[cabf_validation] nameConstraints on technically constrained sub-CAs
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
>> - This certificate is a Subordinate CA Certificate, subject to
>> 184.108.40.206. This should be obvious by 220.127.116.11(g) explicitly applying to such
>> certificates, as well as the explicit language in Section 8.1
>> - Because this Certificate is Subject to 18.104.22.168, it's also
>> subject to 7.1.5, because of 22.214.171.124(h)
>> You probably mean 126.96.36.199(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
> 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 188.8.131.52(g) *also* applies
> to "Subordinate CA Certificates that are *not used to issue TLS
Yes, 184.108.40.206(g) applies to not-TLS. Therefore, 220.127.116.11(f) also applies to
> Hopefully we also agree that 18.104.22.168 also applies to these?
>> - 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.
> I think the overlooking of 126.96.36.199(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 188.8.131.52(h) applies, and that 184.108.40.206 applies.
> 220.127.116.11 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 18.104.22.168(h) (again, not (g)).
This was meant to say 22.214.171.124 (*f*) - that is, to highlight that the
requirements on nameConstraints applies to all not-TLS sub-CAs, just like
126.96.36.199 (*g*) also applies to all not-TLS sub-CAs.
Again, you probably mean 188.8.131.52(g).
> 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
> 184.108.40.206(*f*), 220.127.116.11(*g*), and 18.104.22.168 of the BRs today (and 7.1.5,
> which is referenced by 22.214.171.124(*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:
> - 126.96.36.199(*f*) doesn't apply to non-TLS sub CAs (despite 188.8.131.52(g) being
> clear and explicit it does, and 184.108.40.206 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...
More information about the Validation