[cabfpub] .onion proposal

Jeremy Rowley jeremy.rowley at digicert.com
Thu Nov 13 00:53:47 UTC 2014


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.

From: Ryan Sleevi [mailto:sleevi at google.com]
Sent: Wednesday, November 12, 2014 5:40 PM
To: Jeremy Rowley
Cc: CABFPub
Subject: Re: [cabfpub] .onion proposal


On Nov 12, 2014 10:52 AM, "Jeremy Rowley" <jeremy.rowley at digicert.com<mailto:jeremy.rowley at digicert.com>> wrote:
>
> Hi everyone,
>
>
>
> 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:
>
>
>
> 1)      The CA MUST verify the applicant for an EV Certificate
>
> 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
>

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.

> 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
>

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?

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"

>
>
> 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.
>
>
>
> To facilitate the discussion moving forward, here is summary of the previous discussion:
>
> 1)      Although not delegated by IANA, .onion is recognized by Tor as an address used to provide anonymous services
>
> 2)      Tor uses its own encryption so the certificates are about identification
>
> 3)      .onion addresses are generated from the service provider’s key, meaning they are unique (you don’t choose the onion address)
>
> 4)      A certificate would permit service providers to remove their anonymity while preserving the anonymity of their clients
>
> 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
>
>
>
> Any thoughts on this?
>
>
>
> Jeremy
>
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org<mailto:Public at cabforum.org>
> https://cabforum.org/mailman/listinfo/public
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20141113/40bffecc/attachment-0003.html>


More information about the Public mailing list