To add to Trev's list, we have references to: * Our webpage, document repository and the demo webpages * CCADB * ETSI
Regards Roman From: 'Trevoli Ponds-White' via [email protected] <[email protected]> Sent: Dienstag, 12. Mai 2026 23:08 To: [email protected] Cc: Ben Wilson <[email protected]>; Trevoli Ponds-White <[email protected]>; [email protected] <[email protected]>; Martijn Katerbarg <[email protected]> Subject: Re: MRSP 3.1: Issue #s 282 and 295: CP/CPS Documentation That's fantastic Ben. Great suggestion Martijn I hadn't made that connection yet but definitely concur. For the documents reference what about adding this sentence: "This excludes documents defined by or referenced in the Baseline Requirements for the applicable certificate type." In practice this would mean for TLS certificates all these external references are allowable: 1. Any RFC, IANA, or NIST resource referenced in the applicable BRs. 2. Subscriber Agreement. Which is defined by in the BRs. 3. Relying Party Agreement. Which is referenced in the BRs. (We probably want to fix this in a cleanup ballot because in the BRs we refer to this like a defined term but it’s not defined.) 4. The CA/B Forum website. 5. WebTrust Principles and Critieria. 6. CA/B F recommended Github repos. Such as the Debian weak keys. 7. The links for TorProject, Fermat Attack, and Public Suffix List. I'm don't know enough about what other types of external docs other CAs are referencing to know how restrictive this should be. In addition to referencing some of those listed above ours also includes a reference to a privacy policy and the policy pages for the root programs. On Tuesday, May 12, 2026 at 1:38:24 PM UTC-7 Ben Wilson wrote: That's fine, too. I'll make that change. On Tue, May 12, 2026, 2:23 PM Martijn Katerbarg <[email protected]> wrote: Ben, While this is feedback we sent on the recent survey, I’ll repeat it here: For the effective date, is Mozilla willing to consider aligning with Apple’s policy update proposal, targeting July of 2027? Both programs are making changes which will require extensive reviews across multiple CP/CPSes. As we know, incorrections in a CPS can have a large impact. As such, we worry that a “rush job” on this, is a recipe for disaster. Additionally, several CAs are also still working on making the documentation available in MarkDown format, and splitting our general CP/CPSes into purpose specific CP/CPSes. I feel a careful balance of gains verses risk management is warranted here, hence our request to align with the later date proposed by Apple. Regards, Martijn From: 'Ben Wilson' via [email protected] <[email protected]> Date: Tuesday, 12 May 2026 at 22:05 To: Trevoli Ponds-White <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: MRSP 3.1: Issue #s 282 and 295: CP/CPS Documentation This Message Is From an External Sender This message came from outside your organization. Report Suspicious<https://us-phishalarm-ewt.proofpoint.com/EWT/v1/J5K_pWsD!B8YZvmQVdwhyZt_sl1TdIKMQQB65j-Aw9mHfzsB7g4hFXqY6kvSNmqPvqb09mkqmBIZARmZaXCivEiPFrTVOOrTv5DHhyTEZD1E9BXIoQl8KUZ71TbsLAWmnSpQhGYydKQI$> 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<https://urldefense.com/v3/__https://github.com/BenWilson-Mozilla/pkipolicy/commit/c555615430fd188db394503baad6c62981e15aa8__;!!J5K_pWsD!3Hn4r1DdAtKrFhqLq-5gvw1-0OT2ThG_woxugee0xEHGeLrS9Qb1_PEp2w0isN2zL-la5qxJohXZFzuTkORHL8aUaeZdyLQ3Hwdi$>. 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://urldefense.com/v3/__https://groups.google.com/a/ccadb.org/g/public/c/iZg_253IZfo/m/eC8kQnOlBgAJ__;!!J5K_pWsD!3Hn4r1DdAtKrFhqLq-5gvw1-0OT2ThG_woxugee0xEHGeLrS9Qb1_PEp2w0isN2zL-la5qxJohXZFzuTkORHL8aUaeZdyI8p4FJk$>) 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://urldefense.com/v3/__https://github.com/mozilla/pkipolicy/issues/295__;!!J5K_pWsD!3Hn4r1DdAtKrFhqLq-5gvw1-0OT2ThG_woxugee0xEHGeLrS9Qb1_PEp2w0isN2zL-la5qxJohXZFzuTkORHL8aUaeZdyHkTdrDj$> – Revisions to MRSP 3.3 * #282<https://urldefense.com/v3/__https://github.com/mozilla/pkipolicy/issues/282__;!!J5K_pWsD!3Hn4r1DdAtKrFhqLq-5gvw1-0OT2ThG_woxugee0xEHGeLrS9Qb1_PEp2w0isN2zL-la5qxJohXZFzuTkORHL8aUaeZdyDWKAZ6o$> – 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<https://urldefense.com/v3/__https://github.com/mozilla/pkipolicy/compare/3b7d84f5c9708cf6be9655319825d60ea338eca4...ad8e1766be6e0e9a93a64b0b71506ae923086ec5__;!!J5K_pWsD!3Hn4r1DdAtKrFhqLq-5gvw1-0OT2ThG_woxugee0xEHGeLrS9Qb1_PEp2w0isN2zL-la5qxJohXZFzuTkORHL8aUaeZdyKrwEy1l$>. 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<https://urldefense.com/v3/__https://github.com/BenWilson-Mozilla/pkipolicy/blob/3.1/rootstore/policy.md__;!!J5K_pWsD!3Hn4r1DdAtKrFhqLq-5gvw1-0OT2ThG_woxugee0xEHGeLrS9Qb1_PEp2w0isN2zL-la5qxJohXZFzuTkORHL8aUaeZdyNBSckQq$>. Overview of Proposed Changes 1. Sufficiency and Clarity of Disclosure - #295<https://urldefense.com/v3/__https://github.com/mozilla/pkipolicy/issues/295__;!!J5K_pWsD!3Hn4r1DdAtKrFhqLq-5gvw1-0OT2ThG_woxugee0xEHGeLrS9Qb1_PEp2w0isN2zL-la5qxJohXZFzuTkORHL8aUaeZdyHkTdrDj$> 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://urldefense.com/v3/__https://github.com/mozilla/pkipolicy/issues/282__;!!J5K_pWsD!3Hn4r1DdAtKrFhqLq-5gvw1-0OT2ThG_woxugee0xEHGeLrS9Qb1_PEp2w0isN2zL-la5qxJohXZFzuTkORHL8aUaeZdyDWKAZ6o$> 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://urldefense.com/v3/__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__;JQ!!J5K_pWsD!3Hn4r1DdAtKrFhqLq-5gvw1-0OT2ThG_woxugee0xEHGeLrS9Qb1_PEp2w0isN2zL-la5qxJohXZFzuTkORHL8aUaeZdyAXL5Kw2$>. -- 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://urldefense.com/v3/__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__;JQ!!J5K_pWsD!3Hn4r1DdAtKrFhqLq-5gvw1-0OT2ThG_woxugee0xEHGeLrS9Qb1_PEp2w0isN2zL-la5qxJohXZFzuTkORHL8aUaeZdyEg8tR7R$>. -- 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://urldefense.com/v3/__https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/ZR0P278MB0170793B0492FDC89EF045EDFA3D2*40ZR0P278MB0170.CHEP278.PROD.OUTLOOK.COM?utm_medium=email&utm_source=footer__;JQ!!J5K_pWsD!3Hn4r1DdAtKrFhqLq-5gvw1-0OT2ThG_woxugee0xEHGeLrS9Qb1_PEp2w0isN2zL-la5qxJohXZFzuTkORHL8aUaeZdyNm7emcS$>. -- 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://urldefense.com/v3/__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__;JQ!!J5K_pWsD!3Hn4r1DdAtKrFhqLq-5gvw1-0OT2ThG_woxugee0xEHGeLrS9Qb1_PEp2w0isN2zL-la5qxJohXZFzuTkORHL8aUaeZdyExlj1WF$>. -- 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<https://urldefense.com/v3/__https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA*2B1gtaYOQAP73bpC6fTzm9n*3Dqa_-x*2BEJdhvG6RzP69bPKgw*3DKQ*40mail.gmail.com?utm_medium=email&utm_source=footer__;JSUlJSU!!J5K_pWsD!3Hn4r1DdAtKrFhqLq-5gvw1-0OT2ThG_woxugee0xEHGeLrS9Qb1_PEp2w0isN2zL-la5qxJohXZFzuTkORHL8aUaeZdyNpegXnZ$>. -- You received this message because you are subscribed to the Google Groups "[email protected]<mailto:[email protected]>" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]<mailto:[email protected]>. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/206640f0-2e8c-4eb9-ba96-d7031c5f5405n%40mozilla.org<https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/206640f0-2e8c-4eb9-ba96-d7031c5f5405n%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/ZR0P278MB017085FF55FEECDB2C0795DBFA062%40ZR0P278MB0170.CHEP278.PROD.OUTLOOK.COM.
