[cabfpub] Revised .onion proposal

[Ryan Sleevi]

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).