<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <br>
    <br>
    <div class="moz-cite-prefix">On 2020-09-09 6:43 μ.μ., Ryan Sleevi
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CACvaWvY74SbM0+inT+SNR8NXgVTzufGofk0tRTuqDK8g516fag@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 Wed, Sep 9, 2020 at 1:23
            AM Dimitris Zacharopoulos (HARICA) via Validation <<a
              href="mailto:validation@cabforum.org"
              moz-do-not-send="true">validation@cabforum.org</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"><br>
            <br>
            On 2020-09-09 5:56 π.μ., Ryan Sleevi via Validation wrote:<br>
            > To discuss how the information should be validated
            requires discussing <br>
            > what the information should be in the first place. In
            the months since <br>
            > the F2F discussion, no one has brought any use case
            forward. We know <br>
            > from extant practices that CAs are keen to add their
            brandnames, <br>
            > marketing information, or otherwise problematic data,
            such as "Domain <br>
            > Control Validated", which serves no value to the
            software using these <br>
            > certificates. To figure out how to validate first
            requires identifying <br>
            > the use cases, and those use cases that have been
            shared are not only <br>
            > hardly compelling, but border on problematic to harmful
            to security.<br>
            <br>
            Shouldn't it be easier to search CT logs or CENSYS for OU
            values to get <br>
            a better reading on possible value to the OU field? I'm sure
            we would <br>
            find more than just brandnames, marketing information, or
            otherwise <br>
            problematic data in OU fields.<br>
          </blockquote>
          <div><br>
          </div>
          <div>I think this entirely misses the point of my message?</div>
          <div><br>
          </div>
          <div>We shouldn't need to check CT logs, hire a divinator,
            cast lots, or use scrying rods to figure out "why" folks do
            this. It's incumbent on those advocating that we should
            allow OU to articulate the specific why, because it's
            unambiguously clear that it's not part of the processing
            model used in TLS to validate a domain name. I am certain we
            would find suspicious things, and I'm well aware of cases
            where there are, unquestionably, latent security issues.
            However, it's not fruitful or useful to catalog all the bad,
            nor is it appropriate to try to "reverse engineer" the use
            case here.</div>
        </div>
      </div>
    </blockquote>
    <br>
    <br>
    It's also unambiguously clear that parts in a TLS Certificates that
    are not related to a Domain Name, are not part of the "processing
    model used in TLS to validate a domain name". You have been
    advocating that, for any Identity Information included in TLS
    Certificates, yet there are cases where this information is used.
    Just as some people find it useful to locate organization
    information in a Domain Name (via the Domain Name
    registries/registrars), they find it useful to locate organization
    information in TLS Certificates. OrganizationalUnitName just follows
    the organizationName attribute, it's usually a sub-section. You will
    find lots of cases where O=My company, OU=Sales Department or
    O=University of Utopia, OU=School of Medicine, OU=Department of
    Surgery.<br>
    <br>
    Is this WG or this Subcommittee supposed to be aware of all the use
    cases "out there" and comment on that? To the best of my knowledge
    there is no requirement (at least not yet) for CAs to be aware of
    how the issued certificates will be used by Subscribers, or the use
    cases they have in mind. CAs just bind Subscribers to a Subscriber
    Agreement that includes obligations like revocation in certain
    timelines, etc. <br>
    <br>
    <br>
  </body>
</html>