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

[Ryan Sleevi]

On Mon, Nov 23, 2020 at 6:58 AM Doug Beattie <doug.beattie at globalsign.com>
wrote:

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

Wholeheartedly agreed. This continues to be a facile attempt to dismiss two
years of thoughtful collaboration in order to advance a discredited idea
that harms user security and server agility.


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

Yes.


>
>
> *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> 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/cb7fb093/attachment.html>