Hi Trev, Thanks for your comments. I have revised section 3.3 of the working draft to add an effective date of October 15, 2026, and also made other changes. See https://github.com/BenWilson-Mozilla/pkipolicy/commit/c555615430fd188db394503baad6c62981e15aa8 . Thanks again, Ben
On Tue, May 12, 2026 at 12:58 PM 'Trevoli Ponds-White' via [email protected] <[email protected]> wrote: > I like the updates Ben. I have a few comments > > 1) 3.3.3 Implementation Commitments" should probably have a further future > date. This policy provides more clarity and people may want to edit their > CP/CPS. > > 2) "multiple external documents." This could use some examples or > additional clarity. For example Mozilla has a few places where CAs are > required to "communicate to subscribers" this is generally done with the > Subscriber Agreement not the CP/CPS. Is this saying we need to duplicate > the text that is also in the Subscriber Agreement into the CP/CPS with some > language like "we comply this with this by putting the following in the > Subscriber Agreement..." or is that not considered an external document and > instead some extension of the CP/CPS? > > Thanks! > > On Friday, May 8, 2026 at 11:23:54 PM UTC-7 Roman Fischer wrote: > >> Hi Ben, >> >> >> >> Your suggested wording makes the intention clear to me. And section 7 is >> also IMHO very clear and useful to ensure traceability over past versions >> of the documents. >> >> >> >> Rgds >> Roman >> >> >> >> *From:* Ben Wilson <[email protected]> >> *Sent:* Freitag, 8. Mai 2026 17:46 >> *To:* Roman Fischer <[email protected]> >> *Cc:* [email protected] >> *Subject:* Re: MRSP 3.1: Issue #s 282 and 295: CP/CPS Documentation >> >> >> >> Hi Aaron and Roman, >> >> Thanks for your feedback and questions. The CCADB has two fields >> implicated here: >> >> - the “CA Document Repository” field, which identifies repository >> locations and may contain multiple URLs as a semicolon-separated list; and >> - the “Document Link” field(s), which identify the specific URLs for >> the actual CP/CPS documents themselves. >> >> Because the CCADB separately tracks the specific document URLs, I am >> considering emphasizing those specific document links over the "repository” >> concept. In other words, the CCADB still collects the repository location, >> which is a useful reference when browsing a CA operator’s website to locate >> related CP/CPS documentation, but I think it's less important from a >> filing/compliance perspective now that the CCADB stores direct document >> links separately. >> >> I am currently considering abbreviating the language to something like: >> >> “CA operators MUST ensure that CP/CPS Documentation is made publicly >> available in a structured, text-based format (e.g. Markdown, AsciiDoc, or >> equivalent) and in a manner that preserves publicly accessible version >> history. CA operators MUST ensure that the current location (URL) of each >> CP/CPS document is accurately disclosed and maintained within the CCADB.” >> >> I’ve tried to avoid being overly prescriptive in order to preserve >> flexibility. >> >> What are your thoughts? Will this approach adequately addresses your >> concerns, or should we take a different one? >> >> Also, are your concerns related to subsection 7 (document archiving)? >> Should that paragraph be edited too? >> >> Thanks again, >> Ben >> >> >> >> On Fri, May 8, 2026 at 1:13 AM 'Roman Fischer' via >> [email protected] <[email protected]> wrote: >> >> I'm a bit confused: Does this mean that the disclosed location should be >> the repository (typically a webpage or github repo) where the current and >> the archived versions are listed or the URL of the current CP/CPS document >> (typically a Markdown file hosted somewhere) or an array of URLs of the >> current and previous versions of the CP/CPS document? >> >> >> >> Thx >> Roman >> >> >> >> *From:* 'Aaron Gable' via [email protected] < >> [email protected]> >> *Sent:* Mittwoch, 6. Mai 2026 04:11 >> *To:* [email protected] >> *Cc:* Ben Wilson <[email protected]>; Wayne <[email protected]>; >> [email protected] <[email protected]>; Aaron Gable < >> [email protected]> >> *Subject:* Re: MRSP 3.1: Issue #s 282 and 295: CP/CPS Documentation >> >> >> >> 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 >> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/18857592-1c83-480d-a0b5-6e071c03969cn%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/ZR0P278MB0170793B0492FDC89EF045EDFA3D2%40ZR0P278MB0170.CHEP278.PROD.OUTLOOK.COM >> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/ZR0P278MB0170793B0492FDC89EF045EDFA3D2%40ZR0P278MB0170.CHEP278.PROD.OUTLOOK.COM?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/5162792e-35b4-4d84-90a5-79560c9c3cc5n%40mozilla.org > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/5162792e-35b4-4d84-90a5-79560c9c3cc5n%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%2B1gtaYOQAP73bpC6fTzm9n%3Dqa_-x%2BEJdhvG6RzP69bPKgw%3DKQ%40mail.gmail.com.
