[cabfpub] Revised .onion proposal

[Jeremy Rowley]

> (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.
[JR] Thanks - I'll make the change.

> 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?
[JR] They don't.  I'll add a small amendment to 11.1.1 saying that .onion names should be verified in accordance with Appendix F rather than 11.1.1.

> 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.
[JR] Why do you need more than one per cert?  You can always provide another cert with a separate hash.  I'm not opposed but that seems unnecessary since the browsers won't be using this info (unless Mozilla has plans to use it?).

> 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?
[JR] No - it's being worked on.  Adoption will help drive it forward.

> 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.
[JR] Correct - I'm not planning on resolving it beforehand. I'm hoping it will help encourage the IESG to move things along.