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
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
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
Emails crossed paths – I meant 6pm for the last signed head, but I’m double
checking as I’m not 100% sure on that time. And you are right – since a
compromised SCT can have any time it wants, only a real time check on the last
known good log would be proof of a valid CT. That real time check
That is a good question though - I think the last signed head was 7pm. That
would be the actual time when all other certs shouldn't be trusted...
There is a problem though if you have a bad-acting CA since the notBefore date
could be before 7pm and the browsers don't check to see if it was
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
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 a
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
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
El domingo, 3 de mayo de 2020, 21:05:05 (UTC+2), Ryan Sleevi escribió:
> Pedro,
>
> Did you mean Section 3, not Section 4?
>
Yes, my bad... My comment was indeed related to section 3
___
dev-security-policy mailing list
Pedro,
Did you mean Section 3, not Section 4?
Section 4 does not talk about certificate lifetimes at all, but covers
similar long-standing requirements imposed by other root programs
directly. Naturally, the CA Communications doesn't cover the many
existing Mozilla requirements that are also
Hello,
this commentary it's quite obvious and probably unnecessary, but I would just
say that the controversy that section 4 of the survey is raising is simply
because many of us have the feeling that this change of certificate lifespan
should have come by means of a ballot and a new version of
12 matches
Mail list logo
