[cabfpub] Revised .onion proposal

[Jeremy Rowley]

Good points.  I was thinking it'd be in addition to the dNSName SAN.  Another potential downside is if someone is already using the otherName for something else. Using it for the key might cause confusion (since, as you mentioned, it's not the actual name of the service) or a conflict.

-----Original Message-----
From: Ryan Sleevi [mailto:sleevi at google.com] 
Sent: Monday, January 12, 2015 5:03 PM
To: Jeremy Rowley
Cc: Tom Ritter; Gervase Markham; CABFPub
Subject: Re: [cabfpub] Revised .onion proposal

On Mon, Jan 12, 2015 at 3:56 PM, Jeremy Rowley <jeremy.rowley at digicert.com> wrote:
> Thanks Tom and Gerv - I'll update the draft to permit multiple SANs.
>
> However, I received a suggestion that we use the otherName in the SAN instead of creating a brand new extension.  What do people think about this?

Are you suggesting *not* using the dNSNames in the SAN, exclusively using otherName, or are you suggesting using the Tor key identifier in the otherName in *addition* to the dNSName SAN?

Using otherName exclusively:
- Has the downside that it won't work with any existing applications (something that, with TOR's .onion naming scheme, originally tried to accomodate - whether through network-level redirects or proxy
configurations)
- Has the upside that it supports multiple values & schemes

Using otherName in addition to:
- Has the downside that it may have unforeseen interactions with nameConstraints in some applications (unknown)
- Some semantic ambiguity as to whether the key is really a name (the name is technically the .onion name)

I don't have strong feelings, other than I suspect that exclusively will fail to meet the use cases set forward in the proposal, and using it in addition to is going to have some weird interactions (that may also cause it to fail to meet use cases).