<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <br>
    <br>
    <div class="moz-cite-prefix">On 2/9/2021 9:35 ╬╝.╬╝., Ryan Sleevi
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CACvaWvazve5yLcmywizwGEyTdNfFguKBa1uFMR6ejseA-2KGnA@mail.gmail.com">
      <blockquote class="gmail_quote" style="margin:0px 0px 0px
        0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
        <div> The rest of the section describes requirements for Name
          Constraints IF they are required. One can read it as they are
          only required "If the Subordinate CA Certificate includes the
          id-kp-serverAuth extended key usage" because that is clearly
          written in the second paragraph. The intent about NCs is
          unclear for subCAs that do not have the id-kp-serverAuth
          extended key usage.<br>
        </div>
      </blockquote>
      <div><br>
      </div>
      <div>It appears you disagree with the #10 - #13 here. You're
        saying that this section "only" applies for id-kp-serverAuth.</div>
      <div><br>
      </div>
      <div>This is not how this section reads, but it also means you've
        ignored the Section 7.1.2.4 requirements here, as well as those
        in Section 1.6.1. Could you explain why you believe it's OK to
        ignore these?</div>
    </blockquote>
    <br>
    When you are discussing about 1.6.1 I assume you are referring to
    the definition of <br>
    <br>
    "<strong>Technically Constrained Subordinate CA Certificate</strong>:
    A Subordinate CA certificate which uses a combination of Extended
    Key Usage settings and Name Constraint settings to limit the scope
    within which the Subordinate CA Certificate may issue Subscriber or
    additional Subordinate CA Certificates."<br>
    <br>
    Let me first state that I am not a native English speaker and my
    reading could have some obvious errors for which I would hope the
    native English speakers will correct :)<br>
    <br>
    When it comes to <b>Subscriber Certificates</b> the scope of the
    BRs are server TLS Certificates. Therefore the definition applies to
    "within which<b> the Subordinate CA Certificate may issue Subscriber</b>
    or additional Subordinate CA <b>Certificates</b>", which points to
    the TLS technically constrained subCAs for which a combination of
    EKU AND NC is required, as described in 7.1.5.<br>
    <br>
    Regarding 7.1.2.4, I'm not sure which part you assume I am ignoring.
    Is it the part about RFC 5280 requirements for well-formed fields?<br>
    <br>
    I read your email in
<a class="moz-txt-link-freetext" href="https://archive.cabforum.org/pipermail/validation/2021-September/001689.html">https://archive.cabforum.org/pipermail/validation/2021-September/001689.html</a><br>
    <br>
    but the discussion about 7.1.2.4 is probably not so clear to me. I
    will try to re-read it and hopefully see your points clearer.<br>
    <br>
    <blockquote type="cite"
cite="mid:CACvaWvazve5yLcmywizwGEyTdNfFguKBa1uFMR6ejseA-2KGnA@mail.gmail.com">
      <div><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>
          <blockquote type="cite">
            <div dir="ltr">
              <div class="gmail_quote">
                <blockquote class="gmail_quote" style="margin:0px 0px
                  0px 0.8ex;border-left:1px solid
                  rgb(204,204,204);padding-left:1ex">
                  <div>
                    <blockquote type="cite">
                      <div dir="ltr">
                        <div class="gmail_quote">
                          <div>You will note, for example, that the
                            profiles work is trying to relax this and
                            actually allow the EKU-or-NC. </div>
                        </div>
                      </div>
                    </blockquote>
                    <br>
                    If the SCWG is looking it from the server TLS point
                    of view, "technically constrained" should focus on
                    the technical capabilities of validating a trust
                    path that would enable a <b>server TLS</b>
                    end-entity certificate. In the attempt to describe
                    the profiles for TLS and non-TLS issuing CAs, and as
                    the certificate profiles work is trying to clarify,
                    for the first case we should need both EKU
                    (serverAuth) and NC, while for the non-TLS we should
                    constrain with just the EKU (must not include
                    serverAuth or anyEKU).<br>
                  </div>
                </blockquote>
                <div><br>
                </div>
                <div>As mentioned above, that's <b>not</b>┬áreflective
                  in current Browser members applications behave. This
                  is why the current language requires the And, and
                  doesn't say Or. The "id-kp-serverAuth" EE cert from an
                  "id-kp-emailProtection" will validate in RFC 5280-only
                  implementations, and, for Apple's case, will validate
                  in Apple's supported implementations. So yes, it
                  matters :)</div>
              </div>
            </div>
          </blockquote>
          <br>
          The IF statement of the second paragraph has a MUST for the NC
          extension, only if the keyPurposeId is "id-kp-serverAuth".<br>
        </div>
      </blockquote>
      <div><br>
      </div>
      <div>Yes, we're not disagreeing here.</div>
      <div><br>
      </div>
      <div>You appear, however, to be taking that "If" clause to also
        extend to each subsequent paragraph, despite that being contrary
        to the Definition of a Technically Constrained Sub-CA, and
        despite the requirements of 7.1.2.4. I don't understand how or
        why you're reaching that conclusion, other than saying "Well,
        Mozilla did this for their root program", which, again, seems
        largely irrelevant for the BR discussion here.</div>
    </blockquote>
    <br>
    I hope my answer gives you some idea how one could come to that
    conclusion. <br>
    <br>
    Dimitris.<br>
  </body>
</html>