I think that's much better. One potential issue: if a CA maintains a separate CP and CPS (I believe still acceptable in v3.1), they could be in different GitHub repositories. This would make disclosing a single URL in the "Document Repository" field difficult, as it could only point to one or the other.
On Monday, April 27, 2026 at 1:08:54 PM UTC-10 Ben Wilson wrote: > What about this formulation of Item 2 under MRSP section 3.3? > > 2. CA operators MUST maintain CP/CPS Documentation in a structured, > text-based format suitable for version control (e.g., Markdown, AsciiDoc, > or equivalent), host such documentation in a publicly accessible repository > or equivalent system that provides publicly accessible version history, and > ensure that the current, publicly accessible locations (URLs) of that > CP/CPS documentation are disclosed in, and kept up to date within, the > CCADB “Document Repository” field. > > Thanks, > > Ben > > On Sun, Apr 26, 2026 at 11:47 AM Ben Wilson <[email protected]> wrote: > >> Hi Aaron, >> >> Thanks for these comments. >> >> You’re right that the draft hasn't explicitly addressed location of >> documentation disclosure and archiving. >> >> One idea is to leverage the CCADB field “Document Repository” or to >> create an adjacent field to specify archival locations. >> >> I am considering adding the following requirement to MRSP Section 3.3: >> >> “CA operators MUST ensure that the location (URL) of their CP/CPS >> Documentation is disclosed and maintained in the CCADB 'Document >> Repository' field.” >> >> However, that alone will be inadequate. We'll need to amend the CCADB >> Policy and/or provide guidance for use of the “Document Repository” field >> (and possibly add another field for archival locations) to clarify the use >> of the(se) field(s) and ensure uniformity and consistent implementation. >> For example: >> >> “The ‘Document Repository’ field MUST contain one or more URLs that >> provide access to the CA Owner’s current CP/CPS Documentation. Where CP/CPS >> Documentation is maintained in a version-controlled repository, the URL >> MUST reference the repository or a stable landing page that clearly >> identifies the current version and provides access to prior versions or >> version history. CA Owners MUST ensure that this field is kept accurate and >> up to date.” >> >> What are everyone's thoughts on this, and Is another CCADB field needed >> to point to the archival repository (even if they are both in the same >> location)? >> >> Ben >> >> >> On Fri, Apr 24, 2026 at 1:11 PM Aaron Gable <[email protected]> >> wrote: >> >>> 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 >>> >>> On Wed, Apr 22, 2026 at 12:37 PM Wayne <[email protected]> wrote: >>> >>>> 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 >>>> >>>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/d0ce4550-b3a1-4ec6-9bb1-6984ba7da030n%40mozilla.org?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- 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/18857592-1c83-480d-a0b5-6e071c03969cn%40mozilla.org.
