<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <br>
    I missed the last validation subcommittee call but the following
    from the draft minutes caught my attention.<br>
    <br>
    <div class="moz-cite-prefix">On 7/11/2023 12:19 π.μ., Corey Bonnell
      via Management wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:0100018ba6b8981a-d0bea937-43af-4cc5-9438-5d16fd2c1252-000000@email.amazonses.com">
      <p class="MsoNormal"><i><span
style="font-family:"Arial",sans-serif;color:black;mso-ligatures:none">-
            Validity period for Technically Constrained Sub-CA and
            validation period for Domain Namespace - Wayne said that
            Ryan Sleevi filed this and it has to do with the ‘verified
            namespace’ for an enterprise RA.</span><span
            style="mso-ligatures:none"><o:p></o:p></span></i></p>
      <p class="MsoNormal"><i><span style="mso-ligatures:none"><o:p> </o:p></span></i></p>
      <p class="MsoNormal"><i><span
style="font-family:"Arial",sans-serif;color:black;mso-ligatures:none">Clint
            said that this is on Apple’s backlog. In particular
            clarifying that a domain name in a technically constrained
            subCA needs to be revalidated on the same cadence as any
            other domain name. Clint said that he hopes to work in this
            in the next year.</span></i></p>
    </blockquote>
    <br>
    Section <a
href="https://github.com/cabforum/servercert/blob/main/docs/BR.md#421-performing-identification-and-authentication-functions">4.2.1</a>
    of the BRs states that:<br>
    <br>
    <blockquote type="cite">For validation of Domain Names and IP
      Addresses according to Section 3.2.2.4 and 3.2.2.5, any reused
      data, document, or completed validation MUST be obtained no more
      than 398 days prior to issuing the Certificate</blockquote>
    <br>
    Section <a
href="https://github.com/cabforum/servercert/blob/main/docs/BR.md#71252-technically-constrained-tls-subordinate-ca-name-constraints">7.1.2.5.2</a>
    states for dNSName and iPAddress that:<br>
    <br>
    <blockquote type="cite">The CA MUST confirm that the Applicant has
      registered the <code>dNSName</code> or has been authorized by the
      domain registrant to act on the registrant's behalf. See <a
href="https://github.com/cabforum/servercert/blob/main/docs/BR.md#3224-validation-of-domain-authorization-or-control">Section
        3.2.2.4</a>.</blockquote>
    <br>
    <blockquote type="cite">The CA MUST confirm that the Applicant has
      been assigned the <code>iPAddress</code> range or has been
      authorized by the assigner to act on the asignee's behalf. See <a
href="https://github.com/cabforum/servercert/blob/main/docs/BR.md#3225-authentication-for-an-ip-address">Section
        3.2.2.5</a>.</blockquote>
    <br>
    These sections are linked together. My reading of these requirements
    is that a CA that issues a Technically Constrained TLS SubCA must
    re-validate the Domain Namespace every 398 days. In fact, the only
    way to do this is by using the 3.2.2.4 methods that are eligible for
    the issuance of wildcard certificates. Perhaps the last part is not
    very clearly stated but the re-validation should be clear.<br>
    <br>
    The tricky part is with the IP Address space because the methods
    currently defined in 3.2.2.5 do not all guarantee the control of an
    entire IP space. We could do some work in 3.2.2.5 to explicitly call
    out the methods that are eligible for IP space validation just like
    we did with the Wildcard Domain Name validation.<br>
    <br>
    <br>
    Thanks,<br>
    Dimitris.<br>
    <br>
    <br>
  </body>
</html>