[cabf_validation] nameConstraints on technically constrained sub-CAs

[Ryan Sleevi]

On Wed, Sep 8, 2021 at 1:01 PM Dimitris Zacharopoulos (HARICA) <
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> 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/12e25287/attachment-0001.html>