This approach attempts to minimize disruption to existing subscribers using a recently announced Chrome feature to remove default trust based on the SCTs (signed certificate timestamps) in certificates.
I was wondering how Chrome was able to revoke a certificate based on time without trusting the CA to not back date certificates and it looks like this is due to being able to trust certificate transparency logs instead. This is where they get the signed certificate timestamps (SCT) from.
Even before CT, policies generally trusted the CA to not backdate. Of course a CA could try that, but if caught, all certificates, including previous ones, would be treated as invalid, so it worked.
CT was introduced to detect misissued certificates, but it was never intended to be used as a timestamping system like this. The point of the SCT timestamp was to start the clock on the deadline for the log to publish the certificate, not for use in trust decisions. So when Chrome announced they were using SCT timestamps for trust decisions, my first question[1] was whether anyone was auditing CT logs to detect backdated timestamps. Since then, I have added timestamp auditing to my monitor and should be able to detect a CT log backdating an SCT timestamp.
The goal of CT was not to make staged distrust of a CA possible (that's just a happy coincidence). It was to make it possible to detect CAs misissuing certificates, which includes CAs back dating certificates.
Comments
I was wondering how Chrome was able to revoke a certificate based on time without trusting the CA to not back date certificates and it looks like this is due to being able to trust certificate transparency logs instead. This is where they get the signed certificate timestamps (SCT) from.
See also https://certificate.transparency.dev/howctworks/
Even before CT, policies generally trusted the CA to not backdate. Of course a CA could try that, but if caught, all certificates, including previous ones, would be treated as invalid, so it worked.
This kind of thing was one of the reasons CT was introduced :D
CT was introduced to detect misissued certificates, but it was never intended to be used as a timestamping system like this. The point of the SCT timestamp was to start the clock on the deadline for the log to publish the certificate, not for use in trust decisions. So when Chrome announced they were using SCT timestamps for trust decisions, my first question[1] was whether anyone was auditing CT logs to detect backdated timestamps. Since then, I have added timestamp auditing to my monitor and should be able to detect a CT log backdating an SCT timestamp.
[1] https://groups.google.com/a/ccadb.org/g/public/c/wRs-zec8w7k...
Sorry I think my phrasing was not great.
The goal of CT was not to make staged distrust of a CA possible (that's just a happy coincidence). It was to make it possible to detect CAs misissuing certificates, which includes CAs back dating certificates.