[cabfpub] .onion proposal

Jeremy Rowley jeremy.rowley at digicert.com
Mon Nov 17 22:56:08 MST 2014

It’s not a disservice if the Forum agrees to restrict onion issuance to the prescribed process, especially since we know onion is on route to an RFC as a reserved name.

Again – I’m not looking (or even interested in) an exception to the elimination of true internal server names. However, onion is a well know and beneficial service, in use today, and, unlike other internal server names, can be verified as uniquely controlled by an applicant. Considering the time required for RFC adoption and that unrestricted issuance to onion names is a current security risk (because it falls under the internal name umbrella), the Forum could greatly improve the security in that space by simply adopting validation rules that apply even while the RFC is pending.

From: Ryan Sleevi [mailto:sleevi at google.com]
Sent: Monday, November 17, 2014 10:45 PM
To: Jeremy Rowley
Cc: CABFPub; kirk_hall at trendmicro.com
Subject: RE: [cabfpub] .onion proposal

For every single reason why a responsible CA should not be issuing internal server names now - there is zero guarantee they won't be squatting on a name or future delegation.

If the Forum can not agree on suitable language before the sunset, the practice will be forbidden until such a time. If CAs do engage in issuing .onion names, then they do so knowing they do a disservice to the internet community, as excellently spelled out in Brad's paper that the Forum has circulated.

I'm not fundamentally opposed to .onion, but it is well known that we view the continued issuance of internal server names as a real security risk to the Internet at large, and that is why Chrome actively detects and rejects them - because any promise of security is illusory.
On Nov 17, 2014 7:42 PM, "Jeremy Rowley" <jeremy.rowley at digicert.com<mailto:jeremy.rowley at digicert.com>> wrote:
Why is it mandatory?  The Forum already allows issuance of .onion names as internal server names. Unfortunately, this means some CAs may not be verifying the name correctly.  Since onion is already in use, it’d be better to adopt the rules now while we work in the IETF to support adoption of the RFC reserving the name.


From: Ryan Sleevi [mailto:sleevi at google.com<mailto:sleevi at google.com>]
Sent: Monday, November 17, 2014 4:28 PM
To: kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com>
Cc: CABFPub; Jeremy Rowley
Subject: Re: [cabfpub] .onion proposal

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<mailto:kirk_hall at trendmicro.com>" <kirk_hall at trendmicro.com<mailto: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> [mailto: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<mailto: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.



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<mailto: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<mailto:Public at cabforum.org>

<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.
Public mailing list
Public at cabforum.org<mailto:Public at cabforum.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20141118/901c3008/attachment-0001.html 

More information about the Public mailing list