X.509] Certificate Generation without PoP

[Silviu V]

Hello,

I am developing an application which also has some CA functions. The application knows the public key, KpC, of a client which has a priori proven to this app the possession of KpC through an out-of-band mean. Therefore, when the application "calls" the CA functionality to generate the client's certificate, it should not need to provide the Proof-of-Possession of KpC by the client.

My question is which are the steps to be taken by the application, in order to have a certificate generated for KpC, without providing any PoP to the CA?

Any comments are welcome. Thank you in advance for your answer!

--
Silviu
[phone]

______________________________
Think twice before printing this page.
Do you really need it?

[Silviu V]

To reformulate,

Is there a way to generate a certificate without a proof of possession?

Thanks.

2008/8/18 Silviu VLASCEANU <silviu.vlasceanu@...>

Hello,

I am developing an application which also has some CA functions. The application knows the public key, KpC, of a client which has a priori proven to this app the possession of KpC through an out-of-band mean. Therefore, when the application "calls" the CA functionality to generate the client's certificate, it should not need to provide the Proof-of-Possession of KpC by the client.

My question is which are the steps to be taken by the application, in order to have a certificate generated for KpC, without providing any PoP to the CA?

Any comments are welcome. Thank you in advance for your answer!

--
Silviu
[phone]

______________________________
Think twice before printing this page.
Do you really need it?

--
Silviu
[phone]

______________________________
Think twice before printing this page.
Do you really need it?

[David Schwartz]

Silviu Vlascaenu wrote:

> I am developing an application which also has some CA functions.
> The application knows the public key, KpC, of a client which has
> a priori proven to this app the possession of KpC through an
> out-of-band mean. Therefore, when the application "calls" the CA
> functionality to generate the client's certificate, it should not
> need to provide the Proof-of-Possession of KpC by the client.

> My question is which are the steps to be taken by the application,
> in order to have a certificate generated for KpC, without providing
> any PoP to the CA?

> Any comments are welcome. Thank you in advance for your answer!

I would suggest simply doing it the usual way by having the client generate a CSR, send it to the server, and have the server return the certificate. There are several reasons I suggest this. First off, it will actually be easier, since you can use the same code everybody else uses.

Most importantly though, the CSR does more than just prove the client holds the private key. It also proves the client is requesting the common name in the certificate. If you don't do it the same way everyone else does, you run the risk that you will create new and unusual vulnerabilities. The resources to make sure what you are doing is safe would completely outweigh any benefits from your method being simpler.

In any event, it's impossible to give you any kind of recommendation without understanding why you don't want to do it the usual way. We do things the usual way because it's best. If you have some reason another way would be better, that reason will likely suggest the way that might be better.

You could generate a certificate without a CSR. Simply fill in all the fields and sign it. However, nobody knows what vulnerabilities you might create in that case, so it would be a very bad idea. (Unless you have sufficient in-house crypto staff to evaluate it, in which case why are you asking us rather than them?!)

DS


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

[Silviu V]

Thanks for your answer, David. Let me explain some more of my problem.

The reason for not wanting to make a "usual" CSR is that my client is not able to send the CSR to the server (CA) app. In fact, I am extending an existing communication protocol, where I keep the already defined message types and modify only their processing. Therefore, sending a CSR would mean a new message type, which I cannot afford.

The only thing that I need is to certify the public key of the client by the server, therefore the common name and related infos are not used and have no meaning in this context. Moreover, the certification chain is local/private, so it does not involve interactions with external (public) CAs.

Finally, my question was related to how to do this with the openssl command or with calls to the functions in the OpenSSL library. I asked it on the users'mailing list, because I only need some help with using the library. If I would have found a better strategy to make CSRs, I would have posted to devel-openssl or IETF PKIX MLs. But I am not dealing with that...

Thanks again and I hope that I have been clear enough.

2008/8/19 David Schwartz <davids@...>

Silviu Vlasceanu wrote:

> I am developing an application which also has some CA functions.
> The application knows the public key, KpC, of a client which has
> a priori proven to this app the possession of KpC through an
> out-of-band mean. Therefore, when the application "calls" the CA
> functionality to generate the client's certificate, it should not
> need to provide the Proof-of-Possession of KpC by the client.

> My question is which are the steps to be taken by the application,
> in order to have a certificate generated for KpC, without providing
> any PoP to the CA?

> Any comments are welcome. Thank you in advance for your answer!

I would suggest simply doing it the usual way by having the client generate a CSR, send it to the server, and have the server return the certificate. There are several reasons I suggest this. First off, it will actually be easier, since you can use the same code everybody else uses.

Most importantly though, the CSR does more than just prove the client holds the private key. It also proves the client is requesting the common name in the certificate. If you don't do it the same way everyone else does, you run the risk that you will create new and unusual vulnerabilities. The resources to make sure what you are doing is safe would completely outweigh any benefits from your method being simpler.

In any event, it's impossible to give you any kind of recommendation without understanding why you don't want to do it the usual way. We do things the usual way because it's best. If you have some reason another way would be better, that reason will likely suggest the way that might be better.

You could generate a certificate without a CSR. Simply fill in all the fields and sign it. However, nobody knows what vulnerabilities you might create in that case, so it would be a very bad idea. (Unless you have sufficient in-house crypto staff to evaluate it, in which case why are you asking us rather than them?!)

DS


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

--
Silviu

[David Schwartz]

Silviu Vlasceanu wrote:

> To reformulate,

> Is there a way to generate a certificate without a proof of possession?

> Thanks.

Absolutely. Just stuff all the fields that you want into the certificate and sign it. Simply take the fields from wherever you have them rather than from the CSR.

You are the one who started out by saying you had enough information to do this.

You can follow the same code used to generate self-signed certificates. Just sign it with the CA certificate (and use the CA's key info for the authority key fields).

DS


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

[Michael Sierchio]

Silviu VLASCEANU wrote:

> Hello,
>
> I am developing an application which also has some CA functions. The
> application knows the public key, KpC, of a client which has a priori
> proven to this app the possession of KpC through an out-of-band mean.
> Therefore, when the application "calls" the CA functionality to generate
> the client's certificate, it should not need to provide the
> Proof-of-Possession of KpC by the client.
>
> My question is which are the steps to be taken by the application, in
> order to have a certificate generated for KpC, without providing any PoP
> to the CA?
>
> Any comments are welcome. Thank you in advance for your answer!

I have the same queasy feeling upon reading this as I would
a request for instructions on how to remove one's own appendix.

The only advice I can offer is: don't.

- M
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

[wolfoftheair]

What you're saying is this:

1) You know who the principal is (and therefore the CN to stick into
your certificate), due to your pre-existing protocol.
2) You know what the public key is, also due to your pre-existing protocol.
3) You've already verified the proof of possession of the private key
(2) by the principal (1).

What you haven't described is "what do you want them to be able to do
with the certificate?"  This is the determination of what extensions
need to go into the certificate, based on the requirements of the
applications that you want to use these certificates with.  This is
the last bit of information you need to do this.

If you want to do these things within the internet public key profile,
the format of those profiled certificates can be found in RFC 5280.
If you want to do them as generic X.509, grab the X.509 spec and read
it.  (Note that RFC 5280, as dense as it is, has the advantage of
being readable without reference to 80 different standards documents
which are themselves references to 80 others.)

I would recommend at the least that you read up on the part of the
"CA:false" extension ('can this certificate be used as a certificate
authority to chain other principal certificates into this
hierarchy?').  There are many other extensions that you should read
about, and you should also look in the apps you want to use these
certificates with to figure out what extensions they require and what
their semantics are so that you don't get bitten.

-Kyle H

On Tue, Aug 19, 2008 at 3:54 AM, Silviu VLASCEANU
<silviu.vlasceanu@...> wrote:

> Thanks for your answer, David. Let me explain some more of my problem.
>
> The reason for not wanting to make a "usual" CSR is that my client is not
> able to send the CSR to the server (CA) app. In fact, I am extending an
> existing communication protocol, where I keep the already defined message
> types and modify only their processing. Therefore, sending a CSR would mean
> a new message type, which I cannot afford.
>
> The only thing that I need is to certify the public key of the client by the
> server, therefore the common name and related infos are not used and have no
> meaning in this context. Moreover, the certification chain is local/private,
> so it does not involve interactions with external (public) CAs.
>
> Finally, my question was related to how to do this with the openssl command
> or with calls to the functions in the OpenSSL library. I asked it on the
> users'mailing list, because I only need some help with using the library. If
> I would have found a better strategy to make CSRs, I would have posted to
> devel-openssl or IETF PKIX MLs. But I am not dealing with that...
>
> Thanks again and I hope that I have been clear enough.
>
> 2008/8/19 David Schwartz <davids@...>
>>
>> Silviu Vlasceanu wrote:
>>
>> > I am developing an application which also has some CA functions.
>> > The application knows the public key, KpC, of a client which has
>> > a priori proven to this app the possession of KpC through an
>> > out-of-band mean. Therefore, when the application "calls" the CA
>> > functionality to generate the client's certificate, it should not
>> > need to provide the Proof-of-Possession of KpC by the client.
>>
>> > My question is which are the steps to be taken by the application,
>> > in order to have a certificate generated for KpC, without providing
>> > any PoP to the CA?
>>
>> > Any comments are welcome. Thank you in advance for your answer!
>>
>> I would suggest simply doing it the usual way by having the client
>> generate a CSR, send it to the server, and have the server return the
>> certificate. There are several reasons I suggest this. First off, it will
>> actually be easier, since you can use the same code everybody else uses.
>>
>> Most importantly though, the CSR does more than just prove the client
>> holds the private key. It also proves the client is requesting the common
>> name in the certificate. If you don't do it the same way everyone else does,
>> you run the risk that you will create new and unusual vulnerabilities. The
>> resources to make sure what you are doing is safe would completely outweigh
>> any benefits from your method being simpler.
>>
>> In any event, it's impossible to give you any kind of recommendation
>> without understanding why you don't want to do it the usual way. We do
>> things the usual way because it's best. If you have some reason another way
>> would be better, that reason will likely suggest the way that might be
>> better.
>>
>> You could generate a certificate without a CSR. Simply fill in all the
>> fields and sign it. However, nobody knows what vulnerabilities you might
>> create in that case, so it would be a very bad idea. (Unless you have
>> sufficient in-house crypto staff to evaluate it, in which case why are you
>> asking us rather than them?!)
>>
>> DS
>>
>>
>> ______________________________________________________________________
>> OpenSSL Project                                 http://www.openssl.org
>> User Support Mailing List                    openssl-users@...
>> Automated List Manager                           majordomo@...
>
>
>
> --
> Silviu
>

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

[David Schwartz]

> The only thing that I need is to certify the public key of
> the client by the server, therefore the common name and
> related infos are not used and have no meaning in this
> context. Moreover, the certification chain is local/private,
> so it does not involve interactions with external (public) CAs.

> Finally, my question was related to how to do this with the openssl
> command or with calls to the functions in the OpenSSL library.

Fill in the certificate structure with the appropriate fields and sign it. It's really that simple.

X509_new
X509_set_version
ASN1_INTEGER_set(X509_get_serialNumber(), )
X509_set_issuer_name
X509_set_subject_name
X509_set_notBefore
X509_set_notAfter
X509_set_pubkey
X509_add_ext (if needed, as needed)
X509_sign
PEM_write_bio_X509/i2d_X509 (or whatever you want to do with the cert)

        DS


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

[Silviu V]

Kyle,

2008/8/19 Kyle Hamilton <aerowolf@...>

What you're saying is this:

1) You know who the principal is (and therefore the CN to stick into
your certificate), due to your pre-existing protocol.
2) You know what the public key is, also due to your pre-existing protocol.
3) You've already verified the proof of possession of the private key
(2) by the principal (1).

Ack.

What you haven't described is "what do you want them to be able to do
with the certificate?"  This is the determination of what extensions
need to go into the certificate, based on the requirements of the
applications that you want to use these certificates with.  This is
the last bit of information you need to do this.

The certificate will also include an IP Address Extension containing an IP address which is to be assigned by the application. The mandatory fields of the certificate are the public key and the IP extension; the rest is not essential (yet. See below).

If you want to do these things within the internet public key profile,
the format of those profiled certificates can be found in RFC 5280.
If you want to do them as generic X.509, grab the X.509 spec and read
it.  (Note that RFC 5280, as dense as it is, has the advantage of
being readable without reference to 80 different standards documents
which are themselves references to 80 others.)

Indeed, it would be done within the PKIX context. Already started reading RFC5280.

I would recommend at the least that you read up on the part of the
"CA:false" extension ('can this certificate be used as a certificate
authority to chain other principal certificates into this
hierarchy?').  There are many other extensions that you should read
about, and you should also look in the apps you want to use these
certificates with to figure out what extensions they require and what
their semantics are so that you don't get bitten.

You have read my mind again: In a future revision of my application, I might need to set the CA extension to true.

-Kyle H

Thanks a lot for the suggestions, I will conform them.

Cheers,

On Tue, Aug 19, 2008 at 3:54 AM, Silviu VLASCEANU
<silviu.vlasceanu@...> wrote:
> Thanks for your answer, David. Let me explain some more of my problem.
>
> The reason for not wanting to make a "usual" CSR is that my client is not
> able to send the CSR to the server (CA) app. In fact, I am extending an
> existing communication protocol, where I keep the already defined message
> types and modify only their processing. Therefore, sending a CSR would mean
> a new message type, which I cannot afford.
>
> The only thing that I need is to certify the public key of the client by the
> server, therefore the common name and related infos are not used and have no
> meaning in this context. Moreover, the certification chain is local/private,
> so it does not involve interactions with external (public) CAs.
>
> Finally, my question was related to how to do this with the openssl command
> or with calls to the functions in the OpenSSL library. I asked it on the
> users'mailing list, because I only need some help with using the library. If
> I would have found a better strategy to make CSRs, I would have posted to
> devel-openssl or IETF PKIX MLs. But I am not dealing with that...
>
> Thanks again and I hope that I have been clear enough.
>
> 2008/8/19 David Schwartz <davids@...>
>>
>> Silviu Vlasceanu wrote:
>>
>> > I am developing an application which also has some CA functions.
>> > The application knows the public key, KpC, of a client which has
>> > a priori proven to this app the possession of KpC through an
>> > out-of-band mean. Therefore, when the application "calls" the CA
>> > functionality to generate the client's certificate, it should not
>> > need to provide the Proof-of-Possession of KpC by the client.
>>
>> > My question is which are the steps to be taken by the application,
>> > in order to have a certificate generated for KpC, without providing
>> > any PoP to the CA?
>>
>> > Any comments are welcome. Thank you in advance for your answer!
>>
>> I would suggest simply doing it the usual way by having the client
>> generate a CSR, send it to the server, and have the server return the
>> certificate. There are several reasons I suggest this. First off, it will
>> actually be easier, since you can use the same code everybody else uses.
>>
>> Most importantly though, the CSR does more than just prove the client
>> holds the private key. It also proves the client is requesting the common
>> name in the certificate. If you don't do it the same way everyone else does,
>> you run the risk that you will create new and unusual vulnerabilities. The
>> resources to make sure what you are doing is safe would completely outweigh
>> any benefits from your method being simpler.
>>
>> In any event, it's impossible to give you any kind of recommendation
>> without understanding why you don't want to do it the usual way. We do
>> things the usual way because it's best. If you have some reason another way
>> would be better, that reason will likely suggest the way that might be
>> better.
>>
>> You could generate a certificate without a CSR. Simply fill in all the
>> fields and sign it. However, nobody knows what vulnerabilities you might
>> create in that case, so it would be a very bad idea. (Unless you have
>> sufficient in-house crypto staff to evaluate it, in which case why are you
>> asking us rather than them?!)
>>
>> DS
>>
>>
>> ______________________________________________________________________
>> OpenSSL Project                                 http://www.openssl.org
>> User Support Mailing List                    openssl-users@...
>> Automated List Manager                           majordomo@...
>
>
>
> --
> Silviu
>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

--
Silviu

[Silviu V]

Thanks, David, that's exactly what I needed. I already found some examples, but these are very clear as steps to create the cert.

One more question, though: how do you convert an RSA public key from an (uint8_t *) type to the RSA type defined in OpenSSL (or to EVP_PKEY). I have been googling on this but haven't found anything yet.

Gratefully,

2008/8/20 David Schwartz <davids@...>

> The only thing that I need is to certify the public key of
> the client by the server, therefore the common name and
> related infos are not used and have no meaning in this
> context. Moreover, the certification chain is local/private,
> so it does not involve interactions with external (public) CAs.

> Finally, my question was related to how to do this with the openssl
> command or with calls to the functions in the OpenSSL library.

Fill in the certificate structure with the appropriate fields and sign it. It's really that simple.

X509_new
X509_set_version
ASN1_INTEGER_set(X509_get_serialNumber(), )
X509_set_issuer_name
X509_set_subject_name
X509_set_notBefore
X509_set_notAfter
X509_set_pubkey
X509_add_ext (if needed, as needed)
X509_sign
PEM_write_bio_X509/i2d_X509 (or whatever you want to do with the cert)

       DS


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

--
Silviu