<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">On 23/11/2020 5:23 μ.μ., Ryan Sleevi
via Validation wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACvaWvYE0V7iK02f+w2WXUd3CCh7179GgXqruO1cYY+wU9V82w@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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"
moz-do-not-send="true">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 class="gmail-m_7035733744482897546WordSection1">
<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 class="gmail-m_7035733744482897546WordSection1">
<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"
cite="mid:CACvaWvYE0V7iK02f+w2WXUd3CCh7179GgXqruO1cYY+wU9V82w@mail.gmail.com">
<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 class="gmail-m_7035733744482897546WordSection1">
<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" moz-do-not-send="true">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"
moz-do-not-send="true">sleevi@google.com</a>>;
CA/Browser Forum Validation SC List <<a
href="mailto:validation@cabforum.org"
target="_blank" moz-do-not-send="true">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_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"
moz-do-not-send="true">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" moz-do-not-send="true">Paul.vanBrouwershaven@entrust.com</a>>;
CA/Browser Forum Validation SC List <<a
href="mailto:validation@cabforum.org"
target="_blank" moz-do-not-send="true">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" moz-do-not-send="true">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 class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Validation mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Validation@cabforum.org">Validation@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://lists.cabforum.org/mailman/listinfo/validation">https://lists.cabforum.org/mailman/listinfo/validation</a>
</pre>
</blockquote>
<br>
</body>
</html>