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

[Doug Beattie]

Paul,

 

This does not address Ryan's concerns he's previously stated, so I doubt
it's really advancing the cause.

 

Ryan: I'm thinking the use of a private extension for this type of data
(including LEIs and other industry desired data) that cannot be validated in
accordance with the BRs (section 3.2) might be a good approach, similar to
the QCStatement extension.  Would you have any serious objections to the
long term use of a private extension which the browsers can ignore for
conveying this type of data?

 

From: Validation <validation-bounces at cabforum.org> On Behalf Of Paul van
Brouwershaven via Validation
Sent: Monday, November 23, 2020 4:00 AM
To: Ryan Sleevi <sleevi at google.com>; CA/Browser Forum Validation SC List
<validation at cabforum.org>
Subject: Re: [cabf_validation] [EXTERNAL] Draft Ballot SCXX: Improve OU
validation requirements

 

I created a version to address the highlighted concerns on the usage of the
word 'equivalent' and the validation of trademarks and trade/business names.

This version:

*	is using a fixed set of pre/suffix values
*	includes a requirement for a certified translation for the
equivalent in a language other than English 
*	requires the CA to check the value in the WIPO Global Brand Database
and the local business registry

Proposed OU validation requirements:

If the Subject Identity Information is to include an organizational unit,
then it MUST be preceded or followed by a whitespace and one of the words
"unit", "department", "division", "group", "service", "system", "center",
"office", "school", "faculty", "administration", "operations" in singular or
plural form; or a certified translation of the equivalent in a language
other than English. 

The CA MUST verify the existence and affiliation of the organizational unit
with the Applicant using an Organizational Chart provided by an
authoritative source within the Applicant's organization, such as the
Applicant's main business offices, corporate offices, human resource
offices, information technology offices, or other department that the CA
deems appropriate. 

If a value holds an active registration in the 'WIPO Global Brand Database'
or a local business register the CA MAY only include these registered values
when the CA has verified the right of usage in relation to the Application
in accordance with Section 3.2. 

The value SHALL not be abbreviated unless this would exceed the maximum
length of the `subject:organizationalUnitName` field, in which case it SHALL
only use locally accepted abbreviation. 

 

Please share your thoughts about this version.

 

Thanks,

 

Paul

  _____  

From: Ryan Sleevi <sleevi at google.com>
Sent: Monday, November 16, 2020 16:23
To: Paul van Brouwershaven <Paul.vanBrouwershaven at entrust.com>; CA/Browser
Forum Validation SC List <validation at cabforum.org>
Subject: Re: [cabf_validation] [EXTERNAL] Draft Ballot SCXX: Improve OU
validation requirements 

 

 

 

On Mon, Nov 16, 2020 at 10:12 AM Paul van Brouwershaven via Validation
<validation at cabforum.org <mailto: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/20201123/c171657b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5708 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20201123/c171657b/attachment-0001.p7s>