<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 8, 2021 at 1:56 PM Corey Bonnell <<a href="mailto:Corey.Bonnell@digicert.com">Corey.Bonnell@digicert.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="gmail-m_-76210762699618067WordSection1"><p class="MsoNormal">> Mozilla allows this. The BRs don't.<br></p><p class="MsoNormal"><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">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?</p></div></div></blockquote><div><br></div><div>The language seems unambiguous that it MUST be present if:</div><div><ul><li>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.<br></li><li>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.<br></li></ul><div>Further, if you wish to be exempt from audit requirements, then you MUST be Technically Constrained ("in line with Section 9.7")</div></div></div></div>