Chrome CT Policy Update: Removal of '1 Google Log' SCT requirement and changes to number of required embedded SCTs

[Devon O'Brien]

Hello ct-policy@!

Today, we’re announcing a long-awaited update to the Chrome CT Policy (https://goo.gl/chrome/ct-policy), which outlines the requirements for TLS certificates to successfully validate in Chrome. 

The following changes will take effect in Chrome 100, which is scheduled to be released on 29 March 2022:

• For certificates issued on-or-after 15 April 2022 (2022-04-15T00:00:00), it is no longer required that certificates are accompanied by SCTs from a Google-operated CT log. Instead, there must be SCTs from at least 2 distinct CT log operators as specified in the Chrome CT log list.

• For certificates issued on-or-after 15 April 2022 with validity periods of 180 days or longer that are embedding SCTs, there must now be at least 3 SCTs from distinct CT logs. This increases the number of embedded SCTs required in certain cases and brings Chrome’s requirements in line with the existing Apple CT Policy requirements.

The updated policy reflecting both of these changes has been uploaded to a temporary branch of the CT Policy repository. These changes will be merged to the main policy branch in advance of the release of Chrome 100. We will announce when this occurs in a follow-up message to this post.

While we do not expect changes to this proposed policy, we are sharing it with the community now and monitoring for possible impacts as it is rolled out. We encourage those with any questions or concerns regarding this change to discuss on-list, or at the upcoming CT Days on 7-8 March 2022.

Relaxing the ‘One Google Log’ requirement for CT-compliance

As we called out in our Dynamically-updatable CT Log List announcement, we have been laying the groundwork for removing Google-issued SCTs as a requirement for achieving CT-compliance. This requirement was put in place during Certificate Transparency’s nascency to ensure stability and reliability during a time when much of the operational realities of enforcing CT across the web were unknown. 

With improvements to the design and reliability of CT logs, the deployment of SCT auditing, and the ability to monitor and rapidly respond to changes to CT logs, it is time to finally remove the explicit dependency on Google CT logs. Starting in Chrome 100, we are removing this requirement. 

Although we are removing the requirement for SCTs from Google CT logs specifically, we believe that there is still value in requiring SCTs come from CT logs operated by multiple log operators to provide resilience against log operator-wide incidents or possible decisions to cease operating CT logs altogether.

It’s important to note that no process changes are required of CAs or website operators to satisfy the new log operator diversity requirements. The current practice of providing SCTs from both a Google-operated and a non-Google-operated CT log will continue to satisfy the new diversity requirements, while allowing the option of using SCTs from multiple non-Google CT log operators from this point onward.

Changing SCT requirements for certificates with validity periods >= 180 days

While it’s not necessary for CT-enforcing user agents to maintain identical CT Policies, we recognize that CAs and website operators wishing for broad interoperability seek to comply with the strictest set of requirements across all policies. Periodically, we review these differences and assess the benefit of updating our own policy to increase robustness, simplify requirements, or otherwise reduce confusion when complying with multiple policies.

For certificates relying on embedded SCTs, Apple’s CT Policy has required that certificates issued on-or-after 21 April 2021 (as measured by the notBefore value) with validities between 180 and 398 days contain 3 SCTs from distinct CT logs. Meanwhile, the Chrome CT Policy has required only 2 SCTs from distinct CT logs for these certificates. In order to successfully validate in both Chrome and Apple OSs (macOS, iOS, etc.), certificates issued since 21 April 2021 have needed to comply with stricter requirements than specified in Chrome’s policy. TLS certificates deployed since this requirement took effect have largely already complied with the stricter policy. 

Starting in Chrome 100, we will align the requirements across CT Policies by requiring that TLS certificates issued on-or-after 15 April 2022 and relying on embedded SCTs contain 3 SCTs from distinct CT logs instead of 2 if their validity is greater than or equal to 180 days. Since the current maximum validity for newly-issued TLS certificates from default-trusted CAs is 398 days, the updated policy has been condensed to requirements for certificates with validities less than 180 days, and those for certificates with validity periods of 180 days or greater. 

Testing against this updated CT Policy in Chrome

The updated Chrome CT enforcement behavior is available to test today. In any up-to-date version of Chrome Canary, the new CT enforcement behavior is enabled by default. If you would like to test this enforcement against certificates issued prior to 15 April 2022, you can enable this behavior in Chrome 100.0.4866.0 and above by enabling the "certificate-transparency-2022-policy-all-certs" flag on the chrome://flags page.

If you are unable to use Chrome Canary, you can also test the behavior in Chrome 98 and above by running Chrome with the --enable_features=CertificateTransparency2022PolicyAllCerts command line flag. Note that this flag applies the new requirements on all certificates, regardless of issuance date.

As always, we’re happy to discuss upcoming changes to Chrome’s CT Policy. If you have any questions about these proposed changes, please reply to this post and we’ll address them on-list.

-Devon

[Piotr Kucharski]

What happens with users still using older Chrome that encounter certificate without SCTs from Google-operated log?

In other words, when can CAs, realistically, stop embedding SCTs from Google-operated logs to ensure users are not affected?

[Devon O'Brien]

Hi Piotr,

Thanks for asking this question. The date that CAs can realistically stop embedding SCTs from Google-operated CT logs is indeed 15 April 2022.

To ensure that 15 April 2022 is a safe date across all versions, Chrome versions prior to 100 have been configured to stop enforcing CT shortly before this date. Disabling CT enforcement on older versions of Chrome is necessary to prevent breakage any time requirements change in a way that would be incompatible with those prior versions. This effective date also provides CAs time to plan any updates to their logging configurations as well as to allow users to upgrade to an up-to-date version of Chrome prior to this date.

-Devon

[Ivan Ristic]

Hi Devon,

Thanks for the update. This is indeed a big milestone for the CT ecosystem. I have two questions:

1. If the intention is to align with Apple's policy, should we assume that Chrome's new policy also adopts the definition of one day to equal 86,400 seconds? Apologies if this is already the case, but wanted to check because it's not explicitly mentioned in the email.

2. Apple's policy states that 3 SCTs are required for certificates valid for 181+ days ("181 to 398 days", from their web site), but in your email you say that Chrome's policy will require 3 SCTs for 180+ days ("validity is greater than or equal to 180 days"). There's a one day difference. Is this intentional?

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/727fd927-9dc5-4c06-a6cc-724ce6c5fd36n%40chromium.org.

--

Ivan

[Devon O'Brien]

Hi Ivan,

Thanks for reaching out. Regarding your questions, 

1. Chrome's CT enforcement is handled in chrome_ct_policy_enforcer.cc, which uses base::Days() to determine how many SCTs to require based on certificate validity. This does indeed use 86,400 seconds to determine one day (24 * 60 * 60), which matches Apple's existing calculation.

2. This is a great point, and highlights an unintentional corner case on validities exactly equal to 180 days. Since Apple treats partial days as an additional day for their CT Policy, 3 SCTs are required for certificates with even one second above 180 days. Our intent was to match this behavior,  so we have just landed a CL to update the Chrome logic and will merge the correction the above policy text here momentarily, but a summary of the change is for certificates issued on-or-after 15 April 2022:

• 2 SCTs from distinct CT Logs are required for certificates with validities of 180 days or shorter
• 3 SCTs from distinct CT Logs are required for certificates with validities longer than 180 days

Since the CT log operator diversity requirements are independent of certificate validities, those requirements remain unchanged.

-Devon

[Devon O'Brien]

The branch containing the proposed policy text has now been merged and is live on the main policy page. 

As a reminder, here are some helpful Chrome CT permalinks:

• Chrome CT Policy: https://goo.gl/chrome/ct-policy
• Chrome CT Log Policy: https://goo.gl/chrome/ct-log-policy
• CT Log Lifecycle explainer: https://goo.gl/chrome/ct-log-states

-Devon

[Andrew Ayer]

On Tue, 22 Feb 2022 17:41:53 -0800 (PST)

"'Devon O'Brien' via Certificate Transparency Policy"
<ct-p...@chromium.org> wrote:

> 2. This is a great point, and highlights an unintentional corner case
> on validities exactly equal to 180 days. Since Apple treats partial
> days as an additional day for their CT Policy, 3 SCTs are required
> for certificates with even one second above 180 days. Our intent was
> to match this behavior, so we have just landed a CL to update the
> Chrome logic

> <https://chromium-review.googlesource.com/c/chromium/src/+/3482016>

I'm afraid that this CL is wrong. Apple's policy defines a certificate's
validity period as "the period of time from notBefore through notAfter, inclusive"
(in line with RFC 5280, Section 4.1.2.5).

Since it's inclusive, if the difference between notAfter and notBefore is
exactly 180 days, it means the certificate's validity is actually MORE
than 180 days, which counts as an extra day, so the minimum number of SCTs
should be 3.

Thus, using >= was correct and in line with Apple's policy. Using > is
incorrect, and means that Chrome requires only 2 SCTs for certificates
whose lifetime is 180 days + 1 second.

Regards,
Andrew