On Mon, Mar 23, 2020 at 11:01 AM Jeremy Rowley via dev-security-policy < [email protected]> 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 4310b6bc0841efd7fcec6ba0ed1f36 e7a28bf9a707ae7f7771e2cd4b6f31b5af, 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 [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
