Hi Ono-san, I added the requested language at line 298 in this commit - https://github.com/BenWilson-Mozilla/pkipolicy/commit/03f638b283d71a0b163056c2998e50b5cb8c6658 . Ben
On Wed, May 13, 2026 at 3:57 AM 大野文彰（ONO Fumiaki） <[email protected]> wrote: > 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/CA%2B1gtaZWiu_nq2TyJA6HELgN6uPi2NLQpNEL39e%3D1ZO8T2n%3Dzw%40mail.gmail.com.
