[cabf_validation] [EXTERNAL] Draft Ballot SCXX: Improve OU validation requirements
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Mon Nov 23 13:11:50 MST 2020
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 188.8.131.52 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 (184.108.40.206.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 220.127.116.11."
I would like to highlight that 18.104.22.168 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 22.214.171.124.
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...
More information about the Validation