[cabf_validation] [EXTERNAL]Re: Revision to OU requirements

[Dimitris Zacharopoulos (HARICA)]

On 2020-09-09 6:43 μ.μ., Ryan Sleevi wrote:
>
>
> On Wed, Sep 9, 2020 at 1:23 AM Dimitris Zacharopoulos (HARICA) via 
> Validation <validation at cabforum.org <mailto:validation at cabforum.org>> 
> wrote:
>
>
>
>     On 2020-09-09 5:56 π.μ., Ryan Sleevi via Validation wrote:
>     > To discuss how the information should be validated requires
>     discussing
>     > what the information should be in the first place. In the months
>     since
>     > the F2F discussion, no one has brought any use case forward. We
>     know
>     > from extant practices that CAs are keen to add their brandnames,
>     > marketing information, or otherwise problematic data, such as
>     "Domain
>     > Control Validated", which serves no value to the software using
>     these
>     > certificates. To figure out how to validate first requires
>     identifying
>     > the use cases, and those use cases that have been shared are not
>     only
>     > hardly compelling, but border on problematic to harmful to security.
>
>     Shouldn't it be easier to search CT logs or CENSYS for OU values
>     to get
>     a better reading on possible value to the OU field? I'm sure we would
>     find more than just brandnames, marketing information, or otherwise
>     problematic data in OU fields.
>
>
> I think this entirely misses the point of my message?
>
> 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.


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.

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20200909/f38311a9/attachment.html>