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

[Ryan Sleevi]

On Wed, Sep 9, 2020 at 1:23 AM Dimitris Zacharopoulos (HARICA) via
Validation <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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20200909/57438987/attachment.html>