[cabfpub] .onion proposal

Brian Smith brian at briansmith.org
Wed Nov 12 18:34:41 MST 2014


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


More information about the Public mailing list