[cabf_validation] nameConstraints on technically constrained sub-CAs

Wed Sep 8 17:56:16 UTC 2021

Hi Ryan,

Comments inline.

> No, I meant (h). My point of highlighting (h) is that it's very clear that the scope of the BRs _also_ includes, today, "Subordinate CA certificates that are not used to issue TLS certificates". It's the last paragraph of (h).

I share Dimitris’s confusion. BR 1.8.0 7.1.2.2 (h) describes the requirements of the AKID extension. I don’t see how the AKID specification is relevant to this discussion.

> Mozilla allows this. The BRs don't.

The language in section 7.1.5 was introduced in Ballot 105 [1] and has remained unchanged since the ballot was initially adopted in July 2013. This language in 7.1.5 was taken directly from Mozilla Policy 2.1 [2], which came into effect in February 2013. Despite this clear history of the intent and shared understanding of the language, you’re asserting that the language actually has a different meaning these past 8 years and that CAs must include the NC extension in CA certificates that don’t contain the serverAuth EKU?

Thanks,

Corey

[1] https://cabforum.org/2013/07/29/ballot-105-technical-constraints-for-subordinate-certificate-authorities-yielding-broader-and-safer-pki-adoption/

[2] https://wiki.allizom.org/CA:CertInclusionPolicyV2.1

From: Validation <validation-bounces at cabforum.org> On Behalf Of Ryan Sleevi via Validation
Sent: Wednesday, September 8, 2021 1:36 PM
To: Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>
Cc: CABforum3 <validation at cabforum.org>
Subject: Re: [cabf_validation] nameConstraints on technically constrained sub-CAs

On Wed, Sep 8, 2021 at 1:01 PM Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr <mailto:dzacharo at harica.gr> > wrote:

On 2/9/2021 10:46 μ.μ., Ryan Sleevi wrote:

On Thu, Sep 2, 2021 at 3:12 PM Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr <mailto:dzacharo at harica.gr> > wrote:

When you are discussing about 1.6.1 I assume you are referring to the definition of 

"Technically Constrained Subordinate CA Certificate: A Subordinate CA certificate which uses a combination of Extended Key Usage settings and Name Constraint settings to limit the scope within which the Subordinate CA Certificate may issue Subscriber or additional Subordinate CA Certificates."

Let me first state that I am not a native English speaker and my reading could have some obvious errors for which I would hope the native English speakers will correct :)

When it comes to Subscriber Certificates the scope of the BRs are server TLS Certificates. Therefore the definition applies to "within which the Subordinate CA Certificate may issue Subscriber or additional Subordinate CA Certificates", which points to the TLS technically constrained subCAs for which a combination of EKU AND NC is required, as described in 7.1.5.

Thanks for clarifying your interpretation. This would seem to suggest that you support the following conclusions:

*	If I issue a certificate with basicConstraints=CA:false, and id-kp-emailProtection

*	It must comply with RFC 5280 (because 7.1.2.4 applies to ALL Certificates)
*	You would assert that this is a "Certificate, but not a Subscriber Certificate, nor a CA Certificate" - is that a correct understanding of how you sort the definitions?

This certificate would be issued by a non-TLS subCA so I don't think your interpretation is correct. The product of that issuance is out of BRs scope. In my understanding, when the BRs mention "Subscriber Certificates", these are TLS end-entity Certificates.

I think you're conflating two things here, but I think I can understand.

I tried to use the term "Certificate" here, because that's the term 7.1.2.4 used. I can understand you reiterating that you believe "Subscriber Certificate" is only that which contains id-kp-serverAuth or (according to the BRs) id-kp-clientAuth. I'm asking what do you call the thing-that-is-issued that contains id-kp-emailProtection? 7.1.2.4 seems to be consistent that this is a "Certificate" - do you disagree?

*	If I issue a certificate with basicConstraints=CA:true, and id-kp-emailProtection

*	This certificate is a Subordinate CA Certificate, subject to 7.1.2.2. This should be obvious by 7.1.2.2(g) explicitly applying to such certificates, as well as the explicit language in Section 8.1
*	Because this Certificate is Subject to 7.1.2.2, it's also subject to 7.1.5, because of 7.1.2.2(h)

You probably mean 7.1.2.2(g), yes we are in agreement.

No, I meant (h). My point of highlighting (h) is that it's very clear that the scope of the BRs _also_ includes, today, "Subordinate CA certificates that are not used to issue TLS certificates". It's the last paragraph of (h).

Because (h) is clear that it applies to sub-CAs not used to issue TLS certificates, my point (where we seem to agree) is that 7.1.2.2(g) also applies to "Subordinate CA Certificates that are not used to issue TLS certificates".

Hopefully we also agree that 7.1.2.4 also applies to these?

*	This certificate is also subject to 7.1.2.4, because it is a "Subordinate CA Certificate" (because of Section 8.1, as well as the definition of Subordinate CA in Section 1.6.1)

I think you are strangely interpreting 8.1 and extending it for non-TLS subCAs and what those non-TLS subCAs produce. 

I think the overlooking of 7.1.2.2(h) may explain this confusion.

My understanding is that 8.1 invokes the technical restrictions of 7.1.5 and mandates self-audits per section 8.7 only for TLS subCAs. It doesn't make any sense for the BRs to require self-audits for a non-TLS subCA that is technically restricted by not having the id-kp-serverAuth EKU, that signs -say- Time-Stamping or Code Signing Certificates.

It does, if we say 7.1.2.2(h) applies, and that 7.1.2.4 applies.

7.1.2.4 states the scope is All Certificates. It appears you're treating this narrowly, as "All certificates that can issue or be used as Subscriber certificates", but that's not what it says. Such an interpretation also wouldn't be consistent with 7.1.2.2(h) (again, not (g)).

Equally, Section 8.1 seems 100% unambiguous what the scope is. It specifically defines what "capable of being used to issue new certificates" as, and it seems you're reading additional restrictions that are not stated.

Here's where things get messy: A certificate with basicConstraints=CA:true and id-kp-emailProtection is a CA Certificate that "within which the Subordinate CA Certificate may issue Subscriber or additional Subordinate CA Certificates". That is, because this sub-CA can further issue additional subject CAs, it's a Subordinate CA that is in scope of 7.1.2.2, and 7.1.2.4, and thus, it is not Technically Constrained unless it has both "a combination of Extended Key Usage settings and Name Constraint settings".

Do you see how that conclusion is reached, even if what the Subordinate CA issues aren't TLS certificates?

I don't, because the BRs assume that the EKU is an effective technical measure for trust-building so if a second-level subCA has id-kp-emailProtection and issues a subordinate that has id-kp-serverAuth, the produced end-entity certificates out of that last subCA should not be trusted because it would be blocked by the first subCA issued by the Root which is the Trust Anchor.

No, the BRs don't assume this, nor do Root Programs, most notably, Apple's, not when it comes to Root Program compliance. I'm saying there's no text in the BRs to support this interpretation of id-kp-emailProtection sub-CAs being the cut-off point.

I am trying to introduce such language in the BRs, which is strictly relaxing the requirements, but that's not the current requirement. Corey raised the concern that he believed I was introducing new stricter requirements, and I'm trying to point out how our existing BRs are _more_ strict than the profiles work, or understand what language folks currently believe the BRs to carve things out, to make sure we address it.

Yes. The context here, to make sure it's clear, is the suggestion that if a subordinate CA has an "id-kp-emailProtection", the BRs don't apply to it (hopefully it's clear they do, re: 7.1.2.4 and 7.1.2.2(h)) and that it would be a change in existing requirements to say the BRs do apply, and that the fields must be well-formed. 

Again, you probably mean 7.1.2.2(g).

Again, I don't :) You know me, I try to be very explicit and precise, especially in these disagreements :)

I'm trying to highlight that:

*	The BRs currently place rules on all Certificates issued by a BR compliant CA (7.1.2.4)
*	The rules in 7.1.2.2 currently apply to all Subordinate CA certificates (as evidenced by 7.1.2.2(h)), regardless of EKU
*	That, regardless of EKU, as it stands today in the BRs, a sub-CA is not technically constrained unless it has both EKU and nameConstraints

*	This is because a sub-CA can always issue more sub-CAs. If pathLenConstraint isn't present, or is greater than zero, then they can issue any type of sub-CA. If pathLenConstraint is present, and is zero, they can still issue self-issued sub-CAs, which are still sub-CAs.

The question/concern raised by Corey is whether or not the BRs can/should have an opinion about what the contents of a dNSName nameConstraint should contain for a certificate that only has id-kp-emailProtection. My belief is the BRs today already express an opinion, but not clearly, and the profiles work is just trying to clarify the existing requirements. It would appear Corey (and again, not trying to misrepresent, so much as capture what I understand) is suggesting that the BRs do not have an opinion today (that 7.1.2.4 doesn't apply, nor do the latter two paragraphs of 7.1.5, nor the definition in 1.6.1), and thus, expressing an opinion is a new, more restrictive requirement.

I mostly agree with Corey on this. My interpretation of the BRs is that they apply to the Issuer. The Issuer is audited for the things it signs. If the Root is subject to the BRs, then the product of that Root, whether it is a TLS subCA or a non-TLS subCA should be in scope (invoking 7.1.2.2g, 7.1.2.4, 7.1.5, 8.1 for the Root as the Issuer). This means that even non-TLS subCA Certificates must be well-formed, must adhere to RFC 5280 rules. My interpretation (and probably the interpretation of Mozilla) of section 7.1.5 is that it allows for a Root to issue a Technically Constrained non-TLS subCA without requiring a NC extension.

Mozilla allows this. The BRs don't.

Where I think we are in agreement is that if, today, the BRs apply to the Issuer, then they apply to everything they sign. 

*	If a TLS capable CA signs a non-TLS sub-CA, then, today, that non-TLS sub-CA is unambiguously subject to 7.1.2.4 in now that non-TLS sub-CA is formed. Do you agree with this?
*	That non-TLS sub-CA is _also_ subject to 8.1 of the BRs. This language is very explicit.

Once the non-TLS subCA has been issued, whatever actions that non-TLS subCA  does as an Issuer, is out of BRs scope. 

Not today. 8.1 is quite clear on that. Similarly, if we agree that 7.1.2.2(h) applies to this non-TLS sub-CA, then we have to agree that 7.1.2.4 applies _at least_ to the profile of this non-TLS sub-CA.

It seems you're arguing that 7.1.2.4 doesn't apply to anything that non-TLS sub-CA issues. I don't think the language in 7.1.2.4 currently supports that conclusion, but I'm hoping you can provide reference to the BRs where/why this is. This is where the distinction of "Certificates" vs "Subscriber Certificates" was coming in - it seems that you're saying that what a non-TLS sub-CA issues isn't a Certificate, but that would conflict with Section 8.1. It seems further you're saying 8.1 doesn't apply to those non-TLS sub-CAs, but the language in 8.1 seems very clear it does.

I also agree and realize that the BRs are silent about the non-TLS CA certificate profile but section 7.1.2.2 seems reasonable to me for non-TLS CA Certificates. It would be nice to clarify these non-TLS CA profiles in the profiles ballot and CAs could check their non-TLS CA profiles chained to the same TLS hierarchies to report possible conflicts. However, we must be sensitive to the fact that, for better or worse, there are still mixed hierarchies in use out there, that are used in non-TLS Internet use cases.

Right, to recap the discussion:

Similar to OCSP responder profile (which is already part of the profiles work, and seemed uncontroversial), there is language about what a non-TLS sub-CA looks like. This language is derived from the requirements of 7.1.2.2(h), 7.1.2.2(g), and 7.1.2.4 of the BRs today (and 7.1.5, which is referenced by 7.1.2.2(h)). Specifically, for non-TLS sub-CAs, it requires that dNS and iPAddress nameConstraints be "well-formed" values (i.e. actual domain names or IP addresses). It further requires that if the non-TLS sub-CA will not issue TLS certificates, then these fields are part of the excludedSubtrees, consistent with the existing 7.1.5 language.

So far, the concern seems to be:

- 7.1.2.2(h) doesn't apply to non-TLS sub CAs (despite 7.1.2.2(g) being clear and explicit it does, and 7.1.2.4 equally seeming to unambiguously apply to everything a BR-compliant CA issues)

- 7.1.5 doesn't actually require these exclusions if they're excluded by EKU, despite such language ("If the Subordinate CA includes the id-kp-serverAuth extended key usage") not appearing in these paragraphs for those requirements.

Where I think you may be missing is that I am trying to get the BRs into the end state you're describing, with the profiles work. But they aren't there right now, and the concern being discussed is how we get there :)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210908/ea120074/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4990 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210908/ea120074/attachment-0001.p7s>