[cabfpub] .onion proposal

[Jeremy.Rowley]

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