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/CA%2B1gtabANZiaqJ11yJzm%2B5j5hBXk_j33av9Y%2B2fWsFr%2B-XsMOw%40mail.gmail.com.
