Hello Ben-san, Thank you for your detailed responses and for incorporating draft language into the MRSP v3.1 working document.
Following your explanation, we have provided a small clarification proposal regarding the handling of DCR references across differing audit evaluation periods. We have posted this as a comment on the GitHub commit below: https://github.com/BenWilson-Mozilla/pkipolicy/commit/9b63c631106390ad5508a4c844bdd78490ec484f#r185146560 We hope this helps improve clarity and consistency of interpretation in practical implementation scenarios. Best regards, ONO Fumiaki SECOM Trust Systems CO., LTD. 2026年5月13日水曜日 8:53:15 UTC+9 Ben Wilson: > Hello Ono-san, > > Please see my responses inline below. > > Ben > > On Tue, May 12, 2026 at 4:36 AM 大野文彰 <[email protected]> wrote: > >> 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? >> > Yes, this is the intended direction. > > Where an externally-operated subordinate CA operates under a separate > audit scope or separate operational control environment, we expect that the > subordinate CA operator will obtain its own DCR covering those systems and > controls within its responsibility. > > This approach is generally consistent with Mozilla’s existing treatment of > externally-operated subordinate CAs, which already recognizes that > subordinate CAs may operate under separate policies, practices, operational > controls, and audit scopes. > > >> 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? >> > Referencing another DCR may be acceptable where portions of a CA hierarchy > operate under shared controls or shared audit scope, provided that the > dependencies, scope boundaries, covered time periods, and responsible > parties are clearly identified. > > Primarily, we don't want gaps or ambiguity regarding which party operates > or audits the relevant controls. > > In some cases, it may be clearer for the subordinate CA’s DCR to directly > describe the dependency and explain that the Root CA operator is the party > responsible for the relevant control. > > >> 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. >> > Synchronization of audit periods seems unlikely. Nevertheless, the > applicable DCRs should collectively provide a coherent view of the controls > and should not leave material gaps in coverage. If one DCR references > another with a different evaluation period, then the covered time periods > should be clearly identified, along with any resulting limitations. In > other words, a subordinate CA's DCR referencing a Root CA's DCR from an > earlier period may be acceptable where the relevant controls remain > applicable and there have not been material changes affecting those > controls. > > 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? >> > Yes. > > Consistent with MRSP section 8.4, the operator of a root CA certificate > included in Mozilla’s Root Store remains completely and ultimately > accountable for certificates issued under the hierarchy, including those > issued through externally-operated subordinate CAs. > > Accordingly, the Root CA operator is expected to maintain sufficient > oversight and visibility into the DCRs obtained by externally-operated > subordinate CAs to help ensure continuing compliance with Mozilla policy. > > This does not necessarily mean that the Root CA operator must duplicate > the work of the auditor, but it does mean that the Root CA operator should > understand the scope, dependencies, limitations, exclusions, and any > material findings relevant to the subordinate CA’s operation. > To address some of your questions, I added some draft language to the > working copy of MRSP v. 3.1, here: > https://github.com/BenWilson-Mozilla/pkipolicy/commit/9b63c631106390ad5508a4c844bdd78490ec484f. > > I am open to any suggestions for improvement. Thanks for your input. > > >> 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/1d34d996-d749-472e-84d6-1e3e96e537c4n%40mozilla.org.
