Handling of inconsistencies between BRs, CPs, and CPSes

[Aaron Gable]

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) 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 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, GTS, Entrust, Sectigo CP and CPS) 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 "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", 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

[Wayne]

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

[Mike Shaver]

On Fri, Jun 14, 2024 at 12:44 PM Wayne <rdau...@gmail.com> wrote:

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?

If you’re referring to the CPS forbidding something that the BRs permit but don’t require, then I don’t think there’s a conflict that needs an override order to resolve.

But if the CA puts something in the CPS that conflicts with a BR requirement or proscription, then the BR should take precedence and IMO the CPS should be considered invalid until that conflict is eliminated. I *think* that means that certificates issued under the conflicting CPS would be considered misissued, because the subscriber of relying party might have been relying on an invalid part of the CPS.

Does *that* make some sense?

Mike

[Aaron Gable]

On Fri, Jun 14, 2024 at 9:44 AM Wayne <rdau...@gmail.com> wrote:

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.

I don't think I agree with the interpretation that a CP was a "summary" and a CPS was the "details" -- RFC 3647 clearly draws the line differently, saying that the CP is the what, while the CPS is the how. For example, a CP (like the BRs) might say "you MUST NOT sign using RSASSA-PKCS1-v1_5 with SHA-1", while a CPS might say "we sign only using sha256WithRSAEncryption". Again, the CP is supposed to be prescriptive, while the CPS is supposed to be descriptive.

To be clear, a descriptive document can still place strictures on the CA whose behavior it describes: it's an incident for a CA to act in a way that their CPS does not describe. But I believe that a CPS should not contain RFC 2119-style MUST/SHOULD requirements; it should instead consist of "we do X" statements.

This is the crux of why I believe that the "inconsistency" language doesn't make sense. To me, an inconsistency would be something like the BRs saying "MUST NOT issue for curves other than P256 and P384", while a CA's own CP says "MUST NOT issue for curves other than P244, P256, and P384". The CA's CP appears to allow something that would be inconsistent with the BRs, so instead the BRs take precedence and issuance for P521 is still forbidden.

But if the BRs say "MUST NOT issue for curves other than P256 and P384", while a CA's CPS says "as part of issuance we ensure that the public key in the CSR is a valid point on the P244, P256, or P384 named curves", that's not an inconsistency -- that's saying that the CA actively engages in behavior which is in violation of the Baseline Requirements. That's an incident.

On Fri, Jun 14, 2024 at 9:50 AM Mike Shaver <mike....@gmail.com> wrote:

If you’re referring to the CPS forbidding something that the BRs permit but don’t require, then I don’t think there’s a conflict that needs an override order to resolve.

To put it another way, I don't think a CPS can "forbid" something, though I certainly see why it can be useful to use that phrasing. I think that a CPS describes behavior, and behavior outside of that description is forbidden not by the CPS itself, but by the fact that a CPS is required to be accurate.

Aaron

[Wayne]

On Friday, June 14, 2024 at 6:54:03 PM UTC+1 Aaron Gable wrote:

On Fri, Jun 14, 2024 at 9:44 AM Wayne <rdau...@gmail.com> wrote:

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.

I don't think I agree with the interpretation that a CP was a "summary" and a CPS was the "details" -- RFC 3647 clearly draws the line differently, saying that the CP is the what, while the CPS is the how. For example, a CP (like the BRs) might say "you MUST NOT sign using RSASSA-PKCS1-v1_5 with SHA-1", while a CPS might say "we sign only using sha256WithRSAEncryption". Again, the CP is supposed to be prescriptive, while the CPS is supposed to be descriptive.

Ah we are thinking the same thing we're just using different words. I agree with your interpretation for what it is worth. For those who haven't read RFC 3647 here's the relevant portion from: https://datatracker.ietf.org/doc/html/rfc3647#section-3.5

>The main differences between CPs and CPSs can therefore be summarized as follows:
>
>(a) A PKI uses a CP to establish requirements that state what participants within it must do. A single CA or organization can use a CPS to disclose how it meets the requirements of a CP or how it implements its practices and controls.
>
>(b) A CP facilitates interoperation through cross-certification, unilateral certification, or other means. Therefore, it is intended to cover multiple CAs. By contrast, a CPS is a statement of a single CA or organization. Its purpose is not to facilitate interoperation (since doing so is the function of a CP).
>
>(c) A CPS is generally more detailed than a CP and specifies how the CA meets the requirements specified in the one or more CPs under which it issues certificates.

It is from that part of the RFC that my terms come from. I looked into this over a month ago given how odd it seemed that the WebPKI space used policy differently than other regulated environments. In other places you'd have policy (the descriptive element, or as I call it a summary) -> procedures (how things will actually be implemented, as I call it the details) in a similar vein, therefore the policy part never quite made sense before I saw the RFC.

- Wayne