<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
Thank for the detailed response. It summarizes Google's viewpoint on
several issues, including Identity.<br>
<br>
<div class="moz-cite-prefix">On 23/11/2020 8:45 μ.μ., Ryan Sleevi
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACvaWvb2Y2yh-QSy_ZnkD8=cwRu=EdjXaLAohGFgg4yOeSB+ug@mail.gmail.com">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.</blockquote>
<br>
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."<br>
<br>
I would like to highlight that 7.1.2.4 allows for "other fields and
extensions" but during the <i>organizationIdentifier </i>discussion,
you had expressed a preference that if this <b>validated</b> <b>information
</b>were to be included, it should be in an extension rather than
the subjectDN.<br>
<br>
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.<br>
<br>
To use an example, if a CA were to define in its CP/CPS an extension
that follows exactly the description of the <em>cabfOrganizationIdentifier</em>
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?<br>
<br>
<br>
</body>
</html>