Hello Ben-san,
Thank you for the detailed explanation on the introduction of Detailed Controls Reports (DCRs) (#296 <https://github.com/mozilla/pkipolicy/issues/296>) . We have a few questions regarding how DCRs are expected to work in environments where a Root CA has Externally‑Operated Subordinate CAs. 1. Primary Responsibility for Preparing DCRs Assume that an Externally‑Operated Subordinate CA has its own contractual relationship with an audit firm, prepares its own WebTrust audit reports, and publishes those reports to CCADB via the Root CA. In such a case, is it the intended direction that the Externally‑Operated Subordinate CA would take primary responsibility for preparing its own DCR in coordination with its auditor? 2. Handling Controls Managed Only by the Root CA If the Externally‑Operated Subordinate CA is responsible for preparing its own DCR, some control areas or information may be known or managed only by the Root CA. In that situation, would it be acceptable for the Subordinate CA’s DCR to explicitly reference the Root CA’s DCR for those specific items? Alternatively, would it be preferable for the Subordinate CA to confirm those aspects with the Root CA and include the relevant descriptions directly within its own DCR? 3. Alignment of Audit Evaluation Periods When Referencing DCRs If referencing the Root CA’s DCR from a Subordinate CA’s DCR is acceptable, would it still be acceptable if the audit evaluation periods of the Root CA and the Externally‑Operated Subordinate CA do not fully align, for example due to differing audit cycles? For example, would it be considered acceptable for a Subordinate CA’s DCR to reference a Root CA DCR that was prepared approximately six months earlier? Any guidance on the intended model or expectations in these scenarios would be very helpful. 4. Role of the Root CA in Monitoring Subordinate CA DCRs In addition, we would like to ask about the role of the Root CA with respect to DCRs prepared annually by Externally‑Operated Subordinate CAs. Even if the Externally‑Operated Subordinate CA is the primary author of its DCR, would it be expected that the Root CA monitor those DCRs and maintain sufficient visibility into the underlying audit details and control implementation? Thank you. Best regards, ONO Fumiaki / 大野 文彰 (Japanese name order: family name first, in uppercase) SECOM Trust Systems CO., LTD. 2026年4月23日木曜日 7:59:56 UTC+9 Ben Wilson: 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/9ab19ccb-a5fd-4cda-b70e-58dc41213fd2n%40mozilla.org.
