<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:"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;}
@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"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Thanks Ryan. I’m very happy to specify the verification of .onion at the protocol level (rather than just saying “verify with Tor”). I’ll work something up
and end it over.<o:p></o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></a></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> Wednesday, November 12, 2014 5:40 PM<br>
<b>To:</b> Jeremy Rowley<br>
<b>Cc:</b> CABFPub<br>
<b>Subject:</b> Re: [cabfpub] .onion proposal<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p><br>
On Nov 12, 2014 10:52 AM, "Jeremy Rowley" <<a href="mailto:jeremy.rowley@digicert.com">jeremy.rowley@digicert.com</a>> wrote:<br>
><br>
> Hi everyone,<br>
><br>
> <br>
><br>
> I’d like to continue the .onion discussion that I started here about a month ago. Primarily, I’d like to see how we can create a very limited exception to the general prohibition on internal name certificates that will take effect in 2015 for the purpose
of permitting the CA community to show support for both Tor and entities operating .onion names. Here’s what I propose as issuance requirements:<br>
><br>
> <br>
><br>
> 1) The CA MUST verify the applicant for an EV Certificate<br>
><br>
> 2) The CA MUST verify a non-onion domain name owned by the applicant and assert that domain name in the same certificate as the .onion address<br>
><o:p></o:p></p>
<p>If we go down this route, I would prefer to see a white listed subset of verification methods here. In particular, I have reservations for both nontechnical demonstrations (e.g. opinion letters / "equivalent methods") and for file-based schemes.
<o:p></o:p></p>
<p>> 3) The CA MUST verify the applicant’s control over the .onion name using a practical demonstration of control that is verifiable through the Tor browser<br>
><o:p></o:p></p>
<p>I'm also not a fan of coupling this to "What the TOR Browser says". How .onion names work and is documented - can we find a way to express this demonstration through specifying how at the protocol level one must verify?<o:p></o:p></p>
<p>For example, consider if there was a bug in TBB version X, fixed in Y - it would be unambiguous how to verify if you specified it in protocol terms (since X failed to do those protocol things, and Y fixed the bug and thus does do them), but ambiguous if
you just say "Verify in the TOR browser"<o:p></o:p></p>
<p>> <br>
><br>
> Obviously, if supported, I’d need revise the language to fit with the BR/EV framework before a vote is possible. However, I think this is general framework is a good starting point for continued discussion and hope it will help us find a solution that everyone
agrees with.<br>
><br>
> <br>
><br>
> To facilitate the discussion moving forward, here is summary of the previous discussion:<br>
><br>
> 1) Although not delegated by IANA, .onion is recognized by Tor as an address used to provide anonymous services<br>
><br>
> 2) Tor uses its own encryption so the certificates are about identification<br>
><br>
> 3) .onion addresses are generated from the service provider’s key, meaning they are unique (you don’t choose the onion address)<br>
><br>
> 4) A certificate would permit service providers to remove their anonymity while preserving the anonymity of their clients <br>
><br>
> 5) Continued use of certs for .onion is important for companies like Facebook who would like to facilitate free speech in countries that do not necessarily recognize that as a fundamental right<br>
><br>
> <br>
><br>
> Any thoughts on this?<br>
><br>
> <br>
><br>
> Jeremy<br>
><br>
> <br>
><br>
><br>
> _______________________________________________<br>
> Public mailing list<br>
> <a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
> <a href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a><br>
><o:p></o:p></p>
</div>
</body>
</html>