<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 12:08 PM Dimitris Zacharopoulos (HARICA) <<a href="mailto:dzacharo@harica.gr">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>
    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.</div></blockquote><div><br></div><div>Not by browsers. Which is precisely why it doesn't belong in the TLS certificates used, by browsers, to connect to a server.</div><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>
    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. </div></blockquote><div><br></div><div>Sure, and some people find it useful to use SSL 3.0, or use SHA-1, or use RC4. The measure of whether or not something is a good idea is not whether it's "useful" in some hypothetical model, especially when it actively causes harm. This is precisely what my previous message was addressing, so I would encourage re-reading it. There's a night and day difference here between comparing WHOIS, which was designed as an abstract text protocol, and a very specific use of TLS, by browsers, to connect to servers. </div><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>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?</div></blockquote><div><br></div><div>Yes, absolutely, if you're proposing to put this information in, you absolutely need to know why. We cannot discuss in the abstract, nor is it reasonable to discuss about "that's just the way we did things", especially when so many things done have no basis in technical reality. It's no different than arguing we should put IP addresses in the dNSName, because that's what CAs did, so clearly, they must have had a reason, and if they had a reason, it must have been good. There's so much flawed about that argument that it doesn't even bear dissecting.</div><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> 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></div></blockquote><div><br></div><div>Then I encourage you to read the Baseline Requirements again, and carefully read the sections this ballot proposes to remove.</div><div><br></div><div>As I mentioned in the previous message: the starting discussion is going to be, has to be, and will continue to be, "assume the OU is forbidden. Why should it be allowed?" If that cannot be articulated in a way that demonstrates the value and overcomes the harm, it's a non-starter, plain and simple.</div></div></div>