Re-Retiring Google Icarus, Pilot, Skydiver, Rocketeer on 15 September 2022
Devon O'Brien
Hey everyone,
I wanted to provide an updated timeline for the Retirement and turndown of Google Rocketeer, Pilot, Skydiver, and Icarus CT logs.
Following up from our recent rollback of these Retirements, we will be marking these 4 logs as Retired on 15 September 2022. This update will be made to both the in-source list in the Chromium repository as well as delivered to existing Chrome clients via the Component updater. Once this Retirement has been rolled out, we plan to take these four CT logs offline on 29 September 2022.
While we’ve been working to bring Google’s non-sharded CT logs offline for several years, these particular logs have continued operation in a unique state to accommodate a past CT enforcement issue with some legacy user agents. Our analysis indicates that this new September Retirement timeline will allow us to bring these logs down with very minimal impact, and we are working directly with involved CAs to ensure this change happens smoothly and without further incident.
Additionally, we will be sharing more details soon about the incident that caused us to roll this change back and what we’re doing to prevent similar incidents in the future.
—
Effective 15 September 2022, the following log(s) will transition to Retired, with the last ‘Qualified’ SCT having a timestamp no later than 1663200000 (2022-09-15T00:00:00+00:00):
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/)
After this point in time, 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-09-15T00:00:00+00:00.
Embedded SCTs dated prior to 2022-09-15T00:00:00+00:00 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 separate 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. Due to the nature of these CT logs’ submission acceptance restrictions, there are a very small number of certificates that could be adversely impacted by this Retirement; however, our scans indicate that these are not in use and we’re working with affected CAs to ensure that any potentially affected certificates are replaced before September.
If you are currently serving SCTs via stapled OCSP, then your CA must take appropriate action to update their OCSP pipeline to ensure they are embedding a policy-satisfying set of SCTs. Once done, you must refresh the OCSP response stapled to the connections. Alternatively, you may choose to provide a policy-satisfying set of SCTs via another mechanism outlined in the Chrome CT Policy.
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 will need to update the SCTs included in the handshake to comply with the Chrome CT Policy in order to satisfy the 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. To ensure that newly-issued certificates will be CT-compliant, you should update your CA’s 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 that replace these SCTs with new ones from a set of CT logs that satisfies the Chrome’s CT Policy. Your customers must then begin to serve these new responses or provide a policy-satisfying set of SCTs via another mechanism before the effective date above.
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.
Dustin Hollenback
Thank you for sharing the updated plan. The following statement is not completely clear to me:
"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."
Devon O'Brien
- SCT1 comes from Google Pilot
- SCT2 comes from e.g. Let's Encrypt Oak 2023 (this can be any current log, does not need to be LE)