Updated Chrome CT Policy effective November 1, 2020

135 views

Skip to first unread message

Devon O'Brien

unread,

Oct 20, 2020, 11:36:56 PM10/20/20

to Certificate Transparency Policy

Hello ct-policy@,

During CT Days this past September, we announced an overhaul of the Chrome CT Policy and collected feedback from attendees. In this new policy page, you’ll find requirements for CT Logs in the Chrome CT Log Policy and requirements for certificates to validate in Chrome in the Chrome CT Policy. In addition to these policies, the new site is intended to host a growing list of informative CT resources that focus on Chrome’s policy and implementation, such as the new CT Log Lifecycle explainer that is already posted to the site.

Despite the large changes to the structure and text of the policy, there are only a few substantive modifications to existing requirements. Because these changes are both few and relatively low-impact, the new CT Policy will take effect over the existing policy on November 1, 2020.

The substantive, albeit minor, policy changes are as follows:

Going forward, all new CT Logs added to Chrome must be temporally sharded, with an expiry range of no more than one year and no less than six months. One year is the default choice for most CT Logs that currently seems to work best for the ecosystem.
When Logs receive a logging submission for an already-incorporated certificate, Logs must either return an existing SCT or, if creating a new one, add another certificate entry within the MMD such that the new SCT can be verified using the APIs specified in RFC 6962.
Certificates that meet the requirements outlined in the Chrome CT Policy are said to be CT Compliant. As defined by this policy, CT Compliance can no longer be met by a mix of embedded, OCSP, and TLS SCTs and requirements for achieving CT Compliance are defined separately based on the mechanism. Chrome’s implementation has not changed at this point, so no certificates will be immediately affected. Our analysis indicates that mixed SCT delivery is used extremely rarely when validating certificates in Chrome, but if you are one of the very few using this approach, you should begin the process to move to one of the methods explicitly called out in the Chrome CT Policy as we will align Chrome implementation with this policy in the future.

As always, we welcome discussion and questions from the community about the Chrome CT Policy as well as its implementation.

-Devon

Ivan Ristic

unread,

Dec 16, 2020, 10:22:59 AM12/16/20

to Devon O'Brien, Certificate Transparency Policy

Hi Devon,

Can you provide more information about when Chrome will be changing their compliance checking to enforce the change that mixing SCTs is not required?

Some details about the exact implementation would be useful as well, for example, what would the behaviour be if mixed SCTs were encountered? Would Chrome prefer one of the methods, or try one then the other, or something else? A pointer to some code that will be activated at a future date would be sufficient. For context, we have our own verification implementation that emulates Chrome's and we wish to keep it up to date with the changes. We check certificates when we see them in CT, and also when we see them installed.

It would be great if you could share your test cases so that we could ensure that our implementation matches Chrome's behaviour exactly.

Thanks.

--
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/a145fa7f-e2e2-464f-afaf-d531a98c9866n%40chromium.org.