Matthew Hardeman via dev-security-policy <dev-security-policy@lists.mozilla.org> writes:
>The standard use of the most common way of communicating the public key and >the purported proof-of-possession of the private key to the CA, the CSR, does >not provide replay protection and yet is frequently NOT treated as a security >impacting element should it be disclosed post-issuance. As such, one must >question if an arbitrary CSR which contains a valid signature produced using >the private key which corresponds to the subject public key in same said CSR >is really qualified to be considered proof-of-possession (or proof of control) >of said private key. I submit that it is not. All of the cert management protocols I referenced earlier, CMP, CMC, and SCEP but not ACME which I haven't implemented so I'm not sure about, have liveness constraints. In other words you can't replay an old CSR to get a new cert. Even if there is a bare-CSR way to get a cert, the only thing you could do with it is get the same cert issued with a more recent expiry date. Since everyone clicks past expired certs anyway and when they're used for things like code signing they're countersigned by a TSA to give them an indefinite lifetime, I'm not sure that it gets an attacker much. Having said that, it's another one of the many PKI things that just get done a certain way without anyone ever presenting a threat model that justifies it, so it could be a threat in some manner. Peter. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
