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%2B1gtaZNxfynP-PgpSLSq0VL_GEqO%2BPP4ugzHCz5vTTOVDph7Q%40mail.gmail.com.
