[cabf_validation] nameConstraints on technically constrained sub-CAs
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
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
> o It must comply with RFC 5280 (because 22.214.171.124 applies to ALL
> 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
> o This certificate is a Subordinate CA Certificate, subject to
> 126.96.36.199. This should be obvious by 188.8.131.52(g) explicitly
> applying to such certificates, as well as the explicit
> language in Section 8.1
> o Because this Certificate is Subject to 184.108.40.206, it's also
> subject to 7.1.5, because of 220.127.116.11(h)
You probably mean 18.104.22.168(g), yes we are in agreement.
> o This certificate is also subject to 22.214.171.124, 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 126.96.36.199, and 188.8.131.52, 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 184.108.40.206
> <https://datatracker.ietf.org/doc/html/rfc5280#section-220.127.116.11>, 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
> (that is, the last two paragraphs) should only be read for
> certificates that have an id-kp-emailProtection.
> Regarding 18.104.22.168, 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
> but the discussion about 22.214.171.124 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: 126.96.36.199 and 188.8.131.52(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 184.108.40.206(g).
> I'm trying to highlight that:
> * The BRs currently place rules on /all/ Certificates issued by a BR
> compliant CA (220.127.116.11)
> * The rules in 18.104.22.168 currently apply to /all/ Subordinate CA
> certificates (as evidenced by 22.214.171.124(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
> 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 126.96.36.199
> 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 188.8.131.52g, 184.108.40.206, 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
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
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 220.127.116.11 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Validation