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 On Wednesday, April 22, 2026 at 8:23:40 PM UTC+1 Ben Wilson wrote: > 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 > <https://groups.google.com/a/ccadb.org/g/public/c/iZg_253IZfo/m/eC8kQnOlBgAJ>) > > 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 <https://github.com/mozilla/pkipolicy/issues/295> – Revisions > to MRSP 3.3 > - #282 <https://github.com/mozilla/pkipolicy/issues/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 > <https://github.com/mozilla/pkipolicy/issues/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 > <https://github.com/mozilla/pkipolicy/issues/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 > -- 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/d0ce4550-b3a1-4ec6-9bb1-6984ba7da030n%40mozilla.org.
