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
