Descriptive vs. normative language in CP/CPS documentation
Ben Wilson
Greetings,
The recent discussion in Bug 2061902 suggests that the community may not share a sufficiently clear understanding of how descriptive statements in CP/CPS documents should be interpreted. Continued discussion here may be useful, especially in
light of changes to requirements for CPs/CPSes found in v. 3.1 of the Mozilla Root Store Policy, which will become effective on July 1, 2027. Discussing this here will also help refine policy without trying to establish general policy using Bugzilla.
The questions raised include whether an otherwise applicable declarative statement describing certificate contents has conformance significance when it does not use an RFC 2119 keyword.
Of some relevance is a June 2024 MDSP discussion, in which participants generally distinguished a prescriptive CP from a descriptive CPS while recognizing that a CA’s practices may nevertheless be nonconforming when they differ from the CPS.
Here are some of the questions that we might discuss:
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.)
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?
- [tl;dr of conversation in Bug 2061902: Sectigo received two CPRs re: its CPS statement that its server certificates “contain both” the serverAuth and clientAuth EKUs, even though some certificates contained only serverAuth. Sectigo explained that the statement was intended to describe the EKU values found across its overall certificate population, rather than to require both EKUs in every certificate. It therefore did not consider the certificates misissued. Commenters disagreed with Sectigo's suggestion that CPS language is binding only when it uses words such as
MUST,each, orevery. Commenters argued that a CPS is expected to describe the CA’s actual practices, so an ordinary declarative statement can still represent a commitment. They also noted that similar language has been treated as binding in previous incidents and that “certificates contain both A and B” would ordinarily be understood to mean that both are present in each applicable certificate.]
Aaron Gable
Does a CPS statement commit a CA to a practice even if it does not use words such as MUST, each, or every?
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.)
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?
Ben Wilson
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
Ben Wilson
From: <stefan...@telekom.de>
Date: Thu, Aug 13, 2026 at 2:41 AM
Subject: AW: Descriptive vs. normative language in CP/CPS documentation
To: <bwi...@mozilla.com>, <aa...@letsencrypt.org>
Cc: <dev-secur...@mozilla.org>
Hi Ben, Aaron,
from the practical experience we are currently having, as we are rebuilding our CP/CPS structure from an overarching CP (with lots of RFC 2119 keywords ) and specific CPS to single purpose CP/CPS, I agree with Aaron, that a combined CP/CPS is nearly identical to a standalone CPS without RFC 2119 keywords.
Our draft of the “CP portion” in Section 1.1 is currently something like this:
This document is the *CP/CPS TLS* ...
In the structure of the [RFC3647], it describes the implementation of all relevant requirements of <List of all relevant laws and specifications, in our case EU and German law, ETSI, CA/Browser Forum, Root Stores, CCADB>
… confirms compliance with all relevant requirements of the current version of the above-mentioned documents. In the event of a conflict between this document and the above documents, the provisions of the above documents shall prevail …
But in the following, the language is generally descriptive rather than normative. There may be a few exceptions, e.g., in chapter 9.6.3 and 9.6.4, where subscribers and relying parties are obliged to comply with certain requirements and thus the language can be, e.g., "subscribers must guarantee..." or "relying parties should...". But I'm not sure about that yet, as it could also be descriptive, e.g. "The requirements... are described in the Terms of Use"
Kind regards
Stefan
--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
dev-security-po...@mozilla.org.
To view this discussion visit
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtabDQEJQ42gkPFMrqSeLFj56yqQzOV43hUkJwxGrUFXiPA%40mail.gmail.com.
Aaron Gable
Dimitris Zacharopoulos
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.
RFC 2119 words in capital could have a different meaning/interpretation in a CP (e.g. the BRs) but in a CPS it should have the same meaning/interpretation/"strength" as the words "can", "will", etc which clearly describe a certain practice.
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) and other root program policies (as required by the Chrome Root Program Policy Section 1.1.3, 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 dev-secur...@mozilla.org <dev-secur...@mozilla.org> 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.
Dimitris Zacharopoulos
I think it's fine for Sections 9.6.3 and 9.6.4 to contain words like "should" and "must", because those sections are directed at subscribers and relying parties. However, it is important to note that these sections are not binding on those parties: the CA places requirements on subscribers via its Subscriber Agreement, not its CPS; and it doesn't have leverage to place restrictions on relying parties at all. So I think that using "should" and "must" in those sections, especially RFC 2119 all-caps versions of those words, is at best wishful thinking and at worst actively misleading.
I assume you consider those sections "non-binding" because there is no "signing" or "acceptance" taking place, at least by Relying Parties. However, in most cases I've seen, a CPS contains language that is repeated in Subscriber Agreements, and Subscriber Agreements almost always contain references to a CP/CPS.
In my opinion a CPS is definitely binding on Subscribers via the Subscriber Agreement. For Relying Parties, it is also "binding" in the sense that they cannot claim for damages or any other issues if they don't follow the corresponding CPS language that is applicable to Relying Parties. RPs are supposed to read the policy OIDs from the certificatePolicies extension, identify the applicable CP/CPS, read it through, and decide whether to trust a specific certificate or not. We've had endless conversations about the fact that RPs don't read CP/CPS documents, but for those that do, I would not consider the use of the words "should" and "must" to be misleading.
Perhaps there is some other point you're trying to make that I'm missing.
Thanks,
Dimitris.