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]

I'm not sufficiently sophisticated in the ways of WebTrust to comment on the details, but that "have more functional detail about the operations of trusted CAs" is exactly the right direction to move the MRSP. Thank you!

MIke

--
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]

For #294 (Key Generation Recency): No comment, looks good.

For #298 (Continuous Audit Coverage): Looks good, with the inclusion of the paragraph here in the email. I was about to leave a big comment discussing how the need for a new audit report between a key generation ceremony and a root inclusion request is unclear, before realizing you'd addressed it in the email itself :)

For #297 (Updates to Audit Criteria References): the lines which refer to two different versions of a given WebTrust criteria, one applicable up to a certain date and the other required thereafter, only actually link to the latter doc. I think it would be good for these lines to still link to both the old and new versions of the WebTrust documents.

For #296 (Detailed Controls Reports): I fear that this requirement may substantially increase audit costs to CAs. In some ways it feels like a step in the opposite direction from things like the CCADB Self-Assessment, which felt like a move away from reliance on external audits. That said, I do think that the whole industry will benefit from more transparent and detailed audits.

Aaron

To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CADQzZqu%3Dk4ZzAGEBb1t4mQh2Qt%3D2d1DSE9kiToUDk3hfwbge0Q%40mail.gmail.com.