Summary

  • Mozilla’s current policy distinguishes a maintained root-store and audit regime from the validation practices a CA must use before putting subscriber information into a certificate.
  • Neither a policy statement nor a period-of-time audit is a retrospective record of one request, one validation observation, one issuance decision, one later revocation state or one client result.

Mozilla Root Store Policy 3.1, effective on 1 July 2026, is unusually helpful because it puts several true statements beside one another without making them interchangeable. Mozilla distributes a set of CA certificates with purpose-specific trust bits. It requires certain audits before inclusion and at least annually thereafter for roots and technically capable intermediates in scope.

It also requires a CA to verify subscriber-supplied information through an independent source or alternative channel before inclusion in a certificate, and for a TLS-capable certificate to ensure authorization for listed domain names and control of listed IP addresses through documented methods.

Each statement matters. None is a shortcut to the next one.

An audit is about an assurance boundary. It has a covered system, stated criteria, period, methods, evidence selected for testing, findings and limits. Mozilla’s policy says full-surveillance, period-of-time audit information must be updated at least annually; from annual audit periods beginning on or after 1 July 2027, it also requires a Detailed Controls Report for in-scope websites-trust-bit CAs. The planned report is explicitly about system boundaries, controls, implementation, testing and operating effectiveness. That is valuable governance evidence.

It is not designed to be a list of every certificate request or a substitute for the contemporaneous evidence behind one issuance.

The difference becomes plain when a certificate is placed before a reader. A serial number, issuer, validity interval and subject alternative names describe an object. They do not show which request was received, which policy and procedure revision applied, which authorized people or systems acted, what independent validation source was used, whether the observation was still within the permitted time window, or why a key was bound to the names. An audit opinion does not fill those missing joins merely because it was issued by a qualified auditor.

The reverse substitution is also unsafe. A certificate record may show that an object was issued. It does not prove that the CA’s whole control environment worked throughout an audit period, that every operating location was in scope, that a later incident was absent, or that Mozilla maintained the relevant root-store treatment for every downstream build. Mozilla’s own policy observes this distribution boundary: entities distributing software based on Mozilla software may add or delete CA certificates and change trust bits in their versions.

A root-store policy governs Mozilla’s distributed default set; it does not erase other distributors’ choices.

Nor should issuance be mistaken for later acceptance. NSS documentation distinguishes certificate blocks from trust blocks and treats a root as a certificate plus trust settings. A client still has to construct and assess a path under its own software state and local conditions. Hostname handling, time, extensions, chain construction, revocation information, application use and the target service observed at connection time remain distinct questions. This is not a claim that a particular client failed. It is a limit on what an audit or issuance file can prove without the client-side evidence.

The practical answer is an issuance evidence receipt, not more ceremonial paperwork. For a material assertion, preserve a protected request identifier; the requested names and key fingerprint; the procedure and policy version; the authorized decision actor or automated control; the independent-source or alternative-channel observation and its permitted time window; the resulting serial number, issuer, validity and relevant extensions; and the issuance time. Preserve later revocation evidence separately, with the query time and responder or list context.

Preserve a relying-client result separately again, including the client build or policy boundary, hostname, chain and time, without collecting unnecessary user data.

This receipt does not ask a CA to publish domain-control material, customer records or security-sensitive internal controls. It asks an institution that makes several different assertions to stop using one assertion as a substitute for another. Protected evidence can be reviewed under appropriate authority. What must remain durable is the map of the joins: which decision supported which object, under which rule, and which later observation is being claimed.

Evidence limits

The reviewed materials do not identify a CA, subscriber, certificate, audit opinion, Detailed Controls Report, incident or relying-party event. They do not establish that any CA failed an audit or issued a certificate wrongly. The proposed receipt is editorial analysis, not a Mozilla, CA/Browser Forum, NSS or RFC requirement. It is intentionally narrower than a claim about universal browser behavior or Web PKI safety.

Sources

  1. Mozilla Root Store Policy 3.1
  2. Mozilla NSS: Updating NSS’s Root Store
  3. RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile