[cabf_validation] nameConstraints on technically constrained sub-CAs

Ryan Sleevi sleevi at google.com
Wed Sep 8 17:53:14 UTC 2021

Gah, I really do fail :)

On Wed, Sep 8, 2021 at 1:36 PM Ryan Sleevi via Validation <
validation at cabforum.org> wrote:

>>    - If I issue a certificate with basicConstraints=CA:true, and
>>    id-kp-emailProtection
>>       - This certificate is a Subordinate CA Certificate, subject to
>> This should be obvious by explicitly applying to such
>>       certificates, as well as the explicit language in Section 8.1
>>       - Because this Certificate is Subject to, it's also
>>       subject to 7.1.5, because of
>> You probably mean, 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 *also* applies
> to "Subordinate CA Certificates that are *not used to issue TLS
> certificates*".

Yes, applies to not-TLS. Therefore, also applies to

> Hopefully we also agree that also applies to these?
>>    - This certificate is also subject to, 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 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 applies, and that applies.

> 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 (again, not (g)).

This was meant to say (*f*)  - that is, to highlight that the
requirements on nameConstraints applies to all not-TLS sub-CAs, just like (*g*) also applies to all not-TLS sub-CAs.

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

And then make embarrassing mistakes despite having the page right open and

> 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
>*f*),*g*), and of the BRs today (and 7.1.5,
> which is referenced by*f*)). 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:
> -*f*) doesn't apply to non-TLS sub CAs (despite being
> clear and explicit it does, and 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 :)

Corrected inline and *bolded*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210908/1ab6b659/attachment.html>

More information about the Validation mailing list