Hi there: On 07/02/10 8:55 AM, sandeep kiran p wrote: > Hi, > > A quick question here. Should the Certificate Signing Request message be > protected when requesting for Certificate from CA? If I am sending a > PKCS10 request to a remote CA, there could be a possibility that an > attacker might intercept the request, replace the Public Key and > Signature fields with his own (correct) values and just leave the > subject field as-is.
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 Subscriber (how these codes are transmitted, and the security protocols involved, to the Subscriber is usually dependent on the Assurance level of the certificate being requested - the higher the assurance level, the more rigour in ensuring that only the Subscriber has all of the codes). Or, the Subscriber uses some sort of tool that uses the CMP to talk to the CA to transmit the P10 to the CA. Properly done, there is very little room for a MITM attack to succeed. However, to further mitigate this... > The issued certificate would then contain the > subject name of the original client but the public key of the attacker. > In such a case, would it be the responsibility of the client to check > and make sure the public key on the issued certificate matches his own > public key? Yes - most CPs have an "acknowledgement" clause. This means that the Subscriber has to perform some action that says "Yes, I received this certificate, and can confirm that I have the corresponding Private Key) There is further enforcement provided by most Certificate stores (CAPI, Firefox/LibNSS, etc.) - they won't accept a cert for which there is no private key (or, more precisely, they will treat it much differently). And further, the first time that the Subscriber tries to use the cert, it will be very obvious that it is incorrect (for instance - the Subscriber will be unable to establish an SSL/TLS session - even if (in the OpenSSL context), the developer is able to somehow convince the SSL CTX to start up with a mismatched Cert/Private key, the conversation will not be able to proceed, due to this mismatch. (of course, the attacker WOULD NOT have this problem, which places the onus squarely back on the CA to ensure that they do not issue certs unless they are certain that the appropriate Subscriber possesses the corresponding keys). I would strongly recommend, if you are building a CA with any higher than "rudimentary" security, to not try and get this right yourself, and instead, use a product that has been appropriately certified (CC has a "Certificate Protection" profile that can give you an indication as to how much faith you can have in the steps take by the CA software to get the "end-to-end" security right). Have fun. Patrick. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
