Discussion: removal of one-6962-log requirement

[Joe DeBlasio]

Hi ct-policy@,

When Chrome first added support for logs using static-ct-api, we required that public certificates validating in Chrome still had to include at least one SCT from an RFC6962 log. This policy served as a backstop along several axes:

• All static-ct-api log implementations being new, there was a concern of a higher risk of concurrent log failures in these relatively-untested implementations. Requiring an SCT from an RFC6962 log hedged against certificate breakage risk by requiring use of established log implementations.

• Since static-ct-api has a distinct read API, monitors that did not yet support the new API would lose visibility if certificates were only logged to static-ct-api logs. Requiring the use of an RFC6962 log provided monitors with additional time to add support for the new API before they lost visibility into issuance in the WebPKI.

• Lastly, requiring the use of RFC6962 logs aimed to encourage continued operation of RFC6962 logs among log operators until static-ct-api logs was more widely supported and tested.

In our initial announcement, we said explicitly that we anticipated moving towards a policy that was agnostic to API used as soon as possible. In this phase, the policy would be the same as today, but no longer specifically require the use of any RFC6962 logs. Chrome would continue to accept RFC6962 logs, and certificate submitters would be free to continue to use RFC6962 logs. All certificates compliant with Chrome's current CT policies would remain compliant with this updated policy.

In the nearly 9 months since that announcement, we have seen rapid adoption of static-ct-api. Chrome now has Qualified and/or Usable static-ct-api logs from 3 operators, using 2 different software implementations. An additional operator has a static-ct-api log Pending inclusion, a third software implementation from another log operator is not far behind, and at least one additional log operator is expected to apply with a static-ct-api log soon. We have also heard from many major log monitors and auditors that they now support static-ct-api logs.

Due to Chrome's rollout cadence and CT safety timeouts, if we updated Chrome this November, the earliest point at which one could deploy certificates without SCTs from RFC6962 logs while ensuring that the certificate would validate in all Chrome clients would be mid-March 2026. Presumably, the timeline would be somewhat later still for universal support across browsers. This would be more than a year after the initial announcement.

Given this rapid adoption of static-ct-api, we are increasingly comfortable dropping this one-6962-log requirement, but would love to hear the opinions of others in the ecosystem, especially those who have concerns with this timeline. Do you have a reason to believe the ecosystem isn't ready to fully rely on static-ct-api logs?

Thanks,

Joe, on behalf of the Chrome CT team

[Aaron Gable]

Hi Joe,

Chiming in just for myself, not on behalf of Let's Encrypt, I think dropping the requirement makes sense. Especially with the long rollout timeline, I think it makes sense to make this change now, and let it slowly trickle out. By the time CAs are confident enough in the deployment ecosystem to actually start issuing certs that only contain SCTs from static logs, we will have had time for those upcoming logs (new operators! new implementations!) to fully materialize.

Aaron

--
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 visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/CAFZs0S58v9ss4JMej-rmZNYJ-Yb2beSzscH8U_5UVtsvSdQ11A%40mail.gmail.com.