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

[Ryan Sleevi]

On Mon, Nov 23, 2020 at 3:12 PM Dimitris Zacharopoulos (HARICA) <
dzacharo at harica.gr> wrote:

>
> 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."
>

Yes, and the entire point of this discussion was prompted by many CA
members noting that this effectively leads to unvalidated information, due
to the lack of specificity and the significant lack of interoperable,
well-defined validation semantics. Which is exactly why it was proposed to
be removed.

It's this same issue that demonstrates how lacking Entrust's proposals have
been, by failing to address the issue.


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

I'm afraid this significantly misunderstands the point during that
discussion, and I'm not sure whether it bears yet again discussing this
(e.g. in the context of X.500 naming). To recap, the LEI proposal was not
with respect to "validated" information (to suggest so would be a gross
mischaracterization of the proposals to date), and was an orthogonal naming
scheme (with respect to the hierarchy of distinguished names). For this,
and other reasons omitted for brevity at the risk of an unnecessary
distraction, the comparison here is just wildly off the mark.


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

With respect to LEI? No.
With respect to OU? No.


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

No, not inherently.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20201123/6340b6d2/attachment.html>