<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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","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
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.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]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal" style="text-autospace:none"><b><i>BR 11.5 High Risk Requests<o:p></o:p></i></b></p>
<p class="MsoNormal" style="text-autospace:none">The CA SHALL develop, maintain, and implement documented procedures that identify and require additional verification activity for High Risk Certificate Requests prior to the Certificate’s approval, as reasonably
necessary to ensure that such requests are properly verified under these Requirements.<o:p></o:p></p>
<p class="MsoNormal" style="text-autospace:none"><b><o:p> </o:p></b></p>
<p class="MsoNormal" style="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, which may include names at higher risk for phishing or other fraudulent usage, names contained in previously rejected certificate requests
or revoked Certificates, names listed on the Miller Smiles phishing list or the Google Safe Browsing list, or names that the CA identifies using its own risk-mitigation criteria.<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">We won’t issue certs for microsoft.example.com, googleserver.example.com, etc., even though our customer owns example.com. I think the same concerns would
apply to .onion certs, for the same reason.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<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""> Ryan Sleevi [mailto:sleevi@google.com]
<br>
<b>Sent:</b> Thursday, February 12, 2015 6:44 PM<br>
<b>To:</b> Kirk Hall (RD-US)<br>
<b>Cc:</b> Gervase Markham; Jeremy Rowley (jeremy.rowley@digicert.com); Ben Wilson (Ben.Wilson@digicert.com); CABFPub (public@cabforum.org)<br>
<b>Subject:</b> Re: [cabfpub] Ballot 144 -.onion domains<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Thu, Feb 12, 2015 at 6:33 PM, <a href="mailto:kirk_hall@trendmicro.com">
kirk_hall@trendmicro.com</a> <<a href="mailto:kirk_hall@trendmicro.com" target="_blank">kirk_hall@trendmicro.com</a>> wrote:<span style="color:black"> </span><o:p></o:p></p>
<div>
<div>
<p><span style="color:black">In contrast, a .onion domain name will be displayed to Tor users, and could cause confusion. Should we require CAs to follow the rules of BR 9.2.4g so that .onion domains that include meaningful names are verified? Or better yet,
not allow .onion domains to be meaningful (require them to be random only)?</span><o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">How do you define meaningful? How do you define random? In quantifiable ways that can either be audited or inspected by third-parties (e.g. via Certificate Transparency)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">facebookcorewwwi is a random name. That it has symbolic meaning in English is something that happens with any random system, given sufficient time.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Would these concerns go away if Item #5 was removed from the ballot (the automatic extension if IESG reserves)?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">While I think this discussion is useful to a degree, I do have some concerns:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">- Under the current provisions, anyone can issue for .onion, so this is by no means worse in any quantifiable way<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">- Under the current provisions, using a .onion with HTTP is objectively less secure than using a .onion name with HTTPS<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - A .onion name is based upon an RSA-1024 bit key, which is the only security protection in play here.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - A .onion name is denied access to privacy-and-security enhancing technologies (due to browsers restricting access to features not delivered over secure transports)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">- The concerns regarding 'spoofability' of a .onion name exist independent of any discussion in the Forum. That is, it is, at it's core, a TOR protocol "issue" (I'm not sure I would call it that, but for sake of discussion...)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - Anyone using .onion names can create facebookwwwcore1.onion, given sufficient time and energy<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - DNS spoofing exists entirely in the Baseline Requirements (CAs are only required to document their procedures regarding high risk requests. They are not prohibited from issuing such phishy names, per 11.5 of the BR 1.2.3)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - DNS spoofing exists entirely in the EV Guidelines (CAs are only required to inspect mixed-script domains, per 11.7.1 p2 of the EVG 1.5.2)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal">Nothing prohibits <a href="http://facebookcorewwwi.com">facebookcorewwwi.com</a> and
<a href="http://facebookcorewww1.com">facebookcorewww1.com</a> from purchasing certificates, EV or DV, provided they demonstrate control over that namespace. Why would or should .onion be any different?<o:p></o:p></p>
</div>
</div>
</div>
</body>
</html>
<table><tr><td bgcolor=#ffffff><font color=#000000><pre><table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential
and may be subject to copyright or other intellectual property protection.
If you are not the intended recipient, you are not authorized to use or
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
</pre></td></tr></table></pre></font></td></tr></table>