RE: CT2 log signing key compromise

2020-05-03 Thread Jeremy Rowley via dev-security-policy
log signing key compromise On Sunday, May 3, 2020 at 7:35:44 PM UTC-4, Alex Cohn wrote: > Thank you for the clarification. This would appear to introduce a new > requirement for clients verifying SCTs from CT2: a get-proof-by-hash > call to the log server (or a mirror) is now require

RE: CT2 log signing key compromise

2020-05-03 Thread Jeremy Rowley via dev-security-policy
not react to the media publication when it first came out. That is a question we are digging into. From: Ian Carroll Sent: Sunday, May 3, 2020 5:55 PM To: Jeremy Rowley Cc: Mozilla Subject: Re: CT2 log signing key compromise Hi Jeremy, Can you clarify why you believe the signing key cannot

Re: CT2 log signing key compromise

2020-05-03 Thread Ian Carroll via dev-security-policy
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

RE: CT2 log signing key compromise

2020-05-03 Thread Jeremy Rowley via dev-security-policy
doesn’t exist. However, there is still the multiple log requirement. From: Alex Cohn Sent: Sunday, May 3, 2020 5:35 PM To: Jeremy Rowley Cc: Mozilla Subject: Re: CT2 log signing key compromise Thank you for the clarification. This would appear to introduce a new requirement for clients

RE: CT2 log signing key compromise

2020-05-03 Thread Jeremy Rowley via dev-security-policy
signing key compromise They would already appear in a previous tree where the head was signed by us. From: Alex Cohn Sent: Sunday, May 3, 2020 5:22 PM To: Jeremy Rowley Cc: Mozilla Subject: Re: CT2 log signing key compromise The timestamp on a SCT is fully controlled by the signer, so why

Re: CT2 log signing key compromise

2020-05-03 Thread Alex Cohn via dev-security-policy
PM > *To:* Jeremy Rowley > *Cc:* Mozilla > *Subject:* Re: CT2 log signing key compromise > > > > The timestamp on a SCT is fully controlled by the signer, so why should > SCTs bearing a timestamp before May 2 still be considered trusted? > > > > Alex > >

RE: CT2 log signing key compromise

2020-05-03 Thread Jeremy Rowley via dev-security-policy
They would already appear in a previous tree where the head was signed by us. From: Alex Cohn Sent: Sunday, May 3, 2020 5:22 PM To: Jeremy Rowley Cc: Mozilla Subject: Re: CT2 log signing key compromise The timestamp on a SCT is fully controlled by the signer, so why should SCTs bearing

Re: CT2 log signing key compromise

2020-05-03 Thread Alex Cohn via dev-security-policy
The timestamp on a SCT is fully controlled by the signer, so why should SCTs bearing a timestamp before May 2 still be considered trusted? Alex On Sun, May 3, 2020 at 6:19 PM Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hey all, > > The key used to

CT2 log signing key compromise

2020-05-03 Thread Jeremy Rowley via dev-security-policy
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