Hi, joining late in the discussion :)
On 8/13/2026 3:40 AM, 'Aaron Gable' via [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.
I agree about the CP and CPS distinction but I disagree about removing
RFC 2119 keywords. The words may, must, shall, etc are extensively used
in common English and actually help Relying Parties, Subscribers and
other PKI stakeholders understand what the CA is committing to and what
is allowed or not allowed for each stakeholder.
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
<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.
I completely agree with this assessment. Mozilla can also use the
community's feedback to weigh in before any final decision is made.
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.
If we agree that a CPS is a descriptive document with no special RFC
2119 meaning, the RFC 2119 specific words can have an ordinary meaning
as in plain English. I believe "forbidding" RFC 2119 keywords, which is
what I read in this proposal, is a bit too much.
--
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/58f033c5-4278-450f-95af-ef385a01724a%40it.auth.gr.
