[cabfpub] Revised .onion proposal

[Gervase Markham]

On 05/01/15 17:42, Jeremy Rowley wrote:
> -              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.

Even with Ryan's misgivings, I do feel that there's value to be had here
- if we accept that not everyone has the resources to do what Facebook
did, most onion names are opaque strings, unlike DNS names, which are at
least human-readable. So an alternative route for ownership identity
info could be very useful.

Even if you can notice the difference between
www.bankofthewest.com
and
www.bankofthevvest.com

can you easily notice the difference between
silkroadbdimw7rj.onion
and
silkroadbdlmw7rj.onion
?

> (1) For each Fully-Qualified Domain Name listed in a Certificate other
> than a Domain Name with .onion in the right-most label of the Domain
> Name, 

This is a good way of describing them; we should use it here:

> Appendix F – Issuance of Certificates for .onion Domain Names A CA may
> issue an EV Certificate containing the .onion Domain Name

"containing the .onion Domain Name" is not as good a description.

> the CA SHALL confirm that, as of the date the Certificate was
> issued, the Applicant (or the Applicant’s Parent Company, Subsidiary
> Company, or Affiliate, collectively referred to as “Applicant” for the
> purposes of this section) either is the Domain Name Registrant or has
> control over the FQDN using a procedure specified in Section 11.1.1 of
> the Baseline Requirements, except that a CA MAY NOT verify a domain
> using the procedure described 11.1.1(7).

Hang on; doesn't Appendix F give the list of permitted methods? How do
section 11.1.1 and the list in Appendix F relate?

> cabf-TorServiceDescriptorHash OBJECT IDENTIFIER ::= { 2.23.140.1.31 }
> 
> TorServiceDescriptorHash:: = SEQUENCE {
> 
>                algorithm               AlgorithmIdentifier
> 
>                subjectPublicKeyHash    BIT STRING      }
> 
> Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC
> 6234) performed over the DER-encoding of an ASN.1 SubjectPublicKey of
> the .onion service and SubjectPublicKeyHash is the hash output.

Is it possible to have multiple ones of these per cert? That needs to be
necessary for transitioning to new hash algorithms.

> a.      The CA MAY verify the Applicant’s control over the .onion
> service by posting a specific value at a well-known URL under RFC5785.
> [NOTE: This is subject to change depending on whether we can register a
> well-known URL for onion]

Are you planning to resolve this before we vote on a motion?

> 5.    CAs MUST NOT issue a Certificate containing an .onion Domain Name
> with a validity period longer than 15 months. Despite Section 9.2.1 of
> the Baseline Requirements deprecating the use of Internal Names, a CA
> MAY issue a Certificate containing an .onion name with an expiration
> date later than 1 November 2015 after (and only if) .onion is officially
> recognized by the IESG as a reserved TLD. 

Do we yet have a timeline on this?

Effectively, this puts pressure on the IESG process because if they
don't do this by Nov 1st 2015, then all .onion SSL stops working.
Perhaps that's good or bad, but I am just noting it.

Gerv