BR Certificate Policy OIDS are no longer optional

As of 2020-09-30, certificates must contain one of the CABF reserved policy OIDs [7.1.6.4].

There's a bunch of text left behind in various places asserting they are optional, which contradicts the requirement and may mislead people. For example, in section 1.2 ("reserved for use by CAs as an optional means of asserting compliance...") and 7.1.6.1 ("reserved for use by CAs as an optional means of asserting ..."). These can be fixed simply by removing the assertion that the OID is optional.

It's also not clear that section 1.2 is an appropriate place to reserve policy OIDs; it would probably be better if the entire situation were just accurately explained in the appropriate location (7.1.6). So removing the text from 1.2 entirely might be a nice fix while we're there.

@timfromdigicert I intentionally left those in with the cleanup, because they are about the CA-defined OIDs.

That is, it explicitly exists to make it clear CAs can assert their own OIDs in addition to the required OIDs.

I’m also not sure why you suggest Section 1.2 isn’t appropriate. That is traditionally where a CP lists the document OID that certificates will assert. The duplication in 7.1.6 is necessary due to the field requirements that go with the OIDs, but those will be obviated by the profiles work.

So I don’t think any of these changes are necessary, but happy to find out I’m overlooking something!

I agree with @timfromdigicert that the word optional in sections 1.2 and 7.1.6.1 can be misleading. SC31 now makes it mandatory that one of the CABF reserved OIDs must be included in certificates, so they are mandatory (i.e., not optional).

@CBonnell I’m not sure, but your reply doesn’t add new information for consideration. I can understand and appreciate that you’re looking from the perspective of “As a CA participating in a root program that requires BR compliance, this is not optional for us”. However, such a reply overlooks “As a CA not yet in a root program, or never planning to be, this is the OID to assert compliance with these BRs” (i.e. the point of any policy document).

Put differently, this is a chicken and egg problem, and the current language attempts to resolve which came first. The inclusion of the OID voluntarily by a CA comes first, which indicates their intent to follow the policy of the BRs, which then makes the OID mandatory from then on.

However, such a reply overlooks “As a CA not yet in a root program, or never planning to be, this is the OID to assert compliance with these BRs” (i.e. the point of any policy document).

Yes, and they are not optional. Stating that they are optional does everyone a disservice, from current WTBR CAs to Relying Parties who may be currently hesitant to use the CABF policy OIDs to determine a given certificate's compliance with the BRs and level of assurance.

Additionally, this is the first I'm hearing of this "chicken and the egg problem". Stating definitively that certificates within a given PKI will contain at least a predefined set of OIDs is clearly explained in section 3.1 of RFC 3647.

Yes, and they are not optional. Stating that they are optional does everyone a disservice, from current WTBR CAs to Relying Parties who may be currently hesitant to use the CABF policy OIDs to determine a given certificate's compliance with the BRs and level of assurance.

That seems an incredibly dismissive view of the intelligence and capability of CAs and relying parties to suggest that such confusion exists.

Additionally, this is the first I'm hearing of this "chicken and the egg problem".

I'm quite surprised, since "The BRs are voluntary" has been discussed at tremendous length in the CA/Browser Forum. Perhaps it predates your regular involvement, but it's no different than stating that "CAs voluntarily request to be added/removed from Root Programs", which I should hope is uncontroversial for you.

Stating definitively that certificates within a given PKI will contain at least a predefined set of OIDs is clearly explained in section 3.1 of RFC 3647.

I'm hoping you can more concretely back that up with text you believe supports this comment? I think we're in violent agreement that a CP asserts compliance with the BRs, but I think we're in disagreement about the instrument of normative force.

Put differently, if I create "Honest Sleevi's Used CA and Certificate Emporium", there is no normative force to require that I use the BR OID in any of my certificates. I could fully avoid any participation in any root program (after all, it's just for my organization), while indicating compliance with (and audits against) the Baseline Requirements.

The question about whether or not the OID is optional, within CP, is not an imposition of the BRs. It's an imposition of Root Programs requiring compliance with the BRs for the CAs they recognize. Nothing prohibits a CA they do not recognize from also complying with the BRs. The significance of the language is it seems that you and @timfromdigicert would like it based on intent: that is, the moment I "intend" to comply with the BRs, I'm now required to use the BR OIDs. As Section 3.1 of RFC 3647 makes clear (particularly with respect to the last two paragraphs within that section), it's not about the 'intent' in the abstract: it's from the point of commitment to conform and assessment of conformance, which are voluntary.

People who don't comply with the BRs can put whatever they want in their certs, and it may / may not assert compliance with the BR requirements. We can't tell because there are no requirements. This is true even if they put in an OID that the BRs say means asserting compliance with the BRs. This is because, as they are out of scope for the BRs, they can use it to mean "I like cheese."

Within the scope of the BRs, regardless of who is or isn't mandating compliance with them, the situation is different, because there are requirements. One of the requirements is the use of at least one CABF OID (for EEs, at least).

So within the scope of the BRs, the use of the CABF OIDs is no longer optional. The text of the BRs should reflect that, instead of contradicting it. Not sure what the point is of pushing back on improving the accuracy of the BR language.

@timfromdigicert Perhaps you and Corey can have a chance to discuss in-house at DigiCert, because it would appear you two are arguing quite contradictory positions to try and reach the same conclusion, and I doubt one reply can satisfy both of you.

You're arguing here that the OIDs are meaningless unless and until someone enforces them, while Corey's arguing from the perspective of RFC 3647 in which the OIDs are meaningful precisely because you include them. I don't think both positions can be reasonably and rationally held.

I understand where you're coming from, which is that without a compliance assessment against the BRs CP, you have no assurance of compliance with the BRs CP. But that's not the scenario I described, so I'm not sure if you're intentionally misrepresenting or simply misunderstanding. To try and help you understand, I think it's worth asking: "Can a CA be audited against the BRs without any Root Program requiring it", and I think we'd both agree that yes, that's entirely a thing you can do, and entirely something the CA can voluntarily do.

Within the scope of the BRs, we both agree that the OIDs are mandatory. However, what I'm trying to highlight and emphasize is that compliance with the BRs is optional, and is signalled by inclusion of the OIDs, ergo, the OIDs are optional until you assert them, and then they're required. I realize this might seem subtle, but it's absolutely essential to understanding the role and relationship of a CP such as the BRs, CAs, and browser policy. CAs are not mandated to comply to the BRs by any external force or situation, just like anyone can be a CA and doesn't have to request Root Program inclusion. These are voluntary acts, that, when a CA pursues them, triggers mandatory obligations. It's important to highlight that there is such a distinction, and a wide variety of policies reflect that compliance against a CP is either contractually stipulated (and that contract voluntarily entered) or voluntarily embraced by the CA.

Yes, and they are not optional. Stating that they are optional does everyone a disservice, from current WTBR CAs to Relying Parties who may be currently hesitant to use the CABF policy OIDs to determine a given certificate's compliance with the BRs and level of assurance.

That seems an incredibly dismissive view of the intelligence and capability of CAs and relying parties to suggest that such confusion exists.

This seems like you're arguing that the passage is poorly worded but no one will get tripped up by it because they will know better. If I'm a software developer looking to consume WebPKI certificates, I won't know that the CABF OID is actually required until I dig down into the certificate profile details. I don't think that level of non-discoverability is something that we should accept for the BRs.

Additionally, this is the first I'm hearing of this "chicken and the egg problem".

I'm quite surprised, since "The BRs are voluntary" has been discussed at tremendous length in the CA/Browser Forum. Perhaps it predates your regular involvement, but it's no different than stating that "CAs voluntarily request to be added/removed from Root Programs", which I should hope is uncontroversial for you.

Yes, no one is forced to comply with the BRs. Following the line of reasoning that "the BRs are voluntary", then we should be declaring all requirements within the BRs as optional as we don't want to obligate everyone to these requirements.

Stating definitively that certificates within a given PKI will contain at least a predefined set of OIDs is clearly explained in section 3.1 of RFC 3647.

I'm hoping you can more concretely back that up with text you believe supports this comment? I think we're in violent agreement that a CP asserts compliance with the BRs, but I think we're in disagreement about the instrument of normative force.

Put differently, if I create "Honest Sleevi's Used CA and Certificate Emporium", there is no normative force to require that I use the BR OID in any of my certificates. I could fully avoid any participation in any root program (after all, it's just for my organization), while indicating compliance with (and audits against) the Baseline Requirements.

Sure, but your PKI isn't compliant with the BRs because it issues certificates that violate the certificate profile. You can declare that your PKI is compliant, but that doesn't mean that it actually is. Nor do I see it useful to accommodate such PKIs in drafting the language in the BRs.

The question about whether or not the OID is optional, within CP, is not an imposition of the BRs. It's an imposition of Root Programs requiring compliance with the BRs for the CAs they recognize. Nothing prohibits a CA they do not recognize from also complying with the BRs. The significance of the language is it seems that you and @timfromdigicert would like it based on intent: that is, the moment I "intend" to comply with the BRs, I'm now required to use the BR OIDs. As Section 3.1 of RFC 3647 makes clear (particularly with respect to the last two paragraphs within that section), it's not about the 'intent' in the abstract: it's from the point of commitment to conform and assessment of conformance, which are voluntary.

Section 7.1.6 makes it clear that the CABF OIDs are required. Nonetheless, I think the primary reason for our disconnect is that currently BR section 1.2 doesn't really meet the expectation laid out in RFC 3647, section 4.1.2. Namely, section 4.1.2 states that the CP state its names (either human-readable or OIDs) in this section without any further provision on opining how the names are to be used. However, the BRs take it beyond that and attempt to opine on how CAs assert such information in the CP extension. We can probably clear up a lot of this by modifying section 1.2 to merely state the document name and the associated OIDs for the document without opining on how the OIDs are asserted by CAs, especially since the certificate profile is supposed to cover that concern.

This seems like you're arguing that the passage is poorly worded but no one will get tripped up by it because they will know better. If I'm a software developer looking to consume WebPKI certificates, I won't know that the CABF OID is actually required until I dig down into the certificate profile details. I don't think that level of non-discoverability is something that we should accept for the BRs.

I'm not even arguing it's poorly worded? And I'm trying to understand how someone could mess this up, given the profiles. This bug feels like saying "Shibboleth is hard to pronounce for Ephraimites, so we should change the word we use"

Yes, no one is forced to comply with the BRs. Following the line of reasoning that "the BRs are voluntary", then we should be declaring all requirements within the BRs as optional as we don't want to obligate everyone to these requirements.

This is, again, a nonsense argument. The CP OID is literally the one thing that indicates voluntary compliance, as discussed in RFC 3647. It is what gives every other requirement is normative force, and it's something the CA voluntarily enters into by including. That's literally the purpose of CP OIDs, and you seem to be either ignoring or misrepresenting this.

I'm hoping you can more concretely back that up with text you believe supports this comment? I think we're in violent agreement that a CP asserts compliance with the BRs, but I think we're in disagreement about the instrument of normative force. Put differently, if I create "Honest Sleevi's Used CA and Certificate Emporium", there is no normative force to require that I use the BR OID in any of my certificates. I could fully avoid any participation in any root program (after all, it's just for my organization), while indicating compliance with (and audits against) the Baseline Requirements.

Sure, but your PKI isn't compliant with the BRs because it issues certificates that violate the certificate profile. You can declare that your PKI is compliant, but that doesn't mean that it actually is. Nor do I see it useful to accommodate such PKIs in drafting the language in the BRs.

This doesn't make sense, and I can only suspect you've misunderstood the example. At no point did I say "it issues certificates that violate the certificate profile". My point was that you can be BR compliant independent of any root program, and that's a voluntary decision.

This is essential to understanding the relationship of the BRs, CAs, and Root Programs. I can understand why, if you don't understand the importance of that, it's tempting to suggest removing it, but there's a difference between "not having a purpose" and "not understanding the purpose".

Section 7.1.6 makes it clear that the CABF OIDs are required. Nonetheless, I think the primary reason for our disconnect is that currently BR section 1.2 doesn't really meet the expectation laid out in RFC 3647, section 4.1.2. Namely, section 4.1.2 states that the CP state its names (either human-readable or OIDs) in this section without any further provision on opining how the names are to be used. However, the BRs take it beyond that and attempt to opine on how CAs assert such information in the CP extension. We can probably clear up a lot of this by modifying section 1.2 to merely state the document name and the associated OIDs for the document without opining on how the OIDs are asserted by CAs, especially since the certificate profile is supposed to cover that concern.

I think it's pretty critical, in the introduction, to clarify how these policies apply. It's entirely within the scope of Introductions to understand the relationship and parties involved, and the fact that CAs voluntarily comply with this is a pretty necessary component of understanding exactly how the Web PKI works. That non-PKI participants are confused by this is exactly why it benefits from reinforcement.

This seems like you're arguing that the passage is poorly worded but no one will get tripped up by it because they will know better. If I'm a software developer looking to consume WebPKI certificates, I won't know that the CABF OID is actually required until I dig down into the certificate profile details. I don't think that level of non-discoverability is something that we should accept for the BRs.

I'm not even arguing it's poorly worded? And I'm trying to understand how someone could mess this up, given the profiles. This bug feels like saying "Shibboleth is hard to pronounce for Ephraimites, so we should change the word we use"

The passage currently reads:

The following Certificate Policy identifiers are reserved for use by CAs as an optional means of asserting compliance with this document (OID arc 2.23.140.1.2) as follows:

The way I interpret this, it's stating that CAs can optionally assert their compliance with the CABF OIDs. In other words, there are a plurality of ways CAs can assert compliance in a Certificate Policies extension, and using the reserved CABF OIDs is just one such accepted (but not required) way to do so. I believe this is the natural interpretation of "optional means", but it seems you're arguing that "optional" here is referring to the voluntary action of the CA to comply with the BRs? Is that accurate?

Yes, no one is forced to comply with the BRs. Following the line of reasoning that "the BRs are voluntary", then we should be declaring all requirements within the BRs as optional as we don't want to obligate everyone to these requirements.

This is, again, a nonsense argument. The CP OID is literally the one thing that indicates voluntary compliance, as discussed in RFC 3647. It is what gives every other requirement is normative force, and it's something the CA voluntarily enters into by including. That's literally the purpose of CP OIDs, and you seem to be either ignoring or misrepresenting this.

I fully understand that the CA voluntarily complies and asserts their compliance by asserting a given OID, as mentioned in 3647. But as I mentioned above, I don't think the current language in section 1.2 currently conveys that point.

I'm hoping you can more concretely back that up with text you believe supports this comment? I think we're in violent agreement that a CP asserts compliance with the BRs, but I think we're in disagreement about the instrument of normative force. Put differently, if I create "Honest Sleevi's Used CA and Certificate Emporium", there is no normative force to require that I use the BR OID in any of my certificates. I could fully avoid any participation in any root program (after all, it's just for my organization), while indicating compliance with (and audits against) the Baseline Requirements.

Sure, but your PKI isn't compliant with the BRs because it issues certificates that violate the certificate profile. You can declare that your PKI is compliant, but that doesn't mean that it actually is. Nor do I see it useful to accommodate such PKIs in drafting the language in the BRs.

This doesn't make sense, and I can only suspect you've misunderstood the example. At no point did I say "it issues certificates that violate the certificate profile". My point was that you can be BR compliant independent of any root program, and that's a voluntary decision.

By excluding the CABF OID, the certificates our hypothetical CA issues are not compliant with the BRs as they violate the certificate profile. It seems you're arguing there's some valid state where a given CA can both assert compliance with the BRs while simultaneously omitting the CABF OIDs. The Treachery of Images comes to mind here.

Section 7.1.6 makes it clear that the CABF OIDs are required. Nonetheless, I think the primary reason for our disconnect is that currently BR section 1.2 doesn't really meet the expectation laid out in RFC 3647, section 4.1.2. Namely, section 4.1.2 states that the CP state its names (either human-readable or OIDs) in this section without any further provision on opining how the names are to be used. However, the BRs take it beyond that and attempt to opine on how CAs assert such information in the CP extension. We can probably clear up a lot of this by modifying section 1.2 to merely state the document name and the associated OIDs for the document without opining on how the OIDs are asserted by CAs, especially since the certificate profile is supposed to cover that concern.

I think it's pretty critical, in the introduction, to clarify how these policies apply. It's entirely within the scope of Introductions to understand the relationship and parties involved, and the fact that CAs voluntarily comply with this is a pretty necessary component of understanding exactly how the Web PKI works. That non-PKI participants are confused by this is exactly why it benefits from reinforcement.

I agree that it's valuable for the parties and their interrelationships to be defined in section 1. However, I don't think section 1.2 is the right place for it since that section is solely intended for document identification. We could clarify the relationships of the PKI Participants in the appropriate subsection for each Participant.

By excluding the CABF OID, the certificates our hypothetical CA issues are not compliant with the BRs as they violate the certificate profile. It seems you're arguing there's some valid state where a given CA can both assert compliance with the BRs while simultaneously omitting the CABF OIDs. The Treachery of Images comes to mind here.

I'm not sure why you're saying "by excluding the CABF OID", or suggesting there is a hybrid state. I've tried to repeatedly address that by emphatically capturing that's a misunderstanding. Merely that every CA organization is free to use the BRs, regardless of whether or not they're required to use the BRs. We're saying the CA/B Forum documents are simply that: A CP that exists as a base framework that can be used and assessed. We know it's not enough for browsers (hence, root store policy), and we know that browsers require compliance and assessment, but that's independent of anything the CA/B Forum or these documents do.

"Here's some good practices. Here's how you can choose to say you're following these good practices. If you choose to say you're following them, here's what's required to do in order to say you follow them." is the essence of what the introduction conveys.

The proposed changes would have it say

"Here's some good practices. This is what these good practices are called. These good practices are all required." which strips out a significant part of relevant information.

cabforum / servercert

BR Certificate Policy OIDS are no longer optional #248