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
