Thanks Trev, I appreciate you engaging directly on this. I agree that duplicating required BR text often doesn't add clarity and just creates maintenance headaches. Your example around reasons 6-16 is a good one. That's the kind of discretionary parameter that belongs in the CPS, in my opinion. Same logic applies to validation methods and profile constraints where the obligation is mandatory but operational choices vary. Same with EKU. The option space has narrowed, but the CA should still state which values appear in which profiles.
Where I think there's more to work through is what belongs in a CPS when a CA incorporates by reference. If "only describe optional or discretionary items" becomes the principle, we lose something. A requirement can be mandatory in the BRs while the way a CA implements it still involves choices that affect risk posture. The distinction is less "required versus optional" and more "normative obligation versus implementation choice." Incorporation by reference establishes the obligation. It doesn't always make the CA's posture visible. One concern with the "SHOULD NOT include details about required practices" framing. It could discourage CAs who want to be more transparent. We should be careful not to create a norm that penalizes specificity. Taken to its conclusion, that rewards minimal disclosure. CAs that say less create less surface area for findings. This also has audit implications. Auditors audit against the CPS. If the CPS just says "we comply with the BRs," what is the auditor actually testing against? The CPS says we comply, the auditor confirms we said we comply. Without implementation specifics in the document, there's less to measure. Over the last several years we've seen more CAs default to "we comply with RFC 5280" without specifying profiles. In my experience, few auditors in this space have the technical depth to independently identify which implementation details to drill into. The CPS is their roadmap. If it's vague, the audit will be too. On validation methods, the CPS doesn't need to restate what each BR method is. But it should state which methods the CA uses, which it doesn't, and any constraints on how they're implemented. That's not duplicating the BRs. It's disclosing choices. We saw why this matters with the TLS-ALPN-01 flaws in early 2022. When vulnerabilities turned up in a CA's implementation of 3.2.2.4.20, the ecosystem needed to quickly assess who else was exposed. That triage only works when CAs enumerate what they use. If every CPS just says "we use approved methods," root programs have no starting point and the response turns into a polling exercise. Bug 1962829 is worth looking at too. Microsoft's CPS had a specific commitment about keyEncipherment in RSA subscriber certs. Turned out to be a typo that didn't match practice. A third-party researcher caught it. It was just a typo, and not a consequential one but it was only catchable because the commitment was specific and measurable. If we remove specificity what happens when the error actually matters? The alternative to a detectable error is an undetectable one, even if minor. If a CA can't detect its own implementation errors, removing that information from the CPS means no one else can either. That raises a fair question about what else might be going unnoticed. On your threshold question, if someone has to leave the CPS and interpret external documents to understand what the CA actually does, the document isn't doing its job. That doesn't mean restating every clause. It means the CA's choices, bounds, and constraints should be findable in one place. I wrote up some broader thoughts on this at https://unmitigatedrisk.com/?p=1123 for anyone interested in the longer version. Ryan Hurst On Fri, Feb 13, 2026 at 2:20 PM 'Trevoli Ponds-White' via CCADB Public < [email protected]> wrote: > Thanks Ryan, you are definitely a good voice to weigh in on this topic. > Looking at some of your examples I think they are definitely a mix of what > I would consider BR copy pasta vs unique information. For example I think > the 24 hour revocation SLA for reasons 1-5 is very clear and not optional. > I’m not sure what it adds for all CAs to repeat this? Alternatively for > reasons 6-16 it’s more interesting because there is an optional time frame > there. Under my first proposal I would expect a CP/CPS to state the > timeline a CA tries to use. Extended Key Usage is another good example > where we have evolved the BRs to a place where there are less options than > there used to be. Rather than CAs listing items that are not allowed or > strictly required a section like this one “7.1.2.2.5 Cross-Certified > Subordinate CA Extended Key Usage – Restricted” has more value if it > specifically addresses if “Any other value” is present and why. > > I think you also bring up something that I think is fundamental to > resolve. What is the threshold we think is fine for parties to have to > reference the various baseline requirements to understand what a CA is > doing? I think this is core to the discussion. The BRs allow incorporation > by reference because of this it’s a very common practice. Section 3 is a > good example of this. Most CAs do not describe the validation methods. Do > we think that CAs should add the descriptions into their docs so that > consumers don’t have to look at the BRs to understand them? > > > On Friday, February 13, 2026 at 1:42:40 PM UTC-8 Ryan Hurst wrote: > >> Thanks, Trev. I care a lot about this topic and think it’s an important >> discussion for the ecosystem. >> >> I put some thoughts on the bug ( >> https://bugzilla.mozilla.org/show_bug.cgi?id=2009525) that frame how I’m >> thinking about CP/CPS structure and governance. I initially tried to reply >> here but realized I had to request access, so the bug seemed like the >> easiest place to respond in the moment. >> >> Happy to discuss any of those points here and hear other perspectives. >> >> I’d be especially curious to hear from auditors about how they are >> evaluating these documents in practice. How much specificity do they rely >> on in the CP/CPS itself versus interpreting incorporation by reference? >> That seems like a critical input to getting this right. >> >> Looking forward to the discussion. >> >> Ryan Hurst >> >> On Friday, February 13, 2026 at 11:53:40 AM UTC-8 Trevoli Ponds-White >> wrote: >> >>> Hello! >>> >>> We want to start a conversation about bringing more clarity and >>> consistency to expectations for CP/CPS content. We posted this here so >>> that non-CA/B F members can provide feedback and because we can think >>> of several ways to do it. An update to the Baseline Requirements, CCADB >>> policy update, or an update to one of the Root programs’ policies. >>> >>> This isn’t the first incident about CP/CPS content the community has >>> had but it’s a good place to start with for background >>> https://bugzilla.mozilla.org/show_bug.cgi?id=2009525. >>> >>> We have two proposals to start the discussion. If people have other >>> proposals or feedback about these, please share them. >>> >>> Proposal 1 – Update Section 2.2 of the Baseline Requirements >>> >>> Change the existing language: >>> >>> The CA SHALL publicly give effect to these Requirements and represent that >>> it will adhere to the latest published version. The CA MAY fulfill this >>> requirement by incorporating these Requirements directly into its >>> Certificate Policy and/or Certification Practice Statements or by >>> incorporating them by reference using a clause such as the following (which >>> MUST include a link to the official version of these Requirements): [Name >>> of CA] conforms to the current version of the Baseline Requirements for the >>> Issuance and Management of Publicly-Trusted TLS Server Certificates >>> published at https://www.cabforum.org. In the event of any >>> inconsistency between this document and those Requirements, those >>> Requirements take precedence over this document. >>> >>> >>> >>> To something like: >>> >>> >>> >>> The CA MUST publicly give effect to these Requirements and represent >>> that it will adhere to the latest published version. The CA MAY fulfill >>> this requirement by incorporating these Requirements by reference into >>> its Certificate Policy and/or Certification Practice Statements. If the >>> CA does this the reference must be in Section 1.1 and MUST list which >>> documents it is referencing by title and must include the link to the >>> document’s landing page i.e. “Baseline Requirements for the Issuance >>> and Management of Publicly‐Trusted TLS Server Certificates >>> https://cabforum.org/working-groups/server/baseline-requirements/”. The >>> CA MAY also include the following in Section 1.1: “In the event of any >>> inconsistency between this document and those Requirements, those >>> Requirements take precedence over this document.” CAs that incorporate >>> requirements by reference SHOULD NOT include details about required >>> practices. CAs that incorporate requirements by reference MUST include >>> details in places where the referenced documents express optional >>> requirements i.e. “No stipulation, SHOULD, SHOULD NOT, MAY, optional. >>> >>> >>> >>> In practice this would result in, for example, Section 4.2.1 (for TLS >>> certs) CAs would have to describe if they reuse validation data but not >>> required items such as: “Applicant information MUST include, but not be >>> limited to, at least one Fully-Qualified Domain Name”. >>> >>> >>> >>> Proposal 2 – Adopt a style similar to Matter PKI by the Connectivity >>> Standards Alliance (CSA) >>> >>> When CA's submit a CPS to the CSA it is laid out where the requirement >>> is stated. Following that there is a spot for the CA response when >>> required. Example: >>> >>> 4.2 - Certificate Application Processing >>> It is the responsibility of the CA/RA to verify that the information in >>> a Certificate Application is accurate. >>> CA Response: <insert response> >>> >>> CA Response: >>> >>> Before issuing Matter Certificates, the CA verifies Vendor identity & >>> information through the following process: 1) Vendor requests a Distributed >>> Compliance Ledger (DCL) challenge to prove ownership of their DCL private >>> key; 2) The CA verifies the DCL challenge; 3) The CA retrieves Requester >>> data for the RAD and Certificate Application; 4) The CA verifies the >>> Vendor's information against a known database; 5) The CA generates the RAD >>> and Certificate Application with the verified data; 6) Vendor signs the RAD >>> and Certificate Application; and 7) The CA creates the Vendor for PAI >>> issuance. >>> >>> Given that we have been moving the CA/B F requirements in a direction >>> where we have greater specificity and less leeway we think this is a >>> good time to revisit more specific requirements for CP/CPS content as >>> well. >>> >>> Thanks! >>> >>> Trevoli Ponds-White >>> >>> Amazon Trust Services >>> >>> -- > You received this message because you are subscribed to the Google Groups > "CCADB Public" 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/ccadb.org/d/msgid/public/9abfa07d-636c-41b8-b770-2d93a29ca73en%40ccadb.org > <https://groups.google.com/a/ccadb.org/d/msgid/public/9abfa07d-636c-41b8-b770-2d93a29ca73en%40ccadb.org?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "CCADB Public" 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/ccadb.org/d/msgid/public/CALVZKwZ29k0ZO3CuFyaeoGJmZsJgvEwT2p3pQ9k6RV-UhibKrA%40mail.gmail.com.
