Chrome CT Policy changes to accept static-ct-api logs

[Joe DeBlasio]

Hi all,

Chrome remains excited about the future of the static-ct-api API, and this email formally announces our next steps in supporting its adoption in Chrome's CT log program. (It also includes slight differences from our previously hinted-at policy changes, so please read on for details!)

Recognizing that all tiled (static-ct-api) CT log implementations are new and that no tiled CT log has yet been subjected to the load experienced by logs included in Chrome today, Chrome's initial tiled log support aims to provide an opportunity to for tiled logs in a production environment while ensuring recoverability through falling back onto the existing RFC6962 log ecosystem if needed. In this validation phase, Chrome's CT policy will permit SCTs from included tiled logs, so long as at least one SCT comes from an included RFC6962 log. All other SCT requirements remain in effect and unchanged -- you can read more details in our updated policy. This policy takes effect in Chrome version 134 (releasing on March 4th).  All certificates passing Chrome's previous CT policy will continue to validate under the updated policy.

Starting April 1st, interested log operators may submit static-ct-api-compliant CT logs for inclusion into Chrome's CT log list. These logs will be considered using the same mechanisms and timelines as for RFC6962 log applicants.

Tiled log implementations are still emerging and the specification itself is new. This policy is intentionally rolling out quite early -- we aim to ensure that Chrome isn't a blocker for the ongoing innovation in the static-ct-api space, while doing what we can to ensure the safety and integrity of the CT ecosystem as a whole. 

If the static-ct-api specification and log implementations prove robust, we anticipate moving towards a policy that is agnostic to API specification as soon as October of this year. In that phase, the policy will no longer require the use of RFC6962 logs for certificates to be accepted by Chrome.

I consume CT log data. What should I know?

CT log monitors who do not yet interoperate with static-ct-api logs may start losing visibility into certificates logged to CT once this policy takes effect if any trusted RFC6962 log fails. If you operate a CT log monitor, ensure that your tooling supports static-ct-api logs as soon as possible. If you use a third-party CT monitoring service, check with that service to ensure that they ingest from static-ct-api logs. 

I'm a CA or other certificate submitter. What should I know?

No action is required. You are, however, encouraged to submit your certificates to any submitted static-ct-api logs to increase our collective confidence in their robustness. If you intend to rely on SCTs issued by static-ct-api logs for certificates presented to Chrome, you must ensure that you include at least one SCT from an included RFC6962 log as well. If you do not participate in the validation period, subsequent policy changes will permit you to use RFC6962 and static-ct-api logs interchangeably.

Other CT-enforcing user agents may make differing policy decisions at different times. While we work to ensure that it is straightforward for certificates to comply with Chrome's CT policy and other common CT policies, certificate submitters and end entities are ultimately responsible for assembling a set of SCTs that comply with all policies needed for their certificate's use.

Regardless of whether you decide to make use of static-ct-api logs during this validation period, you should ensure that your CT certificate submission pipeline is ready for the future use of static-ct-api logs. In particular, if you have code that ingests Chrome's log_list.json, you should ensure that your pipeline understands the previously announced tiled_logs addition to the schema.

I operate RFC6962 logs and am not ready to move to static-ct-api. What should I know?

Log operators currently operating RFC6962 logs are under no pressure to operate static-ct-api logs. In fact, please continue to operate your RFC6962 logs as normal! We expect that RFC6962 logs will remain a core part of the CT ecosystem for years to come, alongside static-ct-api logs. If static-ct-api adoption becomes near-universal among existing log operators, we may explore removing support for RFC6962 logs, however we have no timeline for such a removal, and will accept new RFC6962 logs through at least 2026 (i.e. shards with 2028 expiry ranges).

Log operators curious about static-ct-api logs can expect additional static-ct-log log implementations, available for use in a variety of environments, will emerge in the coming months.

I want to submit a static-ct-api log for inclusion. What should I know?

Log operators can read the full details of applying for a log's inclusion in the Chrome CT Log policy. These policies remain mostly unchanged, however:

1. static-ct-api logs will be required to use an MMD of 1 minute or less.

2. To ensure the continued robustness of the RFC6962 ecosystem while tiled logs demonstrate robustness, we are asking that log operators continue to maintain their existing RFC 6962 logs until we transition to the specification-agnostic phase.

The reduced MMD for tiled logs ensures that the CT ecosystem can more effectively support rapid detection of certificates. Maintaining existing RFC6962 logs during tiled log validation ensures the robustness of the RFC6962 log ecosystem until the ecosystem is ready for unqualified reliance on static-ct-api. Even after that time, different CT-enforcing user agents may have differing policies, and log operators are encouraged to operate RFC6962 logs as long as needed to ensure compatibility across the CT ecosystem.

I have additional questions. What should I do?

Ask them here! We're happy to address questions as best as we're able.

Best,

Joe, on behalf of the Chrome CT Team

[Luke Valenta]

Hi Joe,

Quick question on the MMD for static-ct-api logs. The design encourages a null merge delay by requiring that returned SCTs include the leaf index extension, so doesn't this imply that the MMD must be zero, instead of 1 minute or less?

I'll also note that the current tiled log entries at https://www.gstatic.com/ct/log_list/v3/all_logs_list.json have an MMD of 86400, in case that needs to be updated.

Best,

Luke

[Matthew McPherrin]

Including the leaf index does imply sequencing needs to be completed before returning an SCT, but it is possible for a static-ct-api log to actually publish tiles and the next head later.

That's not the tradeoff we wanted for Sunlight, since we wanted to guarantee never missing an MMD.

I think Chrome's policy is appropriate here to allow for other implementations which have different tradeoffs.

--
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/50fe0825-7191-49ec-865e-a002f599474fn%40chromium.org.

[Joe DeBlasio]

Good questions, Luke.

The design of static-ct-api certainly does encourage a null merge delay, and we hope that that is what logs will choose to do.  The spec notes that the design "encourages a null Merge Delay, since entries must be sequenced before an SCT is returned, for this extension to be included." However, it would be possible for SCT to only include the index at which the entry will be included. Even with null merge delays, there's a slightly-philosophical distinction between strict inclusion and the observability/measurability of that inclusion (due to e.g. caching or propagation delay). The requirement of an at-most 1 minute MMD is to clarify that we expect that entries submitted to tiled logs should be retrievable in near-real-time. See also some previous discussion on the topic. Does that make sense?

Regarding tiled logs all_logs_list.json, we opportunistically include logs on that list. Unless a log has applied for inclusion in Chrome, I encourage you to not consider those entries as authoritative. In this case, Let's Encrypt (the only operator with tiled logs listed in all_logs_list.json presently) didn't include explicit MMDs when they announced their logs, so we kept the common default at the time. Logs submitted after April 1 will need to specify an appropriate MMD when doing so, and if Let's Encrypt submits logs we've already included on all_logs_list.json, we'll update the entries accordingly.

Joe

[Luke Valenta]

Thanks, Matthew and Joe for the quick responses! The reasoning makes perfect sense.

Best,

Luke

Luke Valenta

Systems Engineer - Research