Update on Google CT Logs and support for legacy Apple clients
Devon O'Brien
Regarding the recent discussion about proposed plans for several Google CT Logs, I wanted to chime in with Chrome’s stance on this matter.
First, some background: as part of streamlining of the set of Qualified Google CT Logs, as well as a shift to operating only time-sharded CT Logs, the Google CT Log Operator team proposed that following Google CT Logs become Read Only [1]:
https://ct.googleapis.com/pilot
https://ct.googleapis.com/rocketeer
https://ct.googleapis.com/skydiver
https://ct.googleapis.com/icarus
These plans were proposed in the Chromium application for the Google Xenon CT Log, but were first widely shared much later in the context of a thread started by an Apple engineer [2] related to a CT-compatibility issue with legacy iOS, macOS, watchOS, and tvOS clients. In light of the compatibility issue with these clients, and borrowing heavily from discussion by the Google CT Log Operator team and other members of the ecosystem, we propose the following:
The above 4 Google CT Logs can restrict their accepted trust anchors to a set provided by Apple in order to continue supporting these older CT-enforcing clients. These Logs would no longer accept certificate logging requests from the rest of the CA ecosystem.
When all the non-Apple certificates have expired from these logs, Chrome will move to Retire these Logs if they are still Qualified at that point.
Apple web server operators will need to ensure that they provide sufficient additional SCTs to satisfy the CT Policy for both current [3] [4] and legacy CT-enforcing clients, regardless of SCT delivery mechanism (certificate-embedded, OCSP, TLS extension) in order to continue seamless functionality.
While padding with extra SCTs is not immediately required so long as these Logs remain Qualified in modern CT-enforcing user agents, Chrome cannot guarantee that these Logs will continue to stay Qualified should an issue arise in the interim. For that reason, we strongly encourage including additional SCTs early to minimize possible interoperability issues down the road.
Based on the Log List provided by Apple [2], the only non-Google CT Log in this same situation would be the DigiCert Log Server (ct1.digicert-ct.com/log/). We are open to this Log following the same steps as outlined above, but that decision is ultimately up to DigiCert and whether they would like to continue supporting this Log.
In endorsing this plan, we recognize that allowing a Qualified CT Log to drastically restrict its accepted trust anchors creates tension with our strongly-stated goal to keep CT Logs open and usable to the entire ecosystem. The fact that these Logs were already slated to become Read Only combined with the unusual circumstances of having to accommodate a possible CT-related user agent breakage results in this course of action being the least harmful route to pursue. We look forward to working with Log Operators and CT-enforcing user agents to avoid scenarios like this in the future.
Lastly, I wanted to address some open questions surrounding the procedure for Log Operators to announce changes to CT Log operational status. We ask that all future planned status changes to Qualified CT Logs be announced to ct-p...@chromium.org in addition to the existing requirements to post updates to the Log’s Inclusion bug. By posting to this centralized communication channel, this news can be distributed to CT Ecosystem stakeholders efficiently and effectively so that any issues can be identified and discussed before taking effect.
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=833350#c6
[2] https://groups.google.com/a/chromium.org/d/msg/ct-policy/i1NFmE7txNE/dAj5oKzlAgAJ
[3] https://github.com/chromium/ct-policy/blob/master/ct_policy.md
[4] https://support.apple.com/en-us/HT205280