Yeah - that’s about the sum of it. I’ll file an incident report. There are two things worth discussing in general:
1. I’m very interested in seeing the Let’s Encrypt response to this issue since the biggest obstacle in trying to find all of the keys with the same private key is the sheer volume of the certs. Trying to do a comprehensive search when a private key is provided leaves some window between when we start the analysis and when we revoke. 1. Another issue in trying to report keys that aren’t affiliated with any cert is that the process becomes subject to abuse. Without knowing a cert affiliated with a key, someone can continuously generate keys and submit them as compromised. You end up just blacklisting random keys, DDOSing the revocation system as it kicks off another request to search for those keys. I don’t think it’s feasible. This is why the disclosures need to be affiliated with actual certs. From: Ryan Sleevi <r...@sleevi.com> Sent: Monday, March 23, 2020 10:54 AM To: Jeremy Rowley <jeremy.row...@digicert.com> Cc: Matt Palmer <mpal...@hezmatt.org>; Mozilla <mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: Digicert: failure to revoke certificate with previously compromised key On Mon, Mar 23, 2020 at 11:01 AM Jeremy Rowley via dev-security-policy <dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>> wrote: Hey Matt, Ryan's post was the part I thought was relevant, but I understood it differently. The cert was issued, but we should have now revoked it (24 hours after receiving notice). I do see your interpretation though, and the language does support 24 hours after issuing the new cert. What I need is a tool that scans after revocation to ensure there are no additional certs with the same key. The frustration is that this was where the cert was issued after our scan of all keys but just before revocation. As a side note, our system blacklists the keys when a cert is revoked for key compromise, which means I don't have a way to blacklist a key before a cert is ever issued. Matt, Jeremy, To make sure I understand the timeline correctly: 2020-03-20 02:05:49 UTC - Matt reports SPKI 4310b6bc0841efd7fcec6ba0ed1f36e7a28bf9a707ae7f7771e2cd4b6f31b5af, associated with https://crt.sh/?id=1760024320 , as compromised 2020-03-21 01:56:31 UTC - DigiCert issues https://crt.sh/?id=2606438724 with that same SPKI 2020-03-21 02:09:12 UTC - DigiCert revokes https://crt.sh/?id=1760024320 2020-03-23 03:16:18 UTC - DigiCert revokes https://crt.sh/?id=2606438724 Is that roughly correct? If so, it does seem like an Incident Report is warranted here, so we can understand why: a) https://crt.sh/?id=2606438724 wasn't revoked when https://crt.sh/?id=1760024320 was revoked (assuming those timestamps in the CRL are accurate) b) The key wasn't blocklisted as known compromised (if the timestamps are incorrect) That is, it doesn't seem unreasonable that, for situations of key compromise, the CA has the necessary data to scan their systems for potential reuse of that key. Given DigiCert's data lake<https://bugzilla.mozilla.org/show_bug.cgi?id=1526154>, it should be possible to scan for issues. If I've misunderstood the timing here, please feel free to correct. This is where the incident report process is useful, and Resolved/Invalid is a perfectly fine state to end in. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
