All, This thread begins discussion of proposed audit-related updates to the Mozilla Root Store Policy (MRSP).
These changes are intended to improve the depth, consistency, and verifiability of information available to Mozilla when assessing CA compliance, and when evaluating root inclusion requests. In particular, the proposed changes are meant to *(1)* address gaps between high-level audit opinions and the underlying controls and operational practices that those opinions are meant to assess (*#296 <https://github.com/mozilla/pkipolicy/issues/296>*– Detailed Controls Reports), *(2)* update references to audit criteria (*#297 <https://github.com/mozilla/pkipolicy/issues/297>*–WebTrust / ETSI), *(3)* clarify audit coverage following key generation (*#298 <https://github.com/mozilla/pkipolicy/issues/298>*), and *(4)* add a root key generation recency requirement (*#294 <https://github.com/mozilla/pkipolicy/issues/294>*). *Here is a GitHub diff comparison <https://github.com/mozilla/pkipolicy/compare/3b7d84f5c9708cf6be9655319825d60ea338eca4...ad8e1766be6e0e9a93a64b0b71506ae923086ec5>* of the *currently proposed MRSP v3.1 <https://github.com/BenWilson-Mozilla/pkipolicy/blob/3.1/rootstore/policy.md>* (working draft, subject to change) vs. the *current MRSP v3.0 <https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/>* : *Overview of Proposed Changes* *1. Introduction of Detailed Controls Reports (DCRs) – #296 <https://github.com/mozilla/pkipolicy/issues/296>* The current audit framework relies primarily on standardized audit reports (e.g., WebTrust or ETSI), which provide an opinion on whether controls are suitably designed and operating effectively. However, these reports often do not include sufficient detail about the controls themselves, how they are implemented, or how compliance is verified. The proposed addition of Section 3.1.5 introduces a requirement for an annual Detailed Controls Report (DCR), beginning July 1, 2027. Under this approach, a DCR would: - supplement, but not replace, existing audit reports; - define system boundaries, scope limitations, and interactions with relevant parties; - provide a structured and comprehensive description of CA systems, controls, and audit testing; - contain control mappings, descriptions of control design, testing methodologies, and results; and - incorporate risk considerations and how implemented controls address those risks. The DCR is intended to bridge the gap between high-level audit opinions and the underlying technical and procedural reality of CA operations. Also, the DCR would not be publicly disclosed, but a CA operator would have to provide it to Mozilla upon request. *2. Clarification of Continuous Audit Coverage – #298 <https://github.com/mozilla/pkipolicy/issues/298>* Section 7.1 currently includes language requiring “contiguous period-of-time audit reports,” which has led to ambiguity regarding whether audit reports must be issued immediately following root key generation. A proposed revision in subsection 5 clarifies that: - Continuous audit coverage refers to the absence of gaps in audited periods, not the timing of report issuance. - Audit reports are expected to follow the CA operator’s normal audit cycle (e.g., annual reporting), and are not required to be issued immediately after key generation. - A root key generated within an already-audited environment may be considered covered, provided there are no material changes to controls. However, the following additional edits have not yet made it into MRSP v. 3.1 section 7.1: “Before being included, CA operators MUST provide evidence that their CA key pairs and CA certificates comply with the current Mozilla Root Store Policy and the applicable S/MIME BRs or TLS BRs, and have continuously complied, from the time of CA private key creation (see Section 3.1.3), with the Mozilla Root Store Policy and the applicable Baseline Requirements in effect during the relevant audit periods. Evidence of such continuous compliance consists of: (1) existing period-of-time audit reports covering the CA operator’s systems, processes, and controls; and (2) an auditor-witnessed key generation ceremony report for the root CA key pair. Where the key pair was generated within the audited environment and subject to the same controls, and no material changes to those controls have occurred, a separate or immediate audit is not required prior to submission of a Root Inclusion Request, as the subsequent audit report covering the applicable audit period is expected to include the new root CA certificate within its scope.” I plan to incorporate this language into the draft; feedback is welcome. *3. Root CA Key Generation Recency Requirement – #294 <https://github.com/mozilla/pkipolicy/issues/294>* The proposed update to Section 7.1 also introduces a requirement that root CA key material be generated within five (5) years prior to submission of a root inclusion request. Under this approach: - Root inclusion requests will only be accepted if the corresponding root key pair was generated within the preceding five years. - The requirement is tied to the auditor-witnessed key generation ceremony report submitted with the request. This change is intended to: - Promote modern cryptographic practices and operational readiness; - Ensure that newly included roots reflect current security expectations; and - Reduce reliance on long-dormant or aging key material. *4. Updates to Audit Criteria References – #297 <https://github.com/mozilla/pkipolicy/issues/297>* Sections 3.1.1 and 3.1.2 are updated to reference the current versions of applicable WebTrust and ETSI audit criteria. This is a maintenance update intended to ensure alignment with current audit standards and to avoid ambiguity regarding applicable criteria versions. Feedback on proposed direction and draft language are welcome. Thanks, Ben Wilson Mozilla Root Program -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaahGKEks65eRN5ZFY0LSMR8nVcB_QCNu8ONXDxE3RBP6Q%40mail.gmail.com.
