[cabf_validation] nameConstraints on technically constrained sub-CAs

[Ryan Sleevi]

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
>>       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)
>>
>>
>> You probably mean 7.1.2.2(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
> (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 7.1.2.2(g) *also* applies
> to "Subordinate CA Certificates that are *not used to issue TLS
> certificates*".
>

Yes, 7.1.2.2(g) applies to not-TLS. Therefore, 7.1.2.2(f) also applies to
not-TLS.


>
> Hopefully we also agree that 7.1.2.4 also applies to these?
>
>
>>
>>    - 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.
>>
>
> I think the overlooking of 7.1.2.2(h) may explain this confusion.
>

s/h/g/


>
>
>> 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 7.1.2.2(h) applies, and that 7.1.2.4 applies.
>

7.1.2.2(g)


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

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

Again, you probably mean 7.1.2.2(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
double-checking.


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