<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 12, 2015 at 6:33 PM, <a href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a> <span dir="ltr"><<a href="mailto:kirk_hall@trendmicro.com" target="_blank">kirk_hall@trendmicro.com</a>></span> wrote:<span style="color:black"> </span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><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></p></div></div></blockquote><div><br></div><div>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)</div><div><br></div><div>facebookcorewwwi is a random name. That it has symbolic meaning in English is something that happens with any random system, given sufficient time.</div><div><br></div><div>Would these concerns go away if Item #5 was removed from the ballot (the automatic extension if IESG reserves)?</div><div><br></div><div>While I think this discussion is useful to a degree, I do have some concerns:</div><div><br></div><div>- Under the current provisions, anyone can issue for .onion, so this is by no means worse in any quantifiable way</div><div><br></div><div>- Under the current provisions, using a .onion with HTTP is objectively less secure than using a .onion name with HTTPS</div><div>  - A .onion name is based upon an RSA-1024 bit key, which is the only security protection in play here.</div><div>  - A .onion name is denied access to privacy-and-security enhancing technologies (due to browsers restricting access to features not delivered over secure transports)</div><div><br></div><div>- 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...)</div><div>  - Anyone using .onion names can create facebookwwwcore1.onion, given sufficient time and energy</div><div>  - 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)</div><div>  - 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)</div><div><br></div></div>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?</div></div>