Kyle,
2008/8/19 Kyle Hamilton <[EMAIL PROTECTED]>
> 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
> <[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]
>
--
Silviu
