Baseline Requirements: Clarify the requirements about subCAs with a CABF OID in the CP

[sleevi]

In Section 7.1.6.1 of the Baseline Requirements, it reads as follows: https://github.com/cabforum/documents/blob/6e0b8e61590164eb2d686ddcf266b189f46fc636/docs/BR.md#L1803-L1807
and
https://github.com/cabforum/documents/blob/6e0b8e61590164eb2d686ddcf266b189f46fc636/docs/BR.md#L1812
and
https://github.com/cabforum/documents/blob/6e0b8e61590164eb2d686ddcf266b189f46fc636/docs/BR.md#L1818

In effect, if a certificate asserts a DV OID, then it MUST NOT contain an organizationName. Similarly, if it asserts an OV OID, then it MUST contain an organizationName.

As stated in Section 7.1.6.1, these requirements apply to Root CAs, Subordinate CAs, and End-Entity certificates. However, this requirement prevents a Subordinate CA certificate from explicitly listing both the DV OID and the OV OID, which it's required to to do if it wishes to issue both DV and OV certificates.

Normally, this would be handled by having the subordinate CA use the anyPolicy OID. However, this is prohibited by Section 7.1.6.3 if the Subordinate CA is cross-certified or independently operated, as it reads:
https://github.com/cabforum/documents/blob/6e0b8e61590164eb2d686ddcf266b189f46fc636/docs/BR.md#L1824-L1827

To resolve this, one approach would be to move the initial sentence of 7.1.6.1 into 7.1.6, and then clarify that the remainder of the OIDs' description are statement about the End Entity certificates and that CAs bearing the OIDs are subject to the overall BRs, but not necessarily with respect to the Subject profiles (which are dealt with in Section 7.1.4)

[techliaison]

The way I read it the final paragraph in 7.1.6.1 with its references to 7.1.4.2.2 already makes it clear that that section is about the name requirements in subscriber certs associated with the different policy OIDs and not the subject name of the CA certificates. In addition when cert policies are asserted in a CA certificate it is about what policies that CA can assert in the certificates it issues which is why it can contain one or more of the CABF policy OIDs, but you would not put more than one in the subscriber certificate.

[sleevi]

@techliaison I don't think the existing language can be read the way you describe, although I agree, that's the intent (and why I wanted to file this issue)

The references to Section 7.1.4.2.2 are specific to certain fields, and so you can't read it as saying organizationName (if required) just because it effectively says that for localityName

With respect to Certificate Policies in CA certificates, there is relevance here to the BRs, because if the CA is asserting that it issues certificates that conform to the BRs, it's also by very definition asserting that it also complies with the BRs, since a subscriber certificate cannot conform to the BRs if its parent does not also.

[dougbeattie]

As @sleevi mentioned above, the current requirement prevents a Subordinate CA certificate from explicitly listing both the DV OID and the OV OID, which it's required to to do if it wishes to issue both DV and OV certificates.

To go a step further, this requirement prohibits the inclusion of the DV Policy OID into CA certificates, so any/all CAs that assert the DV Policy OID are in technical violation of this requirement. There are quite a few:

https://censys.io/certificates/report?field=parsed.issuer.common_name.raw&max_buckets=10&q=parsed.extensions.basic_constraints.is_ca%3A+yes+and+parsed.extensions.certificate_policies.id%3A+2.23.140.1.2.1

[GreatAmus]

There is one more section that plays into this. Section 7.1.4.3 requires the organizationName in the cert. Since you can't include the DV OID in the cert and an orgnaizationName in cert, if this isn't applied only to end entity certs you can't create any ICAs limited to DV. The only choice you have is anyPolicy.

[timfromdigicert]

I'll add this to the Validation Subcommittee agenda for this week. We should be able to resolve this relatively easily.

[sleevi]

No need. It's already part of the cleanups and clarifications, as I flagged this on the validation list back in May and we had some discussion about it.

[sleevi]

Specifically, see 7.1.6.4 in sleevi#12 which had discussion previously on the list ("Sub-CAs and CP policy OIDs") and in sleevi#21