<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>