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
<[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
>>
>> 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@openssl.org
>> Automated List Manager [EMAIL PROTECTED]
>
>
>
> --
> Silviu
>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
