[cabf_validation] nameConstraints on technically constrained sub-CAs

Wed Sep 8 17:01:31 UTC 2021

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
>       o It must comply with RFC 5280 (because 7.1.2.4 applies to ALL
>         Certificates)
>       o 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.

>   * If I issue a certificate with basicConstraints=CA:true, and
>     id-kp-emailProtection
>       o 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
>       o 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.

>       o 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. 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.

> 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.

Noted that RFC-5280-only implementations will probably ignore the EKU in 
the CA Certificate, but the BRs are applying rules on top of RFC 5280 
and make certain assumptions like the need for digitalSignature KU in 
the CA Certificate to issue an OCSP response, which is not currently 
enforced by most RFC 6960 implementations.

>
> 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 
> <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
>     <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.
>

Again, you probably mean 7.1.2.2(g).

> 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
>       o 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.

Once the non-TLS subCA has been issued, whatever actions that non-TLS 
subCA  does as an Issuer, is out of BRs scope. An interpretation that 
docSigning, S/MIME, clientAuth-only subCAs are subject to the BRs as 
Issuers, and must be audited according to the BRs, sounds unreasonable 
to me.

During the delegated OCSP responder incidents, we had cases where 
non-TLS subCAs had the id-kp-ocspSigning KeyPurposeId in their EKU 
extension. This was creating a risk to the Root that issued those 
non-TLS subCAs. It was well recognized that even-though these non-TLS 
subCAs were out of BRs scope (as Issuers), the fact that they were 
issued by Roots that were in-scope of the BRs enabled the revocation 
requirements for those non-TLS subCAs.

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.

Again, this is my personal interpretation of the BRs as far as scope is 
concerned and I would like to welcome other Members (CAs and Browsers) 
to share theirs. I will also try to be on the validation subcommittee 
call tomorrow.

Thanks,
Dimitris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210908/95d369c5/attachment.html>