The key could be easily used if the attacked exported the key and started signing SCTs. However, they would be able to use it to sign SCTs in DigiCert’s log for fake certs without knowing the full infrastructure.
We will definitely have a full post-mortem on the issue. However, I wanted to post early to give everyone a head’s up about the incident and allow the browsers to take any action required in protecting relying parties. I can say we reacted to the vulnerability when we were notified by Salt that it impacted our system. However, I’m not sure why we were not notified and did not react to the media publication when it first came out. That is a question we are digging into. From: Ian Carroll <i...@ian.sh> Sent: Sunday, May 3, 2020 5:55 PM To: Jeremy Rowley <jeremy.row...@digicert.com> Cc: Mozilla <mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: CT2 log signing key compromise Hi Jeremy, Can you clarify why you believe the signing key cannot be easily used? Is there a cryptographic limitation in what was disclosed? Also, do you have plans for a more formal post-mortem? Since vulnerability management is usually an organization-wide process, it would be useful to understand why it failed here, in the event it could have carried over to other DigiCert infrastructure. Thanks, Ian Carroll On Sun, May 3, 2020 at 4:19 PM Jeremy Rowley via dev-security-policy <dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>> wrote: Hey all, The key used to sign SCTs for the CT2 log was compromised yesterday at 7pm through the Salt root bug. The remaining logs remain uncompromised and run on separate infrastructure. We discovered the compromise today and are working to turn that log into read only mode so that no new SCTs are issued. We doubt the key was used to sign anything as you'd need to know the CT build to do so. However, as a precaution, we ask that you consider all SCTs invalid if the SCT was issued from CT2 after 7pm MST on May 2nd . Please let me know what questions you have. Jeremy _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org<mailto: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
