cabforum / servercert

Repository for the CA/Browser Forum Server Certificate Chartered Working Group
https://cabforum.org/working-groups/scwg/
134 stars 105 forks source link

Technically constrained subordinate CA certificate definition #492

Open barrini opened 6 months ago

barrini commented 6 months ago

In the TLS BRs, we can find the following definition: Technically Constrained Subordinate CA Certificate: A Subordinate CA certificate which uses a combination of Extended Key Usage and/or Name Constraint extensions, as defined within the relevant Certificate Profiles of this document, to limit the scope within which the Subordinate CA Certificate may issue Subscriber or additional Subordinate CA Certificates. (emphasis mine)

That indicates that for a subCA to be technically constrained, the combination could be: EKU, name constraint or EKU+name constraint

In section 7.1.2, we have some specific sub-sections for technically constrained subCAs: 7.1.2.3 for non-TLS subCA (we may review if this sub-section is needed considering that the BRs are now specific for TLS) 7.1.2.4 for precertificate 7.1.2.5 for TLS All these come with EKU is a MUST and the first two, name constraint is a MAY and in 7.1.2.5 is a MUST.

But, in section 7.1.2.6, which is for non-constrained TLS subCA, the EKU is also a MUST (see 7.1.2.6.1) and the name constraint is a MAY (same as in 7.1.2.3 and 7.1.2.4)

So, according to the definition, basically all subCAs are technically-constrained because of the "or". Thoughts?

I think the easiest way to solve this is by removing the "or" from the definition.

barrini commented 6 months ago

And change the MAY with a MUST in sections 7.1.2.3 and 7.1.2.4 if they want to be considered technically constrained