[cabfpub] Revised .onion proposal

[Ryan Sleevi]

On Mon, Jan 5, 2015 at 9:42 AM, Jeremy Rowley
<jeremy.rowley at digicert.com> wrote:
> Now that it’s a new year, I thought we should revive the onion discussion.
> Here’s the latest proposal.  The changes from the last version include use
> of ASN.1 notation to describe the extensions and a clarification that the
> certs must still expire by the current CAB Forum deadline until the onion
> name is officially reserved by IESG.  Any additional commnets?
>
>
>
> Applicants want a CA-signed .onion address for several reasons, including:
>
> -              Powerful web platform features are restricted to secure
> origins, which are currently not available to onion names (in part, because
> of the lack of IANA registration).  Permitting EV certs for onion names will
> help provide a secure origin for the service, moving onion towards use of
> powerful web platform features.
>
> -              Currently, access to .onion names over https from a standard
> browser results in the standard existing 'Invalid Certificate' warning.
> Training users to click through security warnings lowers the value of these
> warnings and will cause users to miss important security information.
> Removing these warnings for the user, through use of a digital certificate,
> will help users recognize and avoid real MITM attacks.

Is there any browser beyond Chrome that does this? That is, prohibit
CAs from issuing from internal names? That is, your wording suggests
the only possible way to get .onion names is via an internal /
non-public CA, but this isn't entirely true, and if a public CA (such
as Digicert) issues for .onion, they won't get an error (... except in
Chrome, for the reason being that we prohibit public CAs from issuing
to non-IANA assigned domains ahead of the BR deprecation)

>
> -              The public needs attribution of ownership of the .onion
> address to differentiate onion services, including potential phishing
> services. Because onion names are not easily recognizable strings, providing
> the public with additional information about the operator has significant
> security improvements, especially in regions where use of the incorrect name
> could have lethal consequences.

<insert standard rant about phishing protection/non-protection from
certificates>

That said, if this is just the introduction to the ballot, and not
part of the normative text, then I think these objections can be noted
but may not require any textual change. We'll just point to this
thread if someone says silence was assent and move on :)

>
>
>
> This proposal amends the EV Guidelines to provide clear guidelines on how a
> CA may issue certificates for .onion addresses.
>
>
>


Our support to co-endorse this ballot still stands. Thanks for the
added details.