On Tue, Mar 17, 2020 at 03:51:13PM +0000, Tim Hollebeek wrote: > For what it's worth, while we generally try to accept any reasonable proof > of key compromise, we have seen quite a large variety of things sent to > us. This includes people actually sending us private keys in various > forms, which is completely unnecessary and something we'd like to avoid.
You probably want to tell the people handling rev...@digicert.com to stop asking for them, then. I stopped counting after the first four instances I found in my archive of revocation-related communications of Digicert representatives asking for a copy of the private key. > When we are unable to verify a proof, we provide explicit instructions on > how to create a proof in a standardized form that's easy to very. I > believe it currently involves signing something with openssl, so it should > be easy to carry out for anyone who is involved in these sorts of > discussions and has access to the private key. There's "access", and then there's "immediate and easy access". I very deliberately don't keep the 1.3M keys I've collected just lying around to be poked at with openssl at a moment's notice. Dragging a key out of cold storage is deliberately not an easy operation. (Incidentally, that also makes ACME's revocation-by-private-key operation difficult when a cert is issued using a previously compromised key, but that's a separate discussion I need to have with the ACME WG). > I also think it's potentially useful to discuss standardizing lists of > known compromised keys, and how to check them before issuance. The > problem of revoking them could be avoided entirely if they were never > issued in the first place. I don't have conclusive data (yet), but the impression I'm getting so far is that most keys are, in fact, compromised after the certificate has been issued, because people put the key+cert into a public GitHub repo or other public online location (like pastebin), for use in their app. I'm yet to find the time to do an analysis of "certificates whose notBefore is later than when they were discovered by the keyfinder". Once that happens, I'll be able to give a better indication of how much value there is in strict pre-issuance checks for key compromise. - Matt _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
