<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 7:36 μ.μ., Ryan Sleevi
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CACvaWvZiNbz7Tr5fGzsPA72o1OuW1okTCrEH4pjpagrE8OBSmg@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <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 11:58
            AM Dimitris Zacharopoulos (HARICA) <<a
              href="mailto:dzacharo@harica.gr" moz-do-not-send="true">dzacharo@harica.gr</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> <br>
              <br>
              <div>On 2/9/2021 6:34 μ.μ., Ryan Sleevi wrote:<br>
              </div>
              <blockquote type="cite">
                <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"
                        target="_blank" moz-do-not-send="true">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" moz-do-not-send="true">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>
                </div>
              </blockquote>
              <br>
              No. I am saying that it's a reasonable interpretation of
              the current BRs and that a subCA that contains an EKU
              without id-kp-serverAuth or anyEKU should be considered
              technically constrained because it cannot create a valid
              TLS end-entity certificate. Or, put differently, even if a
              TLS end-entity certificate is issued, it should not
              validate successfully because of the EKU chaining
              restrictions.<br>
            </div>
          </blockquote>
          <div><br>
          </div>
          <div>I fail to see how you can say that "Because one program
            said something", that it's fine to reinterpret the BRs
            according to that.</div>
          <div><br>
          </div>
          <div>Apple doesn't implement EKU chaining, and so the BR
            requirement makes sense given Apple's implementation. I
            really must push back on this, because I want to make sure
            that CAs aren't arguing that a given program can _loosen_
            the BRs arbitrarily. They may choose to ignore a violation
            for their own program, as is their prerogative, and we
            absolutely see programs put more stringent requirements in
            their programs than the BRs, but I don't believe we can say
            that "Mozilla said it was OK, so now it's OK for everyone"
            is somehow acceptable.</div>
          <div> </div>
        </div>
      </div>
    </blockquote>
    <br>
    If a Browser (especially the Mozilla Root Program which is based on
    an open community where industry experts and security researchers
    contribute) has a certain interpretation of the BRs, this does have
    some weight in the industry. The same thing applies when you,
    representing Google Chrome, have a certain interpretation of the BRs
    that some CAs find ambiguous.<br>
    <br>
    If I understand correctly, you are arguing that Mozilla is relaxing
    a BR rule without doing so in their Root Program Policy and I am
    saying that this is one possible interpretation of the current BRs.
    Mozilla didn't interpret the BRs like you did and said "we don't
    care if you violate that requirement". They didn't see it as a
    violation, ever. And so did the auditors of all CAs out there that
    have used the same Root hierachy for non-TLS certificates, otherwise
    we would have seen audit reports with incidents highlighting that
    issue.<br>
    <br>
    <br>
    <blockquote type="cite"
cite="mid:CACvaWvZiNbz7Tr5fGzsPA72o1OuW1okTCrEH4pjpagrE8OBSmg@mail.gmail.com">
      <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>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>
                </div>
              </blockquote>
              <br>
              I am talking about the current requirements.<br>
            </div>
          </blockquote>
          <div><br>
          </div>
          <div>OK, then you need to support your argument with the
            current BRs, and not one Root Program.</div>
        </div>
      </div>
    </blockquote>
    <br>
    I mentioned the Mozilla communications because we are talking about
    industry experts and security researchers who are reading the BRs,
    just like everyone else. Their opinion has some weight in the
    interpretation of the BRs and CAs often seek clarifications and
    interpretations in the m.d.s.p. community.<br>
    <br>
    Taking the current BRs, in section 7.1.5, reading from the top:<br>
    <p>"For a Subordinate CA Certificate to be considered Technically
      Constrained, the certificate MUST include an Extended Key Usage
      (EKU) extension specifying all extended key usages that the
      Subordinate CA Certificate is authorized to issue certificates
      for. The <code>anyExtendedKeyUsage</code> KeyPurposeId MUST NOT
      appear within this extension."</p>
    <p>Let's pick anything but "id-kp-serverAuth". Moving to the next
      paragraph:<br>
    </p>
    <p>"If the Subordinate CA Certificate includes the id-kp-serverAuth
      extended key usage, then the Subordinate CA Certificate MUST
      include the Name Constraints X.509v3 extension with constraints on
      <code>dNSName</code>, <code>iPAddress</code> and <code>DirectoryName</code>
      as follows:"</p>
    Not applicable because we do not have "id-kp-serverAuth". BTW, the
    rendering of a. b. c. under that paragraph doesn't render properly
    on GitHub Markdown flavor :)<br>
    <br>
    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>
    <br>
    <br>
    <blockquote type="cite"
cite="mid:CACvaWvZiNbz7Tr5fGzsPA72o1OuW1okTCrEH4pjpagrE8OBSmg@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote">
          <div> </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">
                    <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>
    <br>
    Like I said already, the current language seems to have different
    interpretations and we should clarify it. Was it ever the intent to
    include both EKU and NC in all cases of EKU? It would be a very easy
    thing to write had that been the intent from Browser members. CAs
    could easily follow. If these arguments were discussed when 7.1.5
    was drafted, it should be in the archives.<br>
    <br>
    <br>
  </body>
</html>