<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><font face="Calibri">Jeremy, I am not sure I fully understand the
problems you describe. <br>
</font></p>
<p><font face="Calibri">Would it be possible for you to provide some
concrete example related to method #1, with some details,
without of course mentioning specific certificates and/or
organizations?</font><br>
</p>
<br>
<br>
<div class="moz-cite-prefix">Il 19/12/2017 22:30, Jeremy Rowley via
Public ha scritto:<br>
</div>
<blockquote type="cite"
cite="mid:BLUPR14MB03395312ACF356AD5B096D6A8E0F0@BLUPR14MB0339.namprd14.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<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:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></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">Hi all, <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">When reviewing the Symantec validation
methods and the customers using each method, I found an
alarming number of customers verified under 3.2.2.4.1
(Verification of a Domain Contact) or 3.2.2.4.5 (Domain
Authorization Document) where the domain is not technically
associated with the entity. These two methods need improvement
or removal as the way they are currently lacks sufficient
controls to associate the domain verification with the actual
certificate approver. I’ve had too many calls with customers
explaining re-verification where the domain holder didn’t
understand that a cert issued for the domain. Although the
organization verification was successfully complete, the only
tie between the domain and organization is a call to the
organization that happened within the last years to approve
the account for issuance. I wanted to bring it up here because
I’ve always thought these methods were less desirable than
others. I think other large CAs use this method quite a bit so
I’m hoping to get clarity on why these methods are permitted
when the domain verification seems more “hand-wavy” than other
methods. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Method 3.2.2.4.1 permits a CA to issue a
certificate if the certificate is an EV or OV cert. With EV
certificates, there is a call to a verified telephone number
that confirms the requester’s affiliation with the
organization. I can see this method working for EV. For OV
certificates, there is a reliable method of communication that
confirms the account holder as affiliated with the
organization. Unlike EV, for OV certs there is no tie between
the requester and their authority to request a certificate.
Once the organization is verified, the BRs permit
auto-issuance for any domain that reflects an affiliation with
the verified entity for up to 825 days. There’s no notice to
the domain contact that the certificate was requested or
approved. Perhaps this is sufficient as the account has been
affiliated with the organization through the reliable method
of communication and because CT will soon become mandatory. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Method 3.2.2.4.5 permits a CA to issue a
certificate using a legal opinion letter for the domain.
Unfortunately the BRs lack clear requirements about how the
legal opinion letter is verified. If I want a cert for
Google.com and the CA is following the bare minimum, all I
need to do is copy their letterhead and sign the document.
Magically, a certificate can issue. This method lacks a lot
of controls of method 1 because there is no requirement around
verification of the company. I can list as many domains in the
letter as I’d like provided the entity listed in the
corresponding WHOIS’s letterhead is used.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I’m looking to remove/fix both of these
methods as both these methods lack the necessary controls to
ensure that the verification ties to the domain holder. These
methods probably should have been removed back when we passed
169/182. Would anyone being willing to endorse a ballot
killing these or making some necessary improvements? <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Jeremy<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</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>