On 09/02/10 11:02 AM, Steffen DETTMER wrote: > * Patrick Patterson wrote on Sun, Feb 07, 2010 at 10:14 -0500: >>> A quick question here. Should the Certificate Signing Request message be >>> protected when requesting for Certificate from CA? > > I think, if you want to certify that a public matches subject > description, of course you should authenticate both. > Often time, users being what they are, you DON'T want to trust the "Subject" value in the CSR - this information is often generated purely by the CA.
What you need to do is ensure the integrity of the proof of possession, and make sure that the Public key that you associating with a particular subscriber really is associated with a private key held by that Subscriber. >> The first question, is "How are you protecting this channel?" - there >> are several common ways. For instance, in many models, the Subscriber >> logs into an interface (usually a web site) provided by the CA, which is >> protected by SSL/TLS, using one or more codes provided to that > > If you already have a mutual trust, why would you want to create > an additional certificate? Well, perhaps you aren't just creating a certificate to log into some web interface with (an Identity cert) - you could also be creating a Signature certificate and/or an Encryption certificate. So you don't have any sort of mutual trust - you just have some shared secret that you are reasonably certain that is held only between the CA and the Subscriber... the challenge is finding a scalable and user-proof way of handling and distributing that shared secret. > I think, for renewal, strictly speaking, this might not be the best, > if the keys or certs are changed due to security reasons it seems > doubtfull to protect the renewal process by exactly the > keys/certs to be changed. > You're right - if we are doing a renewal after revocation, or a renewal to obtain a cert of a higher assurance level, using a lower assurance level certificate, or the revoked certificate for this purpose is insufficient. However, to renew a certificate (perhaps rekey would be a better word in this example) due to impending expiry of a cert/keypair, then as long as the old and the new are at the same assurance level, and the old is still valid, you could certainly use the same cert. (Hey - it's good enough for the FBCA, CertiPath, USDoD, Qualified Signature Cert, and most other "medium" assurance policies that I've ever seen :). >> Properly done, there is very little room for a MITM attack to succeed. >> However, to further mitigate this... > > I think it feels a bit like pulling yourself up by your > bootstraps... Often it is not possible to increase the security > level by the security that is to be increased, is it? > I'm not sure I get your point - it is, of course, possible to establish equivalent assurance via multiple means. Some ways are just easier/more scalable than others. Patrick. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
