MRSP 3.1: Issue #s 282 and 295: CP/CPS Documentation

[Ben Wilson]

All,

This thread begins discussion of proposed updates to the Mozilla Root Store Policy (MRSP) dealing with Certificate Policy/Certification Practice Statement (CP/CPS) Documentation. Throughout the MRSP, the term, “CP/CPS Documentation,” will replace the phrase “CP, CPS, or combined CP/CPS”.

Over time, CP/CPS documentation has increasingly relied on incorporation by reference to the Baseline Requirements, which seems to reduce visibility into CA-specific implementation details. Also, concerns have been expressed in community discussions (e.g. the 2025 Roundtable, dev-security-policy, and CCADB Public) regarding the level of detail provided in CP/CPS documentation. The proposed changes are intended to improve the extent to which CP/CPS documentation can be used to understand and evaluate a CA operator’s actual practices, rather than serve as a high-level, referential document.

The proposed changes primarily address the following GitHub issues:

• #295 – Revisions to MRSP 3.3
• #282 – Require Markdown/AsciiDoc for CP/CPS documentation

Here is comparison of proposed MRSP 3.1 (as of today) vs. current MRSP v. 3.0: https://github.com/mozilla/pkipolicy/compare/3b7d84f5c9708cf6be9655319825d60ea338eca4...ad8e1766be6e0e9a93a64b0b71506ae923086ec5.

Here is the working branch for MRSP v. 3.1 (working draft, subject to change):  https://github.com/BenWilson-Mozilla/pkipolicy/blob/3.1/rootstore/policy.md.

 

Overview of Proposed Changes

1. Sufficiency and Clarity of Disclosure -  #295

The current MRSP requires that CP/CPS documentation provide sufficient information to determine compliance. In practice, however, many CP/CPS documents have relied heavily on incorporation by reference (e.g., citing Baseline Requirements sections) without clearly describing how those requirements are satisfied with implementation.

The proposed changes clarify that CP/CPS documentation must describe the CA operator’s implementation of applicable requirements, not merely identify them.

Under this approach:

• 3.3.1  CP/CPS documentation is expected to provide CA-specific detail sufficient for a technically competent reviewer to understand how validation, issuance, revocation, and related processes are actually performed.
• 3.3.2  Incorporation by reference remains permissible for normative obligations and shared definitions, but it cannot substitute for disclosure of CA-specific practices.
• 3.3.3  Documentation must be explicit, bounded, and testable where feasible, enabling meaningful audit, review, and comparison across CA operators.
• 3.3.4  Reviewers should not be required to reconstruct operational practices by correlating multiple external documents.
• 3.3.5  CP/CPS documentation must contain or clearly reference certificate, CRL, and OCSP profiles (separate, versioned companion documents are allowed where appropriate).
• 3.3.6  CP/CPS documentation must reflect current operations with substantive changes traceable through version history and changelogs.

The intent is to make CP/CPS documentation a reliable and self-contained description of how a CA operates in practice, particularly in areas where the Baseline Requirements or other standards allow discretion.

2. Documentation Format and Versioning - #282

Also proposed (in Item 2 of MRSP 3.3) are requirements to maintain publicly accessible CP/CPS documentation in a structured, text-based format (e.g., Markdown, AsciiDoc, or similar), with version history.  It is proposed that the requirement to publish CP/CPS documentation on the CA operator’s website be removed, to allow for alternative publication models (e.g., version-controlled public repositories). CA operators may continue to publish PDF versions on their websites if they choose.

These edits are intended to promote CA operator consistency in how such documentation is maintained and published and to support more efficient review, comparison, and automation. Rather than prescribing a single tool or platform, the requirement focuses on characteristics: structured text, version control, and publicly accessible history.

Feedback on the proposed direction and draft language is welcome.

Thanks,
Ben Wilson
Mozilla Root Program

[Wayne]

Having read the comparison of proposed changes nothing jumps out as a stepback. Overall the changes seem to improve clarity, transparency, and are overall a step forward for the industry.

Thanks everyone for your hard work in getting us this far.

- Wayne

[Aaron Gable]

I concur, the changes related to CPS content seem good and don't seem onerous.

I have one minor concern: Section 3.3(2) says that CAs must keep their CP/CPS Documentation in markdown in a public repo, but doesn't say how the CA shall disclose the location of such. Linked from our website (as the current version of the requirements says)? Linked from our Repository? Disclosed in CCADB? Paragraph (7) of the same section does say that CAs shall "maintain links to all historical versions", but it doesn't say where, and my interpretation of that paragraph is that it is about preventing bit-rot (i.e. old links have to continue working).

Thanks,

Aaron

--
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/d0ce4550-b3a1-4ec6-9bb1-6984ba7da030n%40mozilla.org.