<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><font face="Calibri">I also concur with Mads, and would support
the addition of more requirements to method 3.2.2.4.1.<br>
</font></p>
<p><font face="Calibri">I like the solution proposed by Mad, but (if
I am not mistaken) there is not a specific Whois record field
for that information (org number), and I would avoid inserting
that information in a field that's not expressly designed for it.<br>
</font></p>
<p><font face="Calibri">Other solutions may also work, and would be
easier to implement, like e.g. mandating a full Registrant
address, in the Whois record, which must be one of the official
addresses of the Registrant as found in a QIIS/QGIS (excluding,
however, all information sources that just publish self-reported
organization information, which cannot be regarded as
"qualified" information sources and IMO should not be used in
the vetting process), and then the "reliable method of communication"
should be one that is found in the matching QIIS/QGIS record.<br>
</font></p>
<p><font face="Calibri">Not sure about method 3.2.2.4.5, at this
time, as I have not yet seen a sufficient discussion on it, and
I am not sure how it can effectively </font><font
face="Calibri"><font face="Calibri">be </font>used "as is" to
obtain a fraudulent certificate.<br>
</font></p>
Adriano<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">Il 03/01/2018 13:27, Doug Beattie via
Public ha scritto:<br>
</div>
<blockquote type="cite"
cite="mid:TY1PR0301MB11996C028D3C8F0D60BBC3D4F01E0@TY1PR0301MB1199.apcprd03.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:101460128;
mso-list-template-ids:-2030002558;}
@list l1
{mso-list-id:1132091234;
mso-list-template-ids:1020300042;}
@list l1:level1
{mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D">I agree with
Mads and am also supportive of a ballot that removes
3.2.2.4.5 and adds some more detail to 3.2.2.4.1.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Doug<o:p></o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"
moz-do-not-send="true"><span style="color:#1F497D"><o:p> </o:p></span></a></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in
0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Public
[<a class="moz-txt-link-freetext" href="mailto:public-bounces@cabforum.org">mailto:public-bounces@cabforum.org</a>] <b>On Behalf Of </b>Mads
Egil Henriksveen via Public<br>
<b>Sent:</b> Wednesday, January 3, 2018 7:11 AM<br>
<b>To:</b> Jeremy Rowley
<a class="moz-txt-link-rfc2396E" href="mailto:jeremy.rowley@digicert.com"><jeremy.rowley@digicert.com></a>; CA/Browser Forum
Public Discussion List <a class="moz-txt-link-rfc2396E" href="mailto:public@cabforum.org"><public@cabforum.org></a>;
<a class="moz-txt-link-abbreviated" href="mailto:geoffk@apple.com">geoffk@apple.com</a><br>
<b>Subject:</b> Re: [cabfpub] Verification of Domain
Contact and Domain Authorization Document<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="NO-BOK"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Then I think
we should change the requirements. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">As a
representative for a CA with a background in strong
identity validation (both for natural and legal persons) I
find these examples from Ryan and Jeremy to represent a
very bad practice. If this really reflects the current
practice in the industry, we need to tighten up the
requirements and make them much more specific.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">From my point
of view (and with my background) I find method 3.2.2.4.1
useful. We must remember that the domain validation
methods also are used for EV (and not only OV) and when we
have a strongly validated and verified organization (e.g.
based on the EV requirements) it makes sense to allow for
the organization to apply for certificates including
domain names owned by the organization itself. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">I understand
that there are doubts about how to ensure that the
organization really owns the domain (like in Jeremy’s
example), but it should not be too hard to “strengthen”
the link between the applicant and the domain owner in
terms of rewriting section 3.2.2.4.1. A match in the
organization name only should of course not be allowed. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">In Norway
every organization is given a unique organization number
by a national authority and in the registry for the
TLD=.no domains (see <a href="http://www.norid.no"
moz-do-not-send="true">www.norid.no</a>) we find this
organization number as a part of the domain name
registrant information. In such cases, we allow for
issuance based on 3.2.2.4.1 if the domain name registrant
information exactly match organization information (i.e.
by country, organization name and organization number). I
think this is a reasonable use case for method 3.2.2.4.1.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Personally I
am more concerned about the possibility we give to any
stakeholder in the ecosystem who takes a role in
controlling a domain to get an OV (and EV) certificate
based on domain control only. This was discussed also in
the F2F meeting in Bilbao last year – see <a
href="https://cabforum.org/2016/05/25/2016-05/#The-Role-of-Identity-in-TLS-Certificates"
moz-do-not-send="true">https://cabforum.org/2016/05/25/2016-05/#The-Role-of-Identity-in-TLS-Certificates</a>.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Therefore, I
am supportive for a ballot which removes 3.2.2.4.5 and
keep 3.2.2.4.1 but strengthen this up to allow for use
cases like the one described above.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Regards<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Mads </span><span
style="color:#1F497D" lang="NO-BOK"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="NO-BOK"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Public
[<a class="moz-txt-link-freetext" href="mailto:public-bounces@cabforum.org">mailto:public-bounces@cabforum.org</a>] <b>On Behalf Of </b>Jeremy
Rowley via Public<br>
<b>Sent:</b> onsdag 3. januar 2018 05:47<br>
<b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:geoffk@apple.com">geoffk@apple.com</a>; CA/Browser Forum Public
Discussion List <a class="moz-txt-link-rfc2396E" href="mailto:public@cabforum.org"><public@cabforum.org></a><br>
<b>Subject:</b> Re: [cabfpub] Verification of Domain
Contact and Domain Authorization Document<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><span lang="NO-BOK"><o:p> </o:p></span></p>
<p class="MsoNormal">I disagree. The requirements do not
specify that. All that is required is the name of the
applicant was verified under 3.2.2.1 and that the register
specify the domain contact is the applicant. If Google, Inc.
is specified as the domain contact, no address matching is
required.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> <a
href="mailto:geoffk@apple.com" moz-do-not-send="true">geoffk@apple.com</a>
[<a href="mailto:geoffk@apple.com"
moz-do-not-send="true">mailto:geoffk@apple.com</a>] <br>
<b>Sent:</b> Tuesday, January 2, 2018 4:34 PM<br>
<b>To:</b> Jeremy Rowley <<a
href="mailto:jeremy.rowley@digicert.com"
moz-do-not-send="true">jeremy.rowley@digicert.com</a>>;
CA/Browser Forum Public Discussion List <<a
href="mailto:public@cabforum.org"
moz-do-not-send="true">public@cabforum.org</a>><br>
<b>Cc:</b> Ryan Sleevi <<a
href="mailto:sleevi@google.com" moz-do-not-send="true">sleevi@google.com</a>>;
Adriano Santoni <<a
href="mailto:adriano.santoni@staff.aruba.it"
moz-do-not-send="true">adriano.santoni@staff.aruba.it</a>><br>
<b>Subject:</b> Re: [cabfpub] Verification of Domain
Contact and Domain Authorization Document<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Dec 22, 2017, at 12:09 PM,
Jeremy Rowley via Public <<a
href="mailto:public@cabforum.org"
moz-do-not-send="true">public@cabforum.org</a>>
wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">The attack vector is easier than
that.<span class="apple-converted-space"> </span><o:p></o:p></p>
</div>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoNormal" style="mso-list:l1 level1 lfo3">I
use very stringent processes to verify that Google,
Inc. is a legit company in Utah.<o:p></o:p></li>
<li class="MsoNormal" style="mso-list:l1 level1 lfo3">I
verify that Jeremy did indeed incorporate Google,
Inc.<span class="apple-converted-space"> </span><o:p></o:p></li>
<li class="MsoNormal" style="mso-list:l1 level1 lfo3">I
call Jeremy at the phone listed for Google, Inc.,
the Utah corporation<o:p></o:p></li>
<li class="MsoNormal" style="mso-list:l1 level1 lfo3">The
domain information shows Google, Inc. as owning<span
class="apple-converted-space"> </span><a
href="http://google.com/" moz-do-not-send="true"><span
style="color:purple">google.com</span></a><o:p></o:p></li>
<li class="MsoNormal" style="mso-list:l1 level1 lfo3">Certificate
issues.<o:p></o:p></li>
</ol>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Obviously this would be caught in
every CA’s high risk checks, but the point remains
valid. Regardless of the expertise and thoroughness
of the org check, the specs lack any time between
the verified org and the actual domain because orgs
are not unique on a global basis.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">For item 4, you have to verify that
“the Applicant is the Domain Contact”. Obviously it’s
insufficient to just compare names—you must verify every
element of the WHOIS contact matches the Applicant, that’s
typically name, postal address, phone number, and e-mail.<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Public@cabforum.org">Public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a>
</pre>
</blockquote>
<br>
</body>
</html>