<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 23, 2020 at 3:12 PM Dimitris Zacharopoulos (HARICA) <<a href="mailto:dzacharo@harica.gr">dzacharo@harica.gr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<br>
Thank for the detailed response. It summarizes Google's viewpoint on
several issues, including Identity.<br>
<br>
<div>On 23/11/2020 8:45 μ.μ., Ryan Sleevi
wrote:<br>
</div>
<blockquote type="cite">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></div></blockquote><div><br></div><div>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.</div><div><br></div><div>It's this same issue that demonstrates how lacking Entrust's proposals have been, by failing to address the issue.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
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></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
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></div></blockquote><div><br></div><div>With respect to LEI? No.</div><div>With respect to OU? No.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
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></div></blockquote><div><br></div><div>No, not inherently. </div></div></div>