<div dir="ltr">Hi Dimitris,<div><br></div><div>I understand we have different viewpoints, and despite past attempts to help you understand the systemic issues, it appears we will not resolve them.</div><div><br></div><div>Our focus is to ensure all information included in certificates is necessary and has been validated against well-defined, interoperable criteria. Entrust's latest proposal fails on both those very simple tests, being neither well-defined nor interoperable, as have their previous efforts. I can understand that some CAs would prefer a single PKI to serve multiple distinct purposes, but despite good-faith efforts on establishing the rationale for such information, the provided explanations are weak, at best, although many fall into the long-discredited approach to "risk management" that says "There is no risk until something goes wrong". As it stands, nearly half of the CA security incidents we see are related to approaches and proposals similar to what's proposed here for OU, and frankly, that's not acceptable to continue. You can see Ben Wilson's presentation at our recent F2F, in the event you'd like to know more about those statistics.</div><div><br></div><div>For every CA we trust, we want to make sure they're operating a well-defined PKI, with a clear set of purposes and constituencies. While certificates can be used to express a wide variety of information, it's best to ensure separate protocols (e.g. TLS vs S/MIME), separate naming scopes (e.g. legal identity, domain identity, application identity), and user communities (e.g. payment terminals, web browsers, banking industry) use separate PKIs. "PKI" is merely a collection of related technologies, but the successful deployment requires care across all of those dimensions, and attempting to combine them has, over the past 25 years, shown repeatedly the security risks that can come from it.</div><div><br></div><div>You are correct for recognizing that, at the core, this is a question about identity in certificates. However, this is not merely a disagreement, but one that touches on the heart of the security of every user, as it affects a multitude of security principles: from the ability to easy replace certificates (e.g. not having to undergo complex identity vetting processes for information that is not programatically used), the ability to easily change CAs (in which the identity validating processes are used to raise the complexity in changing to a better CA), to the need and frequency of replacing certificates (due to CAs failing to follow the procedures they themselves helped draft). These principles have a direct impact on user security, and these are things we take very seriously.</div><div><br></div><div>When it comes to the CAs that we partner with and include out-of-the-box in a fresh install, without requiring the user to take any explicit action to install or configure, our intent is to work with CAs that share that common goal, and understand that this is an ecosystem issue. I understand the appeal of "If you don't like the certificate, don't trust it", but it's much easier, safer, and interoperable to simply not partner with CAs that only produce "good" results 50% of the time, then it is to try to add complexity (and risk) to end users by trying to reject the insecure 50%. This doesn't prevent the organization from issuing such certificates, but does limit whether or not such "roots" are candidates for inclusion.</div><div><br></div><div>This is no different from how, out of the box, modern web browsers don't support Gopher, or increasingly, FTP: if you want to use those protocols, you have to take an added action to install or configure an application/extension for them. PKI technologies, such as certificates, are not a protocol or a singular solution; they're a set of tools and techniques used to define different protocols. Just as the <a href="https://www.icao.int/publications/pages/publication.aspx?docnum=9303">travel document PKI</a> has a vastly different set of constraints than a PKI used for <a href="https://spiffe.io/">datacenter authentication between virtual machines</a>, even though both use "PKI" and "certificates", when it comes to our browser product, our goal in the set of CAs we support is to <a href="https://tools.ietf.org/html/draft-ietf-pkix-ipki-00#section-2.3">limit the demands on sophistication/attentiveness of users, ensure security out of the box, automate security checks</a>, and treat it as a holistic, systems issue, rather than one-offs. When it comes to web browsers, these requirements and needs have been known for decades, and on a technical level, such proposals simply <a href="https://www.ccadb.org/documents/Qualified_Website_Authentication_Certificates_Interoperability.pdf">don't match how the technology works</a>.</div><div><br></div><div>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.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 23, 2020 at 12:35 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>
<br>
<div>On 23/11/2020 5:23 μ.μ., Ryan Sleevi
via Validation wrote:<br>
</div>
<blockquote type="cite">
<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 6:58
AM Doug Beattie <<a href="mailto:doug.beattie@globalsign.com" target="_blank">doug.beattie@globalsign.com</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 lang="EN-US">
<div>
<p class="MsoNormal">Paul,</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">This does not address Ryan’s
concerns he’s previously stated, so I doubt it’s
really advancing the cause.</p>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Wholeheartedly agreed. This continues to be a facile
attempt to dismiss two years of thoughtful collaboration in
order to advance a discredited idea that harms user security
and server agility.</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 lang="EN-US">
<div>
<p class="MsoNormal">Ryan: I’m thinking the use of a
private extension for this type of data (including
LEIs and other industry desired data) that cannot be
validated in accordance with the BRs (section 3.2)
might be a good approach, similar to the <span style="font-size:10.5pt;font-family:-apple-system;color:rgb(23,43,77);background:white">QCStatement extension.
Would you have any serious objections to the long
term use of a private extension which the browsers
can ignore for conveying this type of data?</span></p>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Yes.</div>
<div> </div>
</div>
</div>
</blockquote>
<br>
I believe that the organizationalUnitName field is an extension of
the organizationName field for larger organizations, especially
governmental structures. This group has not seen any evidence in the
past several years where using OU in end-entity TLS certificates has
caused any user security harm. Perhaps there were discussions in
m.d.s.p. or other Forums about users claiming they were deceived by
following information in the OU fields. Even when this field was
used to convey tracking information or displaying the policy
validation level in a more humanly readable manner ("This
Certificate is Domain/Organization/Extended Validated") used by some
CAs, I don't remember users reporting anything about security harm.
HARICA has been using OU fields in OV Certificates for the last 10
years and we've never received a report from a Relying Party that
they were misguided or harmed in any way because of information in
the OU field.<br>
<br>
Entrust's proposal is trying to make improvements to the current BRs
practice which a significant part of Internet Certificate
Subscribers use today. Assuming that Identity in Certificates is of
some use (some think it is useful and some think it's not; we're not
going to solve this problem on this thread), Relying Parties that
check the information in certificates can see which Organizational
Unit of the validated Organization is responsible for the
site/certificate. Just like they do with the countryName,
stateOrProvinceName, localityName and organizationName, they can see
useful information in the organizationalUnitName field.<br>
<br>
It is self-reported information by the Applicant, but the risk of
adding harmful or misleading data is significantly mitigated by the
proposed language of the ballot. <br>
<br>
There is probably not going to be 100% consensus on this proposal so
perhaps the best way forward is to proceed with the ballot and see
how it goes.<br>
<br>
Ryan's last response on the extension proposal is not clear whether
it has to do with something "similar to the QCStatement" or if there
are serious objections to any type of extension. I was hoping that
since the BRs allow custom extensions to be defined by CAs (and how
CAs validate this information), it would be allowed for a CA to
include an extension that is designed -say- for the EV Profile, like
the CABFSelectedAttributeTypes extension, and include the LEI value.
Ryan, can you please clarify?<br>
<br>
<br>
Thanks you,<br>
Dimitris.<br>
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-US">
<div>
<p class="MsoNormal"> </p>
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b>From:</b> Validation <<a href="mailto:validation-bounces@cabforum.org" target="_blank">validation-bounces@cabforum.org</a>>
<b>On Behalf Of </b>Paul van Brouwershaven via
Validation<br>
<b>Sent:</b> Monday, November 23, 2020 4:00 AM<br>
<b>To:</b> Ryan Sleevi <<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>>;
CA/Browser Forum Validation SC List <<a href="mailto:validation@cabforum.org" target="_blank">validation@cabforum.org</a>><br>
<b>Subject:</b> Re: [cabf_validation] [EXTERNAL]
Draft Ballot SCXX: Improve OU validation
requirements</p>
</div>
</div>
<p class="MsoNormal"> </p>
<div>
<p style="margin-bottom:8pt;line-height:106%"><span style="font-size:12pt;line-height:106%;color:black">I
created a version to address the highlighted
concerns on the usage of the word 'equivalent' and
the validation of trademarks and trade/business
names.</span></p>
<p class="MsoNormal" style="margin-bottom:8pt;line-height:106%"><span style="color:black">This version:</span></p>
<ul type="disc">
<li class="MsoNormal">is using a <u>fixed set</u>
of pre/suffix values</li>
<li class="MsoNormal">includes a requirement for a <u>certified
translation</u> for the equivalent in a language
other than English </li>
<li class="MsoNormal">requires the CA to check the
value in the WIPO Global Brand Database and the
local business registry</li>
</ul>
<p class="MsoNormal" style="margin-bottom:8pt;line-height:106%"><span style="color:black">Proposed OU validation
requirements:</span></p>
</div>
<blockquote style="margin-left:30pt;margin-right:0in">
<div>
<p class="MsoNormal" style="margin-bottom:8pt;line-height:106%"><i><span style="color:black">If the Subject Identity
Information is to include an organizational
unit, then it MUST be preceded or followed by
a whitespace and one of the words “unit”,
“department”, “division”, <span style="background:white">“group”, </span>“service",
"system", "center", "office", “school”,
“faculty”, "administration", "operations” in
singular or plural form; or a certified
translation of the equivalent in a language
other than English. </span></i><span style="color:black"></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:8pt;line-height:106%"><i><span style="color:black">The CA MUST verify the
existence and affiliation of the
organizational unit with the Applicant using
an Organizational Chart provided by an
authoritative source within the Applicant's
organization, such as the Applicant's main
business offices, corporate offices, human
resource offices, information technology
offices, or other department that the CA deems
appropriate. </span></i><span style="color:black"></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:8pt;line-height:106%"><i><span style="color:black">If a value holds an active
registration in the ‘WIPO Global Brand
Database’ or a local business register the CA
MAY only include these registered values when
the CA has verified the right of usage in
relation to the Application in accordance with
Section 3.2. </span></i><span style="color:black"></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:8pt;line-height:106%"><i><span style="color:black">The value SHALL not be
abbreviated unless this would exceed the
maximum length of the
`subject:organizationalUnitName` field, in
which case it SHALL only use locally accepted
abbreviation. </span></i><span style="color:black"></span></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span style="font-size:12pt;color:black"> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;color:black">Please share
your thoughts about this version.</span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;color:black"> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;color:black">Thanks,</span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;color:black"> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;color:black">Paul</span></p>
</div>
<div class="MsoNormal" style="text-align:center" align="center">
<hr width="98%" size="2" align="center"></div>
<div id="gmail-m_-7062142631506974477gmail-m_7035733744482897546divRplyFwdMsg">
<p class="MsoNormal"><b><span style="color:black">From:</span></b><span style="color:black"> Ryan Sleevi <<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>><br>
<b>Sent:</b> Monday, November 16, 2020 16:23<br>
<b>To:</b> Paul van Brouwershaven <<a href="mailto:Paul.vanBrouwershaven@entrust.com" target="_blank">Paul.vanBrouwershaven@entrust.com</a>>;
CA/Browser Forum Validation SC List <<a href="mailto:validation@cabforum.org" target="_blank">validation@cabforum.org</a>><br>
<b>Subject:</b> Re: [cabf_validation] [EXTERNAL]
Draft Ballot SCXX: Improve OU validation
requirements</span> </p>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"> </p>
</div>
<p class="MsoNormal"> </p>
<div>
<div>
<p class="MsoNormal">On Mon, Nov 16, 2020 at
10:12 AM Paul van Brouwershaven via Validation
<<a href="mailto:validation@cabforum.org" target="_blank">validation@cabforum.org</a>>
wrote:</p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;color:black">I
have been thinking about a more
simplistic and strict approach that
doesn't follow all the current allowed
methods listed in section 3.2 of the BR
like we have proposed currently. </span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">As with every other
proposal Entrust has offered to date, this
doesn't actually address the problem inherent
to any use of this field, which is that it's
unverified, unvetted data, as there is *no*
way to validate and vet it.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">The most recent proposal
reflects a thoroughly-debunked theater
exercise to security, which is to rely on
statements like "The user should
understand that ...". It attempts to absolve
the CA of the responsibility for not placing
unverified data in certificates in the first
place, by trying to make it the user's
responsibility on distinguishing that data
from other fields and making an informed
decision. Thankfully, this has been shown to
be a theater exercise that harms users, so I
feel like it's reasonable to simply reject it
outright.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">If that were not troubling
enough, however, I think it also bears
mentioning that this approach continues with
one which has been firmly discredited, and
which we've been actively moving away from in
the Forum since the Forum's very creation,
which is the introduction of significant
interpretation differences and leeway. "and an
equivalent of the word ... " and "in the
equivalent of the language" should best be
read as "any other method", and much like how
"but" serves to negate that which precedes it
in a sentence, the "an equivalent" serves to
negate any presumption of any rigor described.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">This isn't progress on any
measured dimension of providing rigor or
addressing the fundamental issues, and is an
attempt to preserve the status quo without
actually addressing the issues. I'm glad
Entrust is now interested in this space, but
this approach was discussed as far back as
London in 2018, during the WG day, and
highlights the problematic approach.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">And, in the spirit of
completely missing the problem space, it does
nothing to address the fact that the following
language is, practically speaking,
unimplementable: "It SHALL NOT include 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 relation to
the Application accordance with Section 3.2."</p>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
Validation mailing list
<a href="mailto:Validation@cabforum.org" target="_blank">Validation@cabforum.org</a>
<a href="https://lists.cabforum.org/mailman/listinfo/validation" target="_blank">https://lists.cabforum.org/mailman/listinfo/validation</a>
</pre>
</blockquote>
<br>
</div>
</blockquote></div>