Yes, but only for embedded SCTs. For revocation or extension served SCTs, you 
could end up with different timestamps depending on how the CA is set up. On 
top of that, for embedded SCTs, you'd need to route the cert through a separate 
singing service that used the compromised key. For that to happen, either 
another CA compromised the log or another CA was compromised in a manner that 
an attacker could direct issuance through a log running the compromised key. 

Digging into our logs, I think the log should be distrusted for everything 
after 17:00:02 on May 2. This was the last known good treehead. That head was 
published at 5:00:00 on Sunday, May 3. All SCTs after this don't appear in a 
reliable tree.

Jeremy
-----Original Message-----
From: dev-security-policy <[email protected]> On 
Behalf Of Corey Bonnell via dev-security-policy
Sent: Sunday, May 3, 2020 6:42 PM
To: Mozilla <[email protected]>
Subject: Re: CT2 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 required to know if a SCT 
> from before May 2 is valid. Do CT-enforcing clients do this in practice today?
> (I suspect the answer is "no" but don't know off the top of my head)

Alternatively, if SCTs from other trusted CT logs are available for a given 
certificate (which would be the case with certificates that comply with 
Google/Apple policy by embedding the requisite number of SCTs in the final 
certificate), the timestamps of those SCTs could be used to determine if the 
CT2 SCT was signed before the key was compromised.

Thanks,
Corey
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy

_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to