Retiring several Google CT logs in Chrome on 01 May 2022
Devon O'Brien
Hello ct-policy@,
In addition to the removals of long Retired or ReadOnly CT logs that we just announced, we’re also announcing the upcoming Retirement of the following Google-operated CT logs recognized in Chrome:
Google 'Icarus' log (https://ct.googleapis.com/icarus/)
Google 'Pilot' log (https://ct.googleapis.com/pilot/)
Google 'Rocketeer' log (https://ct.googleapis.com/rocketeer/)
Google 'Skydiver' log (https://ct.googleapis.com/skydiver/)
In 2019, Google announced plans to Retire and turn down several of these CT logs as we transitioned our CT log infrastructure to exclusively temporally-sharded logs (Google Argon 20XX, Google Xenon 20XX). In early 2020, however, Google announced that these CT logs would remain online and recognized in Chrome, but with a significantly reduced set of accepted roots to accommodate a CT-related EV display issue in older iOS, macOS, tvOS, and watchOS clients.
In order to streamline Google’s CT log operations as well as ensure that the set of recognized CT logs in Chrome provide broad value to the PKI ecosystem, we are resuming our 2019 plans to Retire and ultimately turn down these CT logs.
Starting in Chrome 101, these logs will transition to Retired with a timestamp of 1651363200, (2022-05-01T00:00:00Z). Current CT-enforcing versions of Chrome that can reach the Component Updater service for updated CT log lists will receive these removals sooner.
After 01 May 2022, SCTs from these logs will no longer count towards the CT Compliance requirements stating that at least one SCT must come from a CT log that was Qualified, Usable, or ReadOnly at time of check. As such, after this point, it is no longer appropriate to serve SCTs from this log in the TLS handshake, in OCSP responses, or embedded in certificates issued on-or-after 2022-05-01T00:00:00Z.
Embedded SCTs dated prior to 2022-05-01T00:00:00Z will still satisfy CT Compliance requirements that permit SCTs to come from CT logs that are Qualified, Usable, ReadOnly, or Retired at time of check; however, at least one other SCT must come from a non-Retired CT log from a different log operator in order for the certificate to successfully validate in Chrome.
What does this mean for site operators?
If you are delivering SCTs embedded in the certificate, this should require no action on your part. All previously-issued certificates containing SCTs from these logs that complied with the Chrome CT Policy will continue to do so.
If you are currently serving SCTs via OCSP, then your CA must take appropriate action to update their OCSP pipeline to include a set of SCTs that meets the requirements outlined in the Chrome CT Policy. Once done, you must refresh the OCSP response stapled to the connection. Alternatively, you may choose to provide a policy-satisfying set of SCTs via another delivery mechanism.
If you are currently delivering SCTs via a TLS extension, SCTs issued by these logs will no longer contribute towards CT Compliance. As such, you must begin to serve SCTs from another log before 01 May 2022, in order to satisfy the CT requirements for SCTs delivered via TLS.
What does this mean for CAs?
If you are embedding SCTs in your certificates, SCTs from these logs for newly-issued certificates will no longer meet CT Compliance requirements stating that at least one SCT must come from a CT log that was Qualified, Usable, or ReadOnly at time of check. In order to ensure that newly-issued certificates will be CT-compliant, you should update your CT log configuration to remove these logs while also ensuring that you are still logging a policy-satisfying set of CT logs after the removal.
While it is not required by policy, CAs with existing certificates embedding SCTs from these logs may wish to proactively reissue affected certificates to increase the resilience of these certificates to possible future log incidents.
If you are embedding SCTs from these logs in your OCSP responses, you must issue new OCSP responses with a new set of SCTs that meet the Chrome CT Policy requirements. Your customers must then begin to serve these new responses or provide a policy-satisfying set of SCTs via another mechanism.
What does this mean for Log Operators?
If you are operating a CT log not listed in the above Retirement announcement, you do not need to take any action.
-Devon
Douglas Beattie
Hi Devon,One of our customers has reported that their site is being blocked by Chrome due to the new rules you provided so I wanted to understand the scope of the issue.The site is: https://wausaudl.com/It is a 27 month cert issued on 13 March 2020 and it was logged to Pilot, Skydiver, Digicert Server 2, and Yeti 2022 (I have no idea how that happened...)Neither of the Google CT logs are from non-retired logs. Is that causing the issue here?
Embedded SCTs dated prior to 2022-05-01T00:00:00Z will still satisfy CT Compliance requirements that permit SCTs to come from CT logs that are Qualified, Usable, ReadOnly, or Retired at time of check; however, at least one other SCT must come from a non-Retired CT log from a different log operator in order for the certificate to successfully validate in Chrome.
Doug
--
You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/CAD2nvsQVTaxxx8d50KAby3JEq1X3W3fzQ2kBqf3Z-%3D_gJHgYSQ%40mail.gmail.com.
Andrew Ayer
On Tue, 3 May 2022 07:58:25 -0400
Douglas Beattie <douglas...@gmail.com> wrote:
> > The site is: https://wausaudl.com/
> > https://crt.sh/?id=2767525070
> >
> > It is a 27 month cert issued on 13 March 2020 and it was logged to
> > Pilot, Skydiver, Digicert Server 2, and Yeti 2022 (I have no idea
> > how that happened...)
failing the requirement that at least one SCT comes from a log that is
Qualified, Usable, or ReadOnly at the time of check.
I'm surprised that Chrome did not wait until all non-Apple certificates in
Pilot, Skydiver, and Rocketeer were expired before retiring them.
Since these logs were still accepting non-Apple certificates until June 10, 2020 [1],
it wasn't safe to retire them until Sep 13, 2022 (825 days later).
Even if all CAs had stopped logging to these logs on Feb 19, 2020 when
the plan was announced[2], the logs shouldn't have been retired until
May 24, 2022.
As it stands, any certificate that was logged only to {Pilot, Skydiver,
or Rocketeer} plus {DigiCert 1, DigiCert 2, or DigiCert Yeti 2022}
is now failing to validate, and this is breaking sites as one would
expect.
Regards,
Andrew
[1] https://groups.google.com/a/chromium.org/g/ct-policy/c/iOg8Jqc0XxU/m/fjQdZ5VkAwAJ
[2] https://groups.google.com/a/chromium.org/g/ct-policy/c/iOg8Jqc0XxU/m/cFm75-JzBQAJ