[cabfpub] .onion proposal

[Ryan Sleevi]

On Nov 17, 2014 1:16 PM, "Jeremy.Rowley" <jeremy.rowley at digicert.com> wrote:
>
> 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.

I think this would be better expressed in the 9.2.1 / 11.1

The current language feels way too broad, which is already an issue with
the existing language. We should ensure that new language provides narrow
scoping and guidelines.

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

This would be an amendment to the EVGs, not the BRs, right? Again, specific
sections would help here.

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20141117/38c5a367/attachment.html