[cabfpub] Revised .onion proposal

[Dean Coclin]

Remind me, are the certs being described below intended to be DV, OV or EV? Or all of the above?

Thanks.

-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi
Sent: Wednesday, January 07, 2015 12:33 AM
To: Jeremy Rowley
Cc: CABFPub
Subject: Re: [cabfpub] Revised .onion proposal

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.
_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6130 bytes
Desc: not available
Url : https://cabforum.org/pipermail/public/attachments/20150107/2c89ca95/attachment-0001.bin