On 8/17/2026 8:00 PM, 'Aaron Gable' via [email protected]
wrote:
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.
Hi Aaron,
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.
Aaron
On Thu, Aug 13, 2026 at 8:19 AM 'Ben Wilson' via
[email protected] <[email protected]> wrote:
Forwarding to the list
---------- Forwarded message ---------
From: <[email protected]>
Date: Thu, Aug 13, 2026 at 2:41 AM
Subject: AW: Descriptive vs. normative language in CP/CPS
documentation
To: <[email protected]>, <[email protected]>
Cc: <[email protected]>
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
*Von:*'Ben Wilson' via [email protected]
<[email protected]>
*Gesendet:* Donnerstag, 13. August 2026 06:26
*An:* Aaron Gable <[email protected]>
*Cc:* [email protected] <[email protected]>
*Betreff:* Re: Descriptive vs. normative language in CP/CPS
documentation
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
<https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtabDQEJQ42gkPFMrqSeLFj56yqQzOV43hUkJwxGrUFXiPA%40mail.gmail.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/CA%2B1gtaZ%2B9%2Bt56fNxHte6pdSEoG5DG5Qga8AO3aYDgMsR-EZSPA%40mail.gmail.com
<https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaZ%2B9%2Bt56fNxHte6pdSEoG5DG5Qga8AO3aYDgMsR-EZSPA%40mail.gmail.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/CAEmnErctBXKiePFqirbDuoAQJsGAytCGaL9qoUCYftuY1BjtTA%40mail.gmail.com
<https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnErctBXKiePFqirbDuoAQJsGAytCGaL9qoUCYftuY1BjtTA%40mail.gmail.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/d0090be3-573d-4a26-b337-98ad63865659%40it.auth.gr.
