[cabf_validation] nameConstraints on technically constrained sub-CAs

[Ryan Sleevi]

On Wed, Sep 8, 2021 at 1:56 PM Corey Bonnell <Corey.Bonnell at digicert.com>
wrote:

> > Mozilla allows this. The BRs don't.
>
>
>
> The language in section 7.1.5 was introduced in Ballot 105 [1] and has
> remained unchanged since the ballot was initially adopted in July 2013.
> This language in 7.1.5 was taken directly from Mozilla Policy 2.1 [2],
> which came into effect in February 2013. Despite this clear history of the
> intent and shared understanding of the language, you’re asserting that the
> language actually has a different meaning these past 8 years and that CAs
> must include the NC extension in CA certificates that don’t contain the
> serverAuth EKU?
>

The language seems unambiguous that it MUST be present if:

   - If the Subordinate CA Certificate is not allowed to issue certificates
   with an iPAddress, then the Subordinate CA Certificate MUST specify the
   entire IPv4 and IPv6 address ranges in excludedSubtrees.
   - If the Subordinate CA is not allowed to issue certificates with
   dNSNames, then the Subordinate CA Certificate MUST include a zero-length
   dNSName in excludedSubtrees.

Further, if you wish to be exempt from audit requirements, then you MUST be
Technically Constrained ("in line with Section 9.7")
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210908/80b9cfa1/attachment.html>