On Tue, Mar 10, 2020 at 01:25:11PM -0700, bif via dev-security-policy wrote: > Voluntarily providing CSR is not an ideal way to prove key compromise, > because you could've simply found this CSR somewhere (I know, I know, > super unlikely with your Subject... but still could happen.)
Feel free to trawl the Internet looking for CSRs with a subject that indicates that the private key is compromised, where that key is used in a publicly-trusted certificate issued to a third party, and for which the private key hasn't been compromised (feel free to confirm that last part via the pwnedkeys.com search API). When you find one -- just one -- we can continue debating the merits of using a static CSR as a method of attesting key compromise. Until then, I'll keep using them as the least-worst available option. > And while "compromised" is way too short (one can sign up to 32 bytes > using it as a nonce in regular TLS session) to prove the key compromise, > in the absence of the actual compromised private key, about the only way > to ensure the possession is to get the reporter to sign some data chosen > by the CA. It very well may be a random CN in the CSR, or plain old > openssl dgst. That would require the database of all pwnedkeys to be available live, to permit real-time generation of signatures in response to CA requests. Having that many keys online is a *spectacular* security risk, given the importance of some of the certificates whose private keys have been publicly disclosed (there's another gao.gov certificate yet to be revoked, not to mention the one for *.avast.com!). I deliberately and *very* purposely keep the database of actual private keys out of harm's way, and requiring the database to be kept online to respond to challenge-response interactions with CAs seems like a spectacularly bad security compromise. Further, given the lack of any sort of standardisation of revocation workflows, even within a single CA, a challenge-response mechanism for key compromise attestation would almost certainly require manual intervention on my part. Given the large backlog of certificates still to be revoked, and the ongoing stream of new certificates and private keys that will, seemingly, never stop, requiring manual steps from me for every one of those is, I'm sure you can understand, not something I'd be keen on. - Matt _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
