<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@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:0cm;
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;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle17
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle18
{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:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1561944391;
mso-list-type:hybrid;
mso-list-template-ids:1683635450 346216730 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:2;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-font-family:Calibri;
mso-bidi-font-family:"Times New Roman";}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></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]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D">I’m following up on the original message to remove validation methods 3.2.2.4.1 and 3.2.2.4.5.
<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">We validate a large percentage of certificate requests using 3.2.2.4.1. It is highly used with our enterprise clients and works great if you know your customer. We would like to continue using this practice
and are open to updating the BRs to help ensure that the three step methodology using 3.2.2.1, 3.2.2.4.1 and 3.2.5 is sound.<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 background method 3.2.2.4.1 is probably the oldest domain validation method used. Until December 2017, I am not aware of any reported incidents. DigiCert appears to be the first to report an incident. After
rereading the message below and reviewing the other messages, I cannot determine if any certificates were mississued. It would be great to get more details or review an incident report. This is important as we would like to correct the issues rather than eliminating
3.2.2.4.1 items 1 an 2.<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">So here is a question for DigiCert: were you reporting certificate misissuance using 3.2.2.4.1? If yes, will DigiCert be posting an Incident Report on the Mozilla Dev Security Policy list using Mozilla’s standard
report form, as is customary when reporting certificate misissuance?<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">We really need to understand the problem statement and review some real use cases. We need to see how 3.2.2.4.1 was combined with 3.2.2.1 and 3.2.5. How was the registrant verified? What Reliable Method of Communication
was used?<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">We believe that:<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="color:#1F497D"><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="color:#1F497D">3.2.2.1 can be used to securely identify the applicant<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="color:#1F497D"><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="color:#1F497D">3.2.2.4.1 can be used to verify that the registrant is the applicant or an affiliate of the applicant<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="color:#1F497D"><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="color:#1F497D">3.2.5 can be securely used to verify that an employee of the applicant has authorized the issuance of the certificate<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">We would like to continue to work with the Validation Working Group to find new text to improve these processes.<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">Thanks, Bruce.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b>From:</b> Public [mailto:public-bounces@cabforum.org] <b>
On Behalf Of </b>Jeremy Rowley via Public<br>
<b>Sent:</b> December 19, 2017 4:30 PM<br>
<b>To:</b> CA/Browser Forum Public Discussion List <public@cabforum.org><br>
<b>Subject:</b> [EXTERNAL][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">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>
</body>
</html>