That's not the visible consensus IMO. The visible consensus is we need to revoke a cert that is key compromised once we're informed the key is compromised for that cert (https://groups.google.com/forum/m/#!topic/mozilla.dev.security.policy/1ftkqbsnEU4). The certificate you mentioned was issued before the keys were blacklisted and not part of a certificate problem report. When revoking a cert we scan to see if additional certs are issued with the same key t, but this particular cert one was issued after the scan but before the revocation, largely because the way you are submitting certificate problem reports breaks automation. We currently don't have a way to blacklist private keys until a certificate is revoked, although that would be a nice enhancement for us to add in the future. Anyway, I don't think anything reported violated the BR since 1) this cert was not part of a certificate problem report and 2) we will be revoking within 24 hours of your Mozilla posting.
I support the idea of swift revocation of compromised private keys and do appreciate you reporting them. I think this is helpful in ensuring the safety of users online. However, using the SPKI to submit information breaks our automation, making finding and revoking certs difficult. The more standards way (IMO) is the SHA2 thumbprint or serial number or a good old CSR. Because submitting the SPKI breaks automation, getting evidence of key compromise took an additional 5 hours after you submitted the report. We still revoked all of the current certs with submitted keys within 24 hours of the report (since compromised private keys are bad and there is nothing that says we can't revoke earlier than 24 hours), but I did want to clarify that I don't think the time starts until we can actually get the information necessary to do an investigation (because there is not sufficient evidence of a key compromise until then). Going to the previous discussion, I'd definitely support seeing a standardized way to report key compromise. Trying to account for the various formats they come in and through the various channels creates a lot of manual work on a process that can easily be automated. Jeremy -----Original Message----- From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> On Behalf Of Matt Palmer via dev-security-policy Sent: Saturday, March 21, 2020 11:01 PM To: Mozilla <mozilla-dev-security-pol...@lists.mozilla.org> Subject: Digicert: failure to revoke certificate with previously compromised key Certificate https://crt.sh/?id=2606438724, issued either at 2020-03-21 00:00:00 UTC (going by notBefore) or 2020-03-21 01:56:31 UTC (going by SCTs), is using a private key with SPKI 4310b6bc0841efd7fcec6ba0ed1f36e7a28bf9a707ae7f7771e2cd4b6f31b5af, which was reported to Digicert as compromised on 2020-03-20 02:05:49 UTC (and for which https://crt.sh/?id=1760024320 was revoked for keyCompromise soon after certificate 2606438724 was issued). As previously discussed on this list, the visible consensus is that, according to the BRs, certificates for which the CA already had evidence of key compromise must be revoked within 24 hours of issuance. That 24 hour period has passed for the above certificate, and thus it would appear that Digicert has failed to abide by the BRs. - Matt _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
