<div dir="ltr">Alec,<div><br></div><div>Various design and security considerations went in to the choice of proposing EV for .onion. It wasn't necessarily meant to be the only way to obtain HTTPS certificates for .onion domains, but as a means of assuring (CAs, relying public) the balance of risks.</div><div><br></div><div>While not fundamentally opposed to exposing .onion for all (including DV), here's a set of considerations that went in to the design and discussion:</div><div><br></div><div>- At Google, we were (and are) concerned with the cryptographic strength of the .onion naming scheme, which employs both SHA-1 and RSA-1024. While only the TOR authors can properly mitigate these attacks on a long-term basis, the TOR Service Descriptor extension, combined with Certificate Transparency, can at least shed light onto these attacks, since if the SD differs-but-still-validates, then it's proof of an attack on SHA-1, and if an unauthorized-but-valid cert appears in the CT logs, then it's proof of a factoring attack on SHA-1. If allowed for any other types of certs, at present, then these mitigations would not necessarily be viable.</div><div><br></div><div>- Related to that first point, the choice of EV discourages attackers making such cryptographic attacks against sites operating .onion sites, as it requires some form of identity validation of who the attacker is, even if they have the cryptographic resources to mount such an attack. The goal of supporting those without linking real-world identities (such as via Richochet) is admirable and entirely understandable within the goals of TOR, yet it also significantly increases the risk for those who presently have .onion certificates, as it would be easier and viable for attacks against them to remain unattributed. I don't mean to suggest that EV is perfect at a defense against this, but, and especially combined with the CT requirement, subversion of a CA's process for issuing an EV cert would be a serious blow to the credibility and trust of that CA, and potentially lead to it becoming untrusted.</div><div><br></div><div>- While this is a position that we (Google) generally disagree with, many CAs feel that it should be their responsibility to police subscriber's content and revoke certificates whose content they (or their governments) disagree with. In general, and thankfully, this has primarily been limited to malware and phishing sites. Since CAs view this as a guarantee being offered by SSL (that the site is 'safe', for some nuanced definition of 'safe'), allowing a wild world of unattributable certificates is challenging to them. Note that some of these CAs have opposed DV at all, or have looked for means to make DV non-desirable (such as through restrictions on wildcards, shortened validity periods, or increased requirements). All of this is captured in past minutes and discussions of the Forum, and while I suspect there will be some disagreement on the 'intent', the effects of such proposals are clear. Because of this concern, it's likely that .onion certificates for anything less than strongly-validated corporate identities will be opposed on the principle of 'protect the users', an unfortunate mismatch for the guarantees that SSL/TLS is meant to provide, but alas, a deeply held belief for some.</div><div><br></div><div>So in contemplating a solution of how to make HTTPS for .onion domains more accessible - an entirely reasonable and extremely worthwhile goal - these concerns must be taken into consideration and balanced. I don't believe that an AV (I'm surprised to see that term; it's not in wide use) or IV cert may necessarily or reasonably help balance those concerns, but hopefully it provides further insight into the considerations and thoughts behind the current support, so that yourself or others might be able to provide a solution to thread those needles.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 6, 2015 at 7:24 AM, Ryan Sleevi <span dir="ltr"><<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Forward on behalf of Alec<div><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Alec Muffett</b> <span dir="ltr"><<a href="mailto:alec.muffett@gmail.com" target="_blank">alec.muffett@gmail.com</a>></span><br>Date: Fri, Nov 6, 2015 at 7:20 AM<br><br><div dir="ltr"><div><div>Hi CA/Browser Forum!</div><div><br></div><div>I'm a software engineer and one of the authors of RFC 7686[0]; since 2001 I have maintained a personal blog[1] and it's overdue for a complete software refresh. I want to take advantage of Let's Encrypt[2] to provide normal HTTPS certificates for the blog, and I want a 100% HTTPS deployment when I am done.</div><div><br></div><div>I intend also to provide my blog with an Onion Address, thus my question:</div><div><br></div><div>On my blog I do not represent a company - I act purely as an individual; I expect to easily get a "normal" domain-related certificate from Let's Encrypt, but as an individual I will not be able to get an EV certificate for my Onion Site as mandated by CA/B Forum Ballot 144[3].</div><div><br></div><div>This situation inhibits me from protecting my personal blog's Onion Site with some form of Onion HTTPS certificate.</div><div><br></div><div>It further discriminates against my choice of software deployment as an individual.</div><div><br></div><div>Perhaps I could run my blog as HTTP-over-Onion and HTTPS-over-Internet, but this breaks my goal of a 100% HTTPS deployment. Clients of my Onion Site would not have access to HTTPS-only "Secure" cookies and other functionality which browsers today (or will soon) restrict to HTTPS[4] sites, e.g. Camera & Microphone access. This would be an undesirable lack of consistency.</div><div><br></div><div>It is not viable to hack the Tor Browser to support an "Onion-only" CA, because only some portion of Tor traffic uses the Tor Browser; non-browser apps which use Tor would not be able take advantage of such a kludge, and thereby would not see the benefit of SSL.</div><div><br></div><div>In any case, ".onion" is now an official special-use TLD, and therefore should be supported by official means.</div><div><br></div><div>After a hint from Ryan Sleevi - plus referring to the Mozilla CA glossary[5] - I did some research and think that I need either an AV (address validation) or an IV (individual validation) SSL Certificate for my personal blog's Onion Site.</div><div><br></div><div>Discussing likely use cases with Runa Sandvik[6], we believe that people who use Tor desire (at least) all of privacy, anonymity and integrity. The option that seems most sympathetic to all of these requirements is the AV (address validation) certificate. An AV certificate would provide an Onion Address with an SSL certificate (and thus a form of persistent identity) corresponding simply to an RFC822 email address. This would appear extremely well-suited to users of Onion-backed instant messenger software, such as Ricochet[7], especially those communicating without reference to "real world" identities.</div><div><br></div><div>The alternative of an IV (individual validation) certificate appears closer to the goals of the EV certificate, being a more expensive "absolute identity" certificate that would (per the Glossary) require "a Driving License, Passport, or National Identity Card" to get. This would be useful for instances where people wish to publicly attest to ownership of what they write / blog / post / publish, but would be less useful e.g. for whistleblowers operating in repressive regimes.</div><div><br></div><div>Frankly I see a need for both, and would be (for this case in point) happy to get one of either, but am also open to other alternatives which would not require me to register a company to bootstrap.</div><div><br></div><div>So, finally, the question: how may I go about obtaining a suitable, personal, Onion-capable SSL Certificate for my blog, please?</div><div><br></div><div>- Alec Muffett, London</div><div><br></div><div><br></div><div>[0] <a href="https://tools.ietf.org/html/rfc7686" target="_blank">https://tools.ietf.org/html/rfc7686</a><br></div><div>[1] <a href="http://dropsafe.crypticide.com/" target="_blank">http://dropsafe.crypticide.com/</a></div><div>[2] <a href="https://letsencrypt.org/howitworks/" target="_blank">https://letsencrypt.org/howitworks/</a></div><div>[3] <a href="https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-names/" target="_blank">https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-names/</a></div><div>[4] <a href="https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/" target="_blank">https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/</a></div><div>[5] <a href="https://wiki.mozilla.org/CA:Glossary" target="_blank">https://wiki.mozilla.org/CA:Glossary</a></div><div>[6] <a href="https://twitter.com/runasand/status/662341004373204993" target="_blank">https://twitter.com/runasand/status/662341004373204993</a></div><div>[7] <a href="https://ricochet.im/" target="_blank">https://ricochet.im/</a></div><div><br></div></div><div><div>[ This e-mail is also posted at <a href="http://dropsafe.crypticide.com/article/11697" target="_blank">http://dropsafe.crypticide.com/article/11697</a> with additional context ]</div></div><span class="HOEnZb"><font color="#888888"><span><font color="#888888">-- <br><div><a href="http://dropsafe.crypticide.com/aboutalecm" target="_blank">http://dropsafe.crypticide.com/aboutalecm</a><br></div><div><br></div>
</font></span></font></span></div>
</div><br></div></div>
</blockquote></div><br></div>