Hello Ben-san, Thank you for adding the requested language. This looks good from our side.
Best regards, ONO Fumiaki SECOM Trust Systems CO., LTD. 2026年5月14日木曜日 3:25:04 UTC+9 Ben Wilson: > 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/40498fd4-22e8-4f80-8f3b-17d0239914d5n%40mozilla.org.
