<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=utf-8"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
{font-family:"Bradley Hand ITC";
panose-1:3 7 4 2 5 3 2 3 2 3;}
/* 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;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle22
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle23
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle24
{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;}
--></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=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='color:#1F497D'>Continuing the discussion we had at this past week’s CA/B Forum teleconference, we agree with those that were in favor of wildcard certificates for EV. The examples cited below exist today with DV wildcards which provide no authentication of the business. At least with EV, you have a strong level of business authentication and if the owner of an EV certificate were to mount a phishing attack, they can be clearly identified and disciplined. The same is not the case for DV. Hence it makes more sense to <u>only</u> allow wildcards for EV (or OV) rather than DV but clearly there was opposition to deprecating this for DV on the call (so I’ll leave that as a separate item for now).<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 have this as a discussion item for the face to face meeting along with validity periods although they are not necessarily tied together. I’ll try to prepare a pro/con sheet to guide the discussion so please continue to send replies.<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<br>Dean<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 #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> public-bounces@cabforum.org [mailto:public-bounces@cabforum.org] <b>On Behalf Of </b>kirk_hall@trendmicro.com<br><b>Sent:</b> Thursday, March 26, 2015 12:03 PM<br><b>To:</b> Dean Coclin; CABFPub (public@cabforum.org)<br><b>Subject:</b> Re: [cabfpub] EV Wildcards<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Dean – while we are not passionate about this, the point we were trying to make is that with an EV certificate, users see the EV “green bar” and other information that is meant to enhance trust in the website. Users also see the full FQDN displayed in the green bar <u>[high-risk].example.com</u>, although most browsers appear to give prominence to the SLDN. Who knows what users really think, but this seems to give legitimacy to the idea that for an EV cert for <u>facebook.example.com</u>, the site has something to do with “Facebook” which it does not.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Again, EV vetting requires the CA to screen for High Risk Certificate Requests, which we have always interpreted as applying to the entire FQDN, and we assume many or most CAs would not issue an EV cert for <u>facebook.example.com</u>. In contract, if we allow wildcard EV certs, there would be no way the CA could perform a screening for High Risk Certificate Requests above the SLDN, and so a potentially misleading name like <u>facebook.example.com</u> could be displayed in the EV green bar. That’s the situation that concerns us.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Of course, BR 11.5 on screening for High Risk Certificate Requests (including screening for “names at higher risk for phishing or other fraudulent usage“ and “names that the CA identifies using its own risk-mitigation criteria“) already applies to ALL cert types, so I’m assuming a request for something like <u>facebook.example.com</u> in a DV or OV cert would trigger some sort of extra screening today for most CAs (it does for us – we won’t issue that cert). But there is less potential harm from wildcard DV and OV certs used to secure <u>facebook.example.com</u> because the browser UI for users in DV and OV does not highlight the FQDN as prominently as for EV. That’s our thinking.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Dean Coclin [<a href="mailto:Dean_Coclin@symantec.com">mailto:Dean_Coclin@symantec.com</a>] <br><b>Sent:</b> Thursday, March 26, 2015 8:47 AM<br><b>To:</b> Kirk Hall (RD-US); CABFPub (<a href="mailto:public@cabforum.org">public@cabforum.org</a>)<br><b>Subject:</b> RE: EV Wildcards<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='color:#1F497D'>We disagree with this line of thinking. Today someone can pay a few dollars and secure *.example.com, where the result is [high-risk].example.com with the most limited form of authentication. However a legitimate organization that successfully passes EV verification cannot order that same certificate. This makes zero sense — in fact, since the concern is with the exploit, this logic means that wildcards would be forced to the least authenticated customers. Hence we would support wildcards for EV certs.<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'>If we were going to change anything else (which is a completely separate discussion), it would be to put a minimum authentication requirement on the issuance of wildcards.<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'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Dean<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 #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> <a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a> [<a href="mailto:public-bounces@cabforum.org">mailto:public-bounces@cabforum.org</a>] <b>On Behalf Of </b><a href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a><br><b>Sent:</b> Wednesday, March 25, 2015 9:05 PM<br><b>To:</b> CABFPub (<a href="mailto:public@cabforum.org">public@cabforum.org</a>)<br><b>Subject:</b> [cabfpub] EV Wildcards<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>All the arguments on the question of allowing EV Wildcard certs are well considered and valid on both sides. Chris Bailey and I come down on the side of “no EV wildcard certs” for the following reason.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>It’s true that *.example.com could “hide” the use for <u>facebook.example.com</u>. It’s also true that the owner of example.com today could ask for an EV cert for <u>facebook.example.com</u>, and if the cert is issued, it’s “no different” from using a wildcard cert *.example.com.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>However, there is one important difference. BR 11.5 (High Risk Requests) and the related EV Guideline 11.12.1 require the following:<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal style='margin-left:.5in;text-autospace:none'><b><i>BR 11.5 High Risk Requests<o:p></o:p></i></b></p><p class=MsoNormal style='margin-left:.5in;text-autospace:none'>The CA SHALL develop, maintain, and implement documented procedures that identify and require <u>additional verification activity</u> for High Risk Certificate Requests prior to the Certificate’s approval, as reasonably necessary to ensure that such requests are <u>properly verified</u> under these Requirements.<o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p><p class=MsoNormal style='margin-left:.5in;text-autospace:none'><b>High Risk Certificate Request: </b>A Request that the CA flags for additional scrutiny by reference to internal criteria and databases maintained by the CA, <u>which may include names at higher risk for phishing or other fraudulent usage</u>, names contained in previously rejected certificate requests or revoked Certificates, names listed on the Miller Smiles phishing list or the Google Safe Browsing list, <u>or names that the CA identifies using its own risk-mitigation criteria</u>.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Among other things, we interpret that to require CAs to scan FQDNs for “names at higher risk for phishing or other fraudulent usage” at every level in the FQDN, and as a matter of policy, we generally won’t issue a cert for <u>facebook.example.com</u> unless the customer can show us it has Facebook’s permission. The same is true for a long list of other high risk names, and we apply the scan to all FQDNs in the SANs field as well.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>So this means that under our policy and interpretation a customer could not get an EV cert from us for <u>[high risk name].example.com</u>, which helps cut down on the likelihood of fraud or imitation. An EV cert for *.example.com, on the other hand, could be used to secure the same high risk name FQDN.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>We recognize that other CAs may not have a policy as restrictive as ours for EV certs, but if another CA issues an EV cert for <u>facebook.example.com</u> and it’s used for fraud or phishing – presumably that CA will get very adverse publicity, and will have some explaining to do to the public. That is likely to keep the number of such high risk name EV certs to a minimum. In contrast, no scanning or review will happen for EV wildcard certs.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>So in that sense, there is a difference, and we think wildcard certs should <i><u>not</u></i> be issued for EV – prohibiting EV wildcard certs makes CAs a bit more responsible, in our opinion.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><b><i><span style='font-size:14.0pt;font-family:"Bradley Hand ITC";color:#0F243E'>Kirk R. Hall<o:p></o:p></span></i></b></p><p class=MsoNormal>Operations Director, Trust Services<o:p></o:p></p><p class=MsoNormal>Trend Micro<o:p></o:p></p><p class=MsoNormal>+1.503.753.3088<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><table class=MsoNormalTable border=0 cellpadding=0><tr><td style='background:white;padding:.75pt .75pt .75pt .75pt'><table class=MsoNormalTable border=0 cellpadding=0><tr><td style='padding:.75pt .75pt .75pt .75pt'><pre><o:p> </o:p></pre><pre>TREND MICRO EMAIL NOTICE<o:p></o:p></pre><pre>The information contained in this email and any attachments is confidential <o:p></o:p></pre><pre>and may be subject to copyright or other intellectual property protection. <o:p></o:p></pre><pre>If you are not the intended recipient, you are not authorized to use or <o:p></o:p></pre><pre>disclose this information, and we request that you notify us by reply mail or<o:p></o:p></pre><pre>telephone and delete the original message from your mail system.<o:p></o:p></pre></td></tr></table></td></tr></table><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Times New Roman","serif"'><o:p> </o:p></span></p><table class=MsoNormalTable border=0 cellpadding=0><tr><td style='background:white;padding:.75pt .75pt .75pt .75pt'><table class=MsoNormalTable border=0 cellpadding=0><tr><td style='padding:.75pt .75pt .75pt .75pt'><pre><o:p> </o:p></pre><pre>TREND MICRO EMAIL NOTICE<o:p></o:p></pre><pre>The information contained in this email and any attachments is confidential <o:p></o:p></pre><pre>and may be subject to copyright or other intellectual property protection. <o:p></o:p></pre><pre>If you are not the intended recipient, you are not authorized to use or <o:p></o:p></pre><pre>disclose this information, and we request that you notify us by reply mail or<o:p></o:p></pre><pre>telephone and delete the original message from your mail system.<o:p></o:p></pre></td></tr></table></td></tr></table><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Times New Roman","serif"'><o:p> </o:p></span></p></div></body></html>