Thanks, Aaron. I agree that the absence of an RFC 2119 keyword does not make an otherwise applicable CPS statement nonbinding. A CPS must describe the CA’s practices, and a CA is expected to operate consistently with such descriptions.
Your recommendation that CPS documents contain no RFC 2119 keywords—and that the CP portion of a combined CP/CPS be limited to identifying the external policies with which the CA complies—is a broader proposal. I would be interested in hearing whether other CA operators, auditors, root store operators, and community members agree with that approach. I also welcome everyone's thoughts on how Mozilla should evaluate whether any particular CPS provision constitutes an implementation commitment. Thanks, Ben On Wed, Aug 12, 2026 at 6:41 PM Aaron Gable <[email protected]> wrote: > Hi all, > > I'll reiterate my previous position: Policies are set by the PKI in which > the CA operates; practices are described by the CA. Having each CA write > its own CP has always been a category error. CP documents are > *prescriptive*, and rely extensively on RFC 2119 keywords. CPS documents > are *descriptive*, and should contain zero uses of the RFC 2119 keywords. > > In my opinion, a combined CP/CPS should be nearly identical to a > standalone CPS, and contain no uses of RFC 2119 keywords. The CP portion of > a combined document is just the paragraph at the top stating conformance to > the Baseline Requirements (as required by BRs Section 2.2 > <https://github.com/cabforum/servercert/blob/main/docs/BR.md#22-publication-of-information>) > and other root program policies (as required by the Chrome Root Program > Policy Section 1.1.3 > <https://googlechrome.github.io/chromerootprogram/#113-chrome-root-program-participant-policies>, > among others). > > With that context, my responses to Ben's specific questions are inline: > > On Sun, Aug 9, 2026 at 11:11 AM 'Ben Wilson' via > [email protected] <[email protected]> wrote: > >> Does a CPS statement commit a CA to a practice even if it does not use >> words such as MUST, each, or every? >> > > It is my opinion that a CPS or combined CP/CPS statement* definitely does* > commit > a CA to a practice even when the statement does not use MUST / SHALL / etc. > > Other words like "each" or "every" are more ambiguous. That gets into your > other questions about ordinary meaning, drafter's intent, and genuinely > unclear statements. > > >> What should be Mozilla's process or criteria when a CPS provision is >> identified as ambiguous or unclear? (E.g. ordinary meaning, the >> surrounding text, certificate profiles, applicable requirements, actual >> issuance practices, or a CA's or drafter's intent.) >> > > I think that Mozilla should make a public judgement call as to whether the > ambiguity is sufficient to require an incident report. I don't think > there's a great objective scale against which to make this judgement. One > can imagine things like "a reasonable reader" (similar to the US legal > system's "reasonable person") being invoked, but I don't know exactly how > to structure that. At the end of the day, Mozilla is the entity that has > the ability to close Bugzilla tickets, so Mozilla is the entity that has to > decide -- in public -- whether the ticket gets to be closed or not. > > >> Should Mozilla’s CP/CPS guidance clarify the situations in which >> descriptive statements would be considered commitments, and should we >> explain how to handle genuinely unclear statements? >> > > I think that Mozilla should require that CPS documents contain no RFC 2119 > keywords, and that combined CP/CPS documents be formatted as I described > above: as a CPS, plus an additional paragraph stating adherence to external > CPs. This will make it abundantly clear that even descriptive statements > are binding, because descriptive statements are the only kind that will be > present. > > Aaron > -- 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%2B1gtabDQEJQ42gkPFMrqSeLFj56yqQzOV43hUkJwxGrUFXiPA%40mail.gmail.com.
