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

Reply via email to