Greetings, The recent discussion in Bug 2061902 <https://bugzilla.mozilla.org/show_bug.cgi?id=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 <https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#33-cps-and-cpses>, 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 <https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/Lr68n79gqEs/m/AXstYy85AQAJ>, 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: 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? - [*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, or every. 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.] Thanks, Ben -- 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%2B1gtaY%2BEhFVm2TveAXBtb_fRo3tnzjEFnxrefv5W9fNCa%3DtzQ%40mail.gmail.com.
