<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 2, 2021 at 4:41 AM Dimitris Zacharopoulos (HARICA) via Validation <<a href="mailto:validation@cabforum.org">validation@cabforum.org</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
    Whether NC is REQUIRED or not for a non-TLS subCA (a Certificate
    with basicConstraints cA:true and EKU extension with KeyPurposeID
    that DOES NOT include <span style="color:rgba(0,0,0,0.87);font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:14px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">anyExtendedKeyUsage<span> </span></span>or
    <span style="color:rgba(0,0,0,0.87);font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:14px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">id-kp-serverAuth</span>) to be
    considered "Technically Constrained", has been clarified at least in
    the <a href="https://groups.google.com/g/mozilla.dev.security.policy/c/f5-URPoNarI/m/PVdH28BFAAAJ" target="_blank">Mozilla
      Root Program since 2016</a>. It is not required.<br>
    <br>
    In fact, HARICA was reading 7.1.5 in the very strict way that Ryan
    is suggesting, and our first Technically Constrained subCAs, even
    those that only had the KeyPurposeId of id-kp-emailProtection, ALSO
    had a NC extension with denied subtrees for dNSName and IPAddress
    values. After discussions with the Mozilla Root store Managers, it
    was determined that it was not necessary to add the NC if the subCA
    had an EKU extension and did not have the id-kp-serverAuth or the
    anyEKU KeyPurposeId for them to be considered Technically
    Constrained.<br></div></blockquote><div><br></div><div>I'm not sure I understand your reply here.</div><div><br>Are you trying to say that CAs are free to ignore the BRs if one root program says so?</div><div><br></div><div>I can understand wanting to talk about what the _future_ requirements should say, but I think the context of what the _current_ requirements require is relevant here, since the concern is the profiles expressing that requirement.</div><div><br></div><div>You will note, for example, that the profiles work is trying to relax this and actually allow the EKU-or-NC. However, it's still requiring that, even if a distinct EKU is present, because it's issued from a BR CA, the certificates the BR CA issues need to be well-formed. That seems to have some concern raised, by Corey, and that's why we're trying to resolve, by making sure we have a correct understanding about what the BRs require, so that we can make sure that the profiles work is properly seen as strictly relaxing, not adding new restrictions.</div></div></div>