[cabf_validation] [EXTERNAL] Draft Ballot SCXX: Improve OU validation requirements

[Ryan Sleevi]

On Mon, Nov 16, 2020 at 10:12 AM Paul van Brouwershaven via Validation <
validation at cabforum.org> wrote:

> I have been thinking about a more simplistic and strict approach that
> doesn't follow all the current allowed methods listed in section 3.2 of the
> BR like we have proposed currently.
>

As with every other proposal Entrust has offered to date, this doesn't
actually address the problem inherent to any use of this field, which is
that it's unverified, unvetted data, as there is *no* way to validate and
vet it.

The most recent proposal reflects a thoroughly-debunked theater exercise to
security, which is to rely on statements like "The user should
understand that ...". It attempts to absolve the CA of the responsibility
for not placing unverified data in certificates in the first place, by
trying to make it the user's responsibility on distinguishing that data
from other fields and making an informed decision. Thankfully, this has
been shown to be a theater exercise that harms users, so I feel like it's
reasonable to simply reject it outright.

If that were not troubling enough, however, I think it also bears
mentioning that this approach continues with one which has been firmly
discredited, and which we've been actively moving away from in the Forum
since the Forum's very creation, which is the introduction of significant
interpretation differences and leeway. "and an equivalent of the word ... "
and "in the equivalent of the language" should best be read as "any other
method", and much like how "but" serves to negate that which precedes it in
a sentence, the "an equivalent" serves to negate any presumption of any
rigor described.

This isn't progress on any measured dimension of providing rigor or
addressing the fundamental issues, and is an attempt to preserve the status
quo without actually addressing the issues. I'm glad Entrust is now
interested in this space, but this approach was discussed as far back as
London in 2018, during the WG day, and highlights the problematic approach.

And, in the spirit of completely missing the problem space, it does nothing
to address the fact that the following language is, practically speaking,
unimplementable: "It SHALL NOT include a name, DBA, tradename, trademark,
address, location, or other text that refers to a specific natural person
or Legal Entity unless the CA has verified this information in relation to
the Application accordance with Section 3.2."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20201116/b7f31c11/attachment-0001.html>