Thank you for bringing this subject up. You have hinted at a problem as I did wander into this a few weeks ago but didn't wish to open this can of worms...
The CP and CPS mentioned in RFC 3647 at some point got flipped by some CAs and are being used in the opposite interpretation than RFC 3647 states. Originally one was the summary (CP), one was the details (CPS), and which is which now depends on the CA. I don't think this divergence *should *matter in reading each CA's documents in isolation, but it is interesting historically and is an indication of how deeply CAs read the RFCs. A reason I didn't mention this is that the BRs themselves prescribe: >1.2.2 Relevant Dates >2018-05-31: 2.2: CP and CPS must follow RFC 3647 format >2.2.: >The Certificate Policy and/or Certification Practice Statement MUST be structured in accordance with RFC 3647 and MUST include all material required by RFC 3647. Therefore taking the 'material required' to be the definition of CP/S it is a slight issue given the terms getting flipped at some point, but only by some CAs. As for your questions: 1. It depends on the context - not a straight answer but this is a complex document. I am of the opinion that given the language of the "take precedence" statement, it was meant to fill-in gaps that are left by an otherwise defective CPS that is lacking in substance on a particular section. Likewise, if a CA decides to insert language into a portion of their CPS that further restrains them, they then should not be able to claim that the BR overrides it. I hope that makes some sense? 2. I agree that this is looking to require further clarification, whether that specifically requires updated language in the BRs I see as an SCWG issue. I am interested to see others thoughts on these issues. - Wayne On Friday, June 14, 2024 at 5:19:23 PM UTC+1 Aaron Gable wrote: > Hi all, > > I know this topic may be better suited for the CABForum's servercert-wg > mailing list, but I wanted to start the conversation here to get input from > a wider community first. > > As you may be aware, there has recently been discussion (e.g. on this > bugzilla incident report > <https://bugzilla.mozilla.org/show_bug.cgi?id=1890898>) about how to > handle inconsistencies between the Baseline Requirements, a CA's own CP, > and a CA's CPS. I believe the conversation so far has been somewhat barking > up the wrong tree, and I'd like to see if the rest of this community agrees > with my interpretation. > > The Baseline Requirements, v2.0.5, Section 2.2 > <https://github.com/cabforum/servercert/blob/7be6839f23725d3dcd14a5ce1491e423e32512ed/docs/BR.md#22-publication-of-information> > says: > > > The CA SHALL publicly give effect to these Requirements and represent > that it will adhere to the latest published version. The CA MAY fulfill > this requirement by incorporating these Requirements directly into its > Certificate Policy and/or Certification Practice Statements or by > incorporating them by reference using a clause such as the following (which > MUST include a link to the official version of these Requirements): > > > [Name of CA] conforms to the current version of the Baseline > Requirements for the Issuance and Management of Publicly-Trusted TLS Server > Certificates published at http://www.cabforum.org. In the event of any > inconsistency between this document and those Requirements, those > Requirements take precedence over this document. > > This has, predictably, led to many CAs (examples: Let's Encrypt > <https://letsencrypt.org/documents/isrg-cp-cps-v5.3/#1.1-overview>, GTS > <https://pki.goog/repo/cps/5.9/GTS-CPS.html>, Entrust > <https://www.entrust.com/sites/default/files/documentation/licensingandagreements/entrust-certificate-services-cps-3-21.pdf>, > > Sectigo CP > <https://www.sectigo.com/uploads/files/Sectigo_WebPKI_CP_v1_3_4.pdf> and > CPS <https://www.sectigo.com/uploads/files/Sectigo_CPS_v5_4_1.pdf>) > including the suggested paragraph of text verbatim in their CPS. And this, > in turn, has led to the discussion of what exactly counts as an > "inconsistency" and, if an inconsistency is found, what it means for the > BRs to "take precedence". > > RFC 3647 <https://datatracker.ietf.org/doc/html/rfc3647> "Internet X.509 > Public Key Infrastructure Certificate Policy and Certification Practices > Framework", Section 3.5 > <https://datatracker.ietf.org/doc/html/rfc3647#section-3.5> "Relationship > Between Certificate Policy and Certification Practice Statement" says: > > > A CP sets forth the requirements and standards imposed by the PKI with > respect to the various topics. In other words, the purpose of the CP is to > establish what participants must do. A CPS, by contrast, states how a CA > and other participants in a given domain implement procedures and controls > to meet the requirements stated in the CP. > > The Baseline Requirements is a CP: it sets forth the requirements that PKI > participants must abide by. Similarly, a CA's CP is (of course) a CP, > establishing additional requirements above and beyond what the BRs and > other root programs require. > > But a CPS, as defined by RFC 3647, is something altogether different. It > does not establish requirements by which the CA must abide. Instead, a CPS > _describes the actual behavior of the CA_. > > This can, in my opinion, lead to two different kinds of incidents: > - If the CA behaves in a way other than their CPS describes, then they are > in violation of their CPS. > - If the CA's CPS describes behavior which is in violation of their CP > (including the BRs), then they are in violation of that CP (and/or the BRs). > > If the document which includes the suggested paragraph from the BRs is a > CP, then I believe the suggested language makes sense: any inconsistencies > between the document and the BRs are essentially immaterial, and the BRs > take precedence. For example, if a CP said that the maximum validity of a > DV certificate was 399 days, then obviously the BRs' 398 days would control. > > However, if the document which includes the suggested paragraph is a CPS, > then I think the language makes less sense. A CPS cannot meaningfully be > "inconsistent" with a CP such as the BRs: it is a descriptive document, not > a prescriptive document, so any discrepancies are in fact violations of > that CP, not merely inconsistencies. > > Speaking from personal experience, I can say that Let's Encrypt publishes > a combined CP/CPS, uses the suggested paragraph to incorporate the Baseline > Requirements (a CP) by reference, and then the rest of the document is > basically a CPS. Some other CAs appear to include the suggested paragraph > directly in their CPS, even when they have a separate CP document. > > My two concrete questions are the following: > > 1. Do others agree that, given the descriptive nature of a CPS, it is not > meaningful for a CPS to have an inconsistency with the BRs, nor for the BRs > to "take precedence" over a CPS? > > 2. Do others agree that the BRs should be amended to suggest slightly > different language, and in fact to suggest two different paragraphs for > inclusion in CP vs CPS documents respectively? > > Thanks, > 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 on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/fe30e72e-e546-4c62-9eab-7c7afa265793n%40mozilla.org.
