[cabfpub] .onion proposal

Ryan Sleevi sleevi at google.com
Mon Nov 17 23:27:55 UTC 2014

Right, I consider this MANDATORY before the Forum should allow issuance.
Luckily, this is being pursued to ensure .onion is reserved by IANA and not
delegated. But that remains to be approved/finalized.
On Nov 17, 2014 1:20 PM, "kirk_hall at trendmicro.com" <
kirk_hall at trendmicro.com> wrote:

> You may have covered this in an earlier email -- but why can't Tor simply
> obtain the .onion TLD from IANA?
> What if someone else obtains .onion?
> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
> Behalf Of Jeremy.Rowley
> Sent: Monday, November 17, 2014 3:15 PM
> To: public at cabforum.org
> Subject: Re: [cabfpub] .onion proposal
> Thanks to everyone who has commented so far.  Based on the feedback, I'm
> amending the proposal as follows:
> 1) Modify the definition of internal name to exclude reserved names
> approved by the Forum (which will only be onion as far as I know).
> Here's the language:
> Internal Name: A string of characters (not an IP address) in a Common Name
> or Subject Alternative Name field of a Certificate that cannot be verified
> as globally unique within the public DNS at the time of certificate
> issuance because it does not end with either (a) a reserved name approved
> by the CAB Forum under Appendix D or (b) a Top Level Domain registered in
> IANA’s Root Zone Database.
> 2) Add Appendix D that contains the following requirements:
> Although CAs are prohibited from issuing Internal Names as of 1 November
> 2015,  the following TLDs are outside the scope of this prohibition because
> of their delegation outside of IANA and use in certain communities
> supported by CA/Browser Forum members. In each case, the CA/Browser Forum
> has established set procedures for verifying the information contained in
> the Certificate. If there is any conflict between the procedures set forth
> in this appendix and the other controls established by the CA/Browser
> Forum, the procedures set forth in this appendix control.
> a) .onion
> .onion is a pseudo-top level domain name that is used to designated hidden
> services reachable within the Tor network. Prior to issuing a Certificate
> that contains a .onion Domain Name, the CA MUST:
> i) Verify that the Applicant controls the service provided at the
> requested .onion Domain Name by specifying a change to the service and
> verifying the Applicant made the change using the onion routing network.
> ii) Verify the Applicant's legal existence and identity, business
> presence, reliable method of communication, and operational existence in
> accordance with the CA/Browser Forum's EV Guidelines.
> Thoughts?
> Jeremy
> On 11/12/2014 6:34 PM, Brian Smith wrote:
> > On Wed, Nov 12, 2014 at 12:51 PM, Jeremy Rowley
> > <jeremy.rowley at digicert.com> wrote:
> >> 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.
> > I suggest that you redefine "internal name" so that .onion isn't
> > considered an internal name. I don't see much resistance to that.
> >
> >> 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
> > I don't think that this should be required. It could have very
> > negative consequences. In particular, whether this is even safe or not
> > depends on some unspecified/undocumented subtleties of how browsers
> > coalesce connections. Also, it seems unnecessary. We don't require
> > such a thing for the issuance of normal certificates, and I don't
> > think Tor is special here. In fact, for now, I would argue that the
> > certificate should only contain a single dNSName SAN entry, which
> > would be the single .onion address.
> >> 2)      Tor uses its own encryption so the certificates are about
> >> identification
> > It is true that Tor uses its own encryption, but HTTPS over Tor is
> > going to use HTTPS encryption too, right? And, there are significant
> > benefits to the HTTPS-level encryption.
> >
> >> 3)      .onion addresses are generated from the service provider’s key,
> >> meaning they are unique (you don’t choose the onion address)
> > As Facebook showed, you can control a significant part of the onion
> > address. However, it is too expensive and complicated to do so for
> > most people, so it would be unreasonable to force somebody requesting
> > a certificate to do what Facebook did. However, CAs should be aware of
> > the possibility of somebody generating addresses which are misleading
> > (e.g. contain trademarks of other companies) or addresses that are
> > confusingly similar to other addresses.
> >
> > I agree with your other points.
> >
> > Cheers,
> > Brian
> > .
> >
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
> <table class="TM_EMAIL_NOTICE"><tr><td><pre>
> 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>
> _______________________________________________
> Public mailing list
> 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/20141117/14a82bb2/attachment-0003.html>

More information about the Public mailing list