Updated Mozilla CT Log Policy

[Ben Wilson]

All,

We recently updated our Certificate Transparency policy documentation to clarify our CT Log Policy.  You can view the full content at: https://wiki.mozilla.org/SecurityEngineering/Certificate_Transparency.

Under our existing Mozilla CT Policy: certificates ≤180-day validity require 2 SCTs from distinct log operators; certificates >180-day validity require 3 SCTs, at least one from an Admissible log at verification; and SCTs via TLS handshake or OCSP must include 2 SCTs from distinct Admissible logs.

With this update we clarify that Mozilla recognizes CT logs listed in Chromium’s log_list.json (https://googlechrome.github.io/CertificateTransparency/log_lists.html) that are marked qualified, usable, readonly, or retired.  Per https://wiki.mozilla.org/SecurityEngineering/Certificate_Transparency#CT_Log_Policy, log operators should apply through Google’s CT log program. Admissible logs MUST include all NSS roots that have the websites trust bit enabled, and log operators MUST maintain reliable uptime, timely merging, and compliance with CT operational requirements. Mozilla may independently assess or disqualify any log if needed to protect its users.

These updates clarify Mozilla’s requirements for CT log operators and, with the existing CT policy, will ensure continued alignment with other browsers.

Thanks,

Ben Wilson

Mozilla Root Program Manager

[Rob Stradling]

Hi Ben.  Thanks for sharing this announcement.

I'm working on updating crt.sh's reports ([1] and [2]) that track how well CT logs are complying with the various policies that govern which roots they need to accept at a minimum, and I've noticed that the following language in the new Mozilla CT Log Policy could do with some slight tweaking / clarification...

> Admissible logs MUST include all NSS roots that have the websites trust bit enabled

The Chrome CT Log Policy has a similar requirement, but it's not phrased as a MUST because it allows for the scenario where "If a log operator plans to restrict the set of Accepted Root Certificates, this should be clearly stated in the CT log operator application as well as the rationale for this restriction".

The Apple CT Log Policy also has a similar requirement, but the language seems to imply that the requirement is only evaluated when a log is "considered for inclusion", not after that log has been included.

"MUST include all NSS roots" is a subtly stronger requirement, assuming I understand the intent correctly (*).  "Admissible logs" includes ReadOnly logs that are no longer accepting submissions.  Currently Sectigo is operating a number of logs (the Mammoth and Sabre shards) that are in the ReadOnly state in Chrome's log list.  When these logs transitioned from Usable to ReadOnly, we emptied their Accepted Roots lists and started rejecting all POST requests.  Mozilla's language seems to require us to add all of the "NSS roots that have the websites trust bit enabled" to the Accepted Roots lists of these logs, even though these logs are ReadOnly and hence not actually accepting any submissions at all.  Is this the intent?

(*) Normally when we talk about a log "include"ing a certificate, we mean that the log has accepted a submission and added that certificate as a log entry.  But I presume Mozilla is referring here to inclusion in the log's Accepted Roots list.

Current language:

"All operators of Admissible CT logs MUST include all Root Certificates in NSS that have the websites trust bit enabled"

My wordsmithing suggestion:
"For all Qualified and Usable logs, the operator MUST include in the Accepted Roots list all Root Certificates in NSS that have the websites trust bit enabled"

---

From: 'Ben Wilson' via Certificate Transparency Policy <ct-p...@chromium.org>
Sent: 22 October 2025 18:52
To: ct-p...@chromium.org <ct-p...@chromium.org>
Subject: [ct-policy] Updated Mozilla CT Log Policy

 

All, We recently updated our Certificate Transparency policy documentation to clarify our CT Log Policy. You can view the full content at: https: //wiki. mozilla. org/SecurityEngineering/Certificate_Transparency. Under our existing Mozilla CT Policy: 

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

Report Suspicious

 

ZjQcmQRYFpfptBannerEnd

--
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/CA%2B1gtaZ-3RD%3DFs6J%3DdPZn-T2HFCruC%3DE0c5Y2M%2B05-RMXhVhyA%40mail.gmail.com.

[Ben Wilson]

Thanks, Rob

I'll make your suggested change right away to clarify our intent.  

Everyone,

Please let us know if there are any other suggested improvements.

Thanks again,

Ben 

[Winston de Greef]

One more note I'd like to add: Mozilla's language seems to imply that logs should update their accepted roots whenever new roots are trusted by Mozilla (instead of only including an up to date list when creating the log). However my understanding is that chrome doesn't expect this and that log operators would prefer not to update accepted roots after logs are accepted.

Sincerely,

Winston de Greef

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/MW4PR17MB47291A84D4FB83CEFE4CD1A4AAF0A%40MW4PR17MB4729.namprd17.prod.outlook.com.

[Filippo Valsorda]

FWIW, we do add new roots that are added to CCADB to existing log shards, we just never (automatically or routinely) remove them.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/CAD2RJqaAwV0FXTJBPyWC9paeWO2DPT5G614SxgnUch2pSrKvBg%40mail.gmail.com.

[Pim van Pelt]

Hoi,

And as a followup to Filippo’s details on Sunlight, those of us operating TesseraCT static logs do not automatically update roots. The IPng logs have copied an initial set from

CCADB upon inception and are not adding nor removing roots, because TesseraCT cannot do this online (requires an intrusive restart of the serving process). We may reconsider, if TesseraCT adds online tracking of new roots in the way Sunlight does. 

As such, the Gouda (Sunlight) and Halloumi (TesseraCT) logs are not guaranteed to accept the same roots. 

Pim

— 

Pim van Pelt / PBVP1-RIPE

https://ipng.ch/

On 23 Oct 2025, at 20:06, Filippo Valsorda <fil...@ml.filippo.io> wrote:



To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/fe63d031-fed6-4ab3-8fdd-7b770effb930%40app.fastmail.com.

[Ben Wilson]

Hi all,

Thanks for your concerns and suggestions about that sentence in the CT LOg Policy by which log operators would have to include all NSS roots with the websites trust bit enabled. 

To better align with current practices, here is some draft policy language, which I plan to use to update the CT Log Policy:

For all Qualified and Usable logs, the operator MUST include in the Accepted Roots list all Root Certificates in NSS that have the websites trust bit enabled at the time the log is created or accepted for inclusion. Log operators are encouraged, but not required, to periodically update their Accepted Roots list to include newly trusted NSS roots.

Please let me know any further thoughts about this proposed wording.

Thanks,

Ben

[Rob Stradling]

Hi Winston.  My understanding is that the Chrome CT Log Policy does require all logs to update their accepted roots whenever new roots are trusted by Chrome.

The requirement ("In order to maintain broad utility to Chrome and its users, CT logs are expected to accept logging submissions from CAs that are trusted by default in Chrome across all its supported platforms") is not in the policy section entitled "Application Process".  It's in the "Logging Submission Policy: Accepted Root Certificates" section, which I believe is intended to address ongoing requirements for logs.

It would be really useful if a Chrome representative could chime in and tell us which interpretation is correct.

---

From: Winston de Greef <winston...@gmail.com>
Sent: 23 October 2025 17:54
To: Rob Stradling <r...@sectigo.com>
Cc: Certificate Transparency Policy <ct-p...@chromium.org>; Ben Wilson <bwi...@mozilla.com>
Subject: Re: [ct-policy] Updated Mozilla CT Log Policy

 

One more note I'd like to add: Mozilla's language seems to imply that logs should update their accepted roots whenever new roots are trusted by Mozilla (instead of only including an up to date list when creating the log). However my

ZjQcmQRYFpfptBannerStart

This Message Is From an Untrusted Sender

You have not previously corresponded with this sender.

Report Suspicious

 

ZjQcmQRYFpfptBannerEnd

[Ben Wilson]

Thanks, Rob, for that insight.  Mozilla shares Chrome’s goal of ensuring broad utility, so here is a possible re-wording of that part of the Mozilla CT Log Policy:

"Log operators are expected to update their Accepted Roots list within a reasonable time after new NSS roots are added, so that logs accept submissions from all  root CAs that have the websites trust bit enabled, with Mozilla allowing some flexibility to accommodate operational constraints provided the operator notifies Mozilla, documents the rationale and impact, and commits to a timeline for updating its Accepted Roots list."

Thoughts?

Ben

[Ryan Dickson]

Hi all,

In response to Rob's message...

The requirement ("In order to maintain broad utility to Chrome and its users, CT logs are expected to accept logging submissions from CAs that are trusted by default in Chrome across all its supported platforms") is not in the policy section entitled "Application Process".  It's in the "Logging Submission Policy: Accepted Root Certificates" section, which I believe is intended to address ongoing requirements for logs.

It would be really useful if a Chrome representative could chime in and tell us which interpretation is correct.

Speaking on behalf of Chrome, it’s our expectation that as new root CA certificates are added to the Chrome Root Store, they are also added to the set of accepted root certificates maintained by CT logs listed in a “pending”, “qualified”, or “usable” state.

We recognize the technical considerations, but the requirement to accept logging submissions from all CAs trusted by default in Chrome is intended to be continuous, not a one-time check at the time of log inclusion.

To ease the update process for log operators, we created CCADB reports that list the roots included in the CCADB-participating root stores, (introduced here), and are open to additional recommendations for improvement.

- Ryan, on behalf of the Chrome CT team

 

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/CA%2B1gtabyZa6RBh3Snbn3CGkq%3DrnhqybJYBX2b1sQNke3%3DZRaHQ%40mail.gmail.com.

[Rob Stradling]

Hi Ben.  Sorry for the slow reply.

Your proposed re-wording of that part of the Mozilla CT Log Policy looks good to me.

[Ben Wilson]

Hi Rob,

I've updated the wording (https://wiki.mozilla.org/SecurityEngineering/Certificate_Transparency) and present here, highlighted in yellow, for review and any comments:

CT Policy

Certificate transparency information can be delivered either as signed certificate timestamps (SCTs) embedded in the certificate itself or as SCTs stapled alongside the certificate (via the TLS handshake or in an OCSP response). For a connection to succeed, sufficient certificate transparency information must be provided using either of these methods.

For embedded SCTs, "sufficient" means at least N SCTs from distinct logs that were Admissible or Retired at the time of verification, where N is 2 for certificates with a lifetime of 180 days or less, and 3 otherwise. At least 1 of those SCTs must be from a log that was Admissible at the time of verification. Among those SCTs, at least 2 must be from distinct log operators.

For SCTs delivered via the TLS handshake or an OCSP response, "sufficient" means at least 2 SCTs from distinct log operators that were Admissible at the time of verification.

CT Log Policy

Mozilla does not maintain a separate log application process. We recognize CT logs that appear in the Chromium log_list.json list, located at https://googlechrome.github.io/CertificateTransparency/log_lists.html. CT logs included in that list that are marked qualified, usable, readonly, or retired are considered usable by Mozilla as described above. Log operators seeking inclusion or updates to their logs should apply through Google’s CT log program. For all Qualified and Usable logs, the operator MUST include in the Accepted Roots list all Root Certificates in NSS that have the websites trust bit enabled at the time the log is created or that are accepted for inclusion. Log operators are expected to update their Accepted Roots list within a reasonable time after new NSS roots are added, so that logs accept submissions from all root CAs that have the websites trust bit enabled, with Mozilla allowing some flexibility to accommodate operational constraints provided the operator notifies Mozilla, documents the rationale and impact, and commits to a timeline for updating its Accepted Roots list. All log operators MUST maintain reliable availability, timely merging of submitted certificates, and ongoing compliance with all relevant CT operational requirements. Mozilla reserves the right to independently assess or disqualify any log to protect its users.

Thanks,

Ben

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/42e1701a-68e1-4570-83f1-5159faf29cc6n%40chromium.org.