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

[Ryan Sleevi]

I'll note the latest draft still suffers the same basic issues we've been
discussing for years, without meaningful improvement.

For example, it still relies on ambiguous, subjective interpretations,
which has shown to result in a number of incidents for CAs. "Local business
register" and "locally accepted abbreviation" are exactly the sort of
issues that the Validation WG sought to meaningfully address, and which
Entrust here has failed to do. Equally, the presumption of trust in the
Applicant data is the very antithesis of validation, yet remains a core
component of this proposal.

As stated, we do not see a viable path forward for this, not (as it has
been unfortunately stated) as an attempt to shut down discussion, but
precisely because this fails to meet the bare minimum of addressing the
systemic issues, and is thus not a remotely viable or acceptable "solution"
to the problems identified and, unfortunately, practiced by CAs.

On Thu, Jan 14, 2021 at 2:12 PM Paul van Brouwershaven <
Paul.vanBrouwershaven at entrust.com> wrote:

> This is the latest version of the proposed ballot to strengthen the
> validation requirements of the OU field:
>
> *#### 3.2.2.1.1 Organizational Unit*
> 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 an unambiguous certified translation of the equivalent
> in a language other than English.
>
> The CA MUST verify the existence of the organizational unit using an
> Organizational Chart provided by the human resource offices of the
> Applicant or that is signed by a listed officer of Applicant.
>
> If a word in the value holds an active registration in the ‘WIPO Global
> Brand Database’ or a local business register the CA MUST only include these
> registered values when the CA has verified the right of usage in relation
> to the Applicant 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.
>
> i. *__Certificate Field:__* `subject:organizationalUnitName` (OID:
> 2.5.4.11)
>   * __Required/Optional:__ *
>    *__Optional__* if the `subject:organizationName` field is present.
>    *__Prohibited__* if the `subject:organizationName` is absent.
>    *__Contents:__* If present, the `subject:organizationalUnitName` field
> MUST contain the Subject's organizational unit name as verified under
> Section 3.2.2.1.1.
>
>
> ------------------------------
> *From:* Validation <validation-bounces at cabforum.org> on behalf of
> Dimitris Zacharopoulos (HARICA) via Validation <validation at cabforum.org>
> *Sent:* Monday, November 23, 2020 21:11
> *To:* Ryan Sleevi <sleevi at google.com>
> *Cc:* CA/Browser Forum Validation SC List <validation at cabforum.org>
> *Subject:* Re: [cabf_validation] [EXTERNAL] Draft Ballot SCXX: Improve OU
> validation requirements
>
>
> Thank for the detailed response. It summarizes Google's viewpoint on
> several issues, including Identity.
>
> On 23/11/2020 8:45 μ.μ., Ryan Sleevi wrote:
>
> The Baseline Requirements do not, nor have they ever, permitted CAs to
> include unverified, self-attested information. Every piece of information
> included in a certificate has a requirement to be validated by the CA, as
> captured by 7.1.2.4 of the BRs, as well as more specific individual
> requirements. It is unfortunate that a CA needs to be reminded of this, or
> of the principles and motivations, and this applies equally to LEI, OU, or
> any other field or data the CA might imagine here.
>
>
> The validation rules for OU are already in the BRs (7.1.4.2.2 i). They
> have been there for years. It has always been self-attested information.
> The CA had to "implement a process that prevents an OU attribute from
> including 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 accordance with Section 3.2 and the
> Certificate also contains subject:organizationName, subject:givenName,
> subject:surname, subject:localityName, and subject:countryName attributes,
> also verified in accordance with Section 3.2.2.1."
>
> I would like to highlight that 7.1.2.4 allows for "other fields and
> extensions" but during the *organizationIdentifier *discussion, you had
> expressed a preference that if this *validated* *information *were to be
> included, it should be in an extension rather than the subjectDN.
>
> Regarding the LEI, of course the CA would need to verify/validate the
> information included in the extension; I never implied that information
> would not be validated. In my previous post, I mentioned that "BRs allow
> custom extensions to be defined by CAs (and how CAs validate this
> information)", so I hope we're in agreement that this is still currently
> allowed, if a CA meets everything listed in 7.1.2.4.
>
> To use an example, if a CA were to define in its CP/CPS an extension that
> follows exactly the description of the *cabfOrganizationIdentifier* as
> described in section 9.8.2 of the EV Guidelines (my previous example was
> flawed), describe the same EVG validation rules for that extension and
> include this extension in an OV Certificate, wouldn't that be compliant
> with the BRs?
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210114/916cdd63/attachment-0001.html>