Unfortunately, the BRs make no stipulation on how Proof of Possession is done 
(https://github.com/cabforum/documents/blob/master/docs/BR.md#321-method-to-prove-possession-of-private-key).

Most CAs, in my experience, simply treat the signature on the CSR as sufficient 
to demonstrate control of a given key. 

Specifically, they do not don't require any specific data to be included in the 
CSR so it is only linked with the metadata to be included in the CSR via the 
session they were both submitted in. 

This is, of course, doesn't prove the CSR was created for that particular 
request. For that to be true there would need either be a challenge created by 
the CA, included in the CSR by the requestor or the CA would need to require 
the CSR contain the same data is included in the session.

While the matching of the data in the CSR to the data in the session allows for 
CSR replay, it does mitigate the risk. ACME takes this approach where they say 
(https://tools.ietf.org/html/rfc8555):

   The CSR encodes the client's requests with regard to the content of
   the certificate to be issued.  The CSR MUST indicate the exact same
   set of requested identifiers as the initial newOrder request.

My guess is that the CA in question does not have either check.

The risk here, of course, is low in that having a certificate you do not 
control a key for doesn't give you the ability to do anything. 

Ryan Hurst
(personal capacity)
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to