Mozilla has published version 3.1 of its Root Store Policy (MRSP), effective July 1, 2026. While previous updates tackled certificate revocation, automation, and operational resilience, this release zeroes in on a harder problem: making Certification Authority (CA) operations truly transparent, understandable, and auditable. For developers and security engineers who rely on the Web PKI, these changes mean deeper insights into how CAs work and stronger guarantees that trust anchors are actually trustworthy.

Improving CP/CPS Documentation

Certificate Practice Statements (CPS) and combined Certificate Policy/Certificate Practice Statement documents (CP/CPS) are the primary public descriptions of a CA’s operations. Unfortunately, their quality varies widely. Some are detailed implementation guides; others are vague outlines that lean heavily on external references. Mozilla’s MRSP v3.1 tightens the requirements in section 3.3, demanding that documentation be explicit, bounded, auditable, and sufficiently detailed to cover all certificate issuance and management activities. The policy now also enforces version control, accessibility, and ongoing maintenance practices.

What does this mean in practice? A technically competent reviewer should be able to read a CA’s CP/CPS and know exactly what commitments the CA has made, how those commitments are implemented, and whether the documented practices support oversight. This isn’t just about compliance paperwork—it’s about reducing misissuance risks by ensuring operational practices are recorded accurately and consistently. Mozilla believes this will improve transparency, cut down on misunderstandings, and lead to more effective audits.

Introducing Detailed Controls Reports

The second major change is the introduction of Detailed Controls Reports (DCRs). Traditional WebTrust and ETSI audits provide assurance that a CA meets established criteria, but they offer limited visibility into the specific controls, testing procedures, and operational environments behind those conclusions. Starting with audit periods beginning July 1, 2027, every CA operator with a root certificate enabled for TLS website authentication must obtain a DCR.

A DCR must cover: scope and boundaries of audited CA systems, applicable audit criteria, controls implemented, the auditor’s testing procedures, test results, and any control exceptions or deficiencies. Mozilla plans to review DCRs on an as-needed basis—mostly during compliance reviews, incident investigations, or inclusion evaluations. The goal is not to replace existing audits but to give Mozilla (and the wider community) a granular view of how CAs actually operate beneath the high-level compliance veneer.

For developers managing certificate infrastructure, this means more accountability. DCRs push CAs to document their system boundaries, control implementations, and testing procedures in a way that supports earlier identification of weaknesses and fosters a culture of continuous improvement. It’s a step toward making “trust but verify” truly actionable.

Additional Clarifications and Improvements

MRSP v3.1 also includes several targeted clarifications:

• Mass revocation planning is now aligned with the CA/Browser Forum Baseline Requirements, ensuring consistency across compliance frameworks.
• Root inclusion requests get clearer audit expectations, including requirements for audit continuity and root key generation ceremonies.
• Root CA key pairs submitted for inclusion must have been generated within the previous five years, ensuring that new roots use contemporary cryptographic practices and controls.
• Ownership or control changes require timely notification to Mozilla, so the impact of acquisitions or reorganizations on compliance can be evaluated.

These may seem like administrative tweaks, but they close loopholes that have historically led to trust gaps. For instance, requiring fresh key pairs prevents legacy weak crypto from entering the root store under the guise of a new inclusion.

Key Takeaways

• MRSP v3.1 shifts focus from technical controls to operational transparency and auditability.
• CP/CPS documents must now be explicit, versioned, and verifiable—no more vague references.
• Detailed Controls Reports will expose the inner workings of CA systems, complementing existing audits.
• Key generation freshness and ownership change reporting tighten the security perimeter.

Looking Forward

Mozilla recognizes that these changes require preparation. To help, the team has published wiki guidance on CP/CPS documentation and Detailed Controls Reports. The policy updates were shaped by discussions with CA operators, auditors, and the Web PKI community—feedback that made the requirements more practical.

For anyone building on top of the Web PKI—whether you’re deploying TLS, building a CA, or relying on certificate transparency—these improvements mean greater confidence that the trust anchors in your certificate chains are backed by verifiable, auditable practices. MRSP v3.1 isn’t just policy; it’s a commitment to making security measurable.

---

Source: Improving Transparency and Assurance in the Web PKI: Mozilla Root Store Policy v3.1