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

[Dimitris Zacharopoulos (HARICA)]

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/20201123/dd063753/attachment.html>