MRSP 3.1: Issue #s 294, 296, 297, and 298: Audit-related Improvements
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– Detailed Controls Reports), (2) update references to audit criteria (#297–WebTrust / ETSI), (3) clarify audit coverage following key generation (#298), and (4) add a root key generation recency requirement (#294).
Here
is a GitHub diff comparison of the currently
proposed MRSP v3.1 (working draft, subject to change) vs. the current
MRSP v3.0:
Overview of Proposed Changes
1. Introduction of Detailed Controls Reports (DCRs) – #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
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
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
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
Mike Shaver
--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaahGKEks65eRN5ZFY0LSMR8nVcB_QCNu8ONXDxE3RBP6Q%40mail.gmail.com.
Aaron Gable
Ben Wilson
Hi Aaron,
Thanks for the feedback.
On #298 (Continuous Audit Coverage):
Item 5 of Section 7.1 could be made more explicit (I could work on distinguishing between continuous audit coverage and the timing of audit reports), but hopefully it’s clear that continuous reports are due only at the close of the normal, period-of-time audit cycle and not directly after a key generation ceremony.
On #297 (Updates to Audit Criteria References):
I’ll update those lines to include links to both the prior and current versions of the applicable WebTrust and ETSI audit criteria.
On #296 (Detailed Controls Reports):
I understand the concern about potential audit cost increases. I expect that this should not materially increase costs because it aligns with practices that CA operators and auditors should already be performing as part of a well-functioning audit and compliance program. The goal is to ensure that those practices are more consistently documented and reflected in outputs of the audit process. In addition, more detailed controls reporting will provide clearer visibility into residual or unmitigated risks, especially to the executive level within the CA operator's organization.
If there are specific suggestions on how to improve the clarity or effectiveness of this requirement, I would welcome that input.
Thanks again for the detailed feedback.
Ben
大野文彰
Hello Ben-san,
Thank you for the detailed explanation on the introduction of Detailed Controls Reports (DCRs)
(#296) .
We have a few questions regarding how DCRs are expected to work in environments where a Root CA has Externally‑Operated Subordinate CAs.
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?
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?
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.
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.
Ben Wilson
Hello Ben-san,
Thank you for the detailed explanation on the introduction of Detailed Controls Reports (DCRs) (#296) .
1. Primary Responsibility for Preparing DCRs
We have a few questions regarding how DCRs are expected to work in environments where a Root CA has Externally‑Operated Subordinate CAs.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 CAIf 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 DCRsIf 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 DCRsIn 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.大野文彰（ONO Fumiaki）
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.
Ben Wilson
大野文彰（ONO Fumiaki）
Thank you for adding the requested language.
This looks good from our side.
Best regards,
ONO Fumiaki
SECOM Trust Systems CO., LTD.