[cabf_validation] nameConstraints on technically constrained sub-CAs

[Ryan Sleevi]

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?
   - 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)
      - 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)

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?

The reason is because the sub-CA can issue more sub-CAs. So let's imagine
we slap a pathLenConstraint=0 on the certificate, as an attempt to prevent
further sub-CAs. Unfortunately, as discussed in RFC 5280, Section 4.2.1.9
<https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.9>, this
doesn't actually prevent issuing subCA certificates - it just prevents
non-self-issued Sub-CAs. That is, it exists to permit situations such as a
key rollover. A key rollover certificate (that is, same subject, different
SPKI) is still a new CA certificate, and still subject to the requirements
here.

So even if your understanding of "Subscriber Certificate" is correct, it
doesn't seem to change the conclusion here that id-kp-emailProtection as an
EKU alone is not sufficient to meet the definition of Technically
Constrained Subordinate CA Certificate in 1.6.1, even if we assume that #10
- #13 in
https://archive.cabforum.org/pipermail/validation/2021-September/001689.html
(that is, the last two paragraphs) should only be read for certificates
that have an id-kp-emailProtection.

Regarding 7.1.2.4, I'm not sure which part you assume I am ignoring. Is it
> the part about RFC 5280 requirements for well-formed fields?
>
> I read your email in
> https://archive.cabforum.org/pipermail/validation/2021-September/001689.html
>
> but the discussion about 7.1.2.4 is probably not so clear to me. I will
> try to re-read it and hopefully see your points clearer.
>

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210902/58f9945f/attachment-0001.html>