[cabfpub] Revised .onion proposal

[Jeremy Rowley]

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?

-----Original Message-----
From: Tom Ritter [mailto:tom at ritter.vg] 
Sent: Saturday, January 10, 2015 10:37 AM
To: Gervase Markham
Cc: Jeremy Rowley; CABFPub
Subject: Re: [cabfpub] Revised .onion proposal

On 9 January 2015 at 10:51, Gervase Markham <gerv at mozilla.org> wrote:
>> 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?).
>
> The Tor folks would need to chip in, but with my limited understanding 
> I can see value in comparing the TorServiceDescriptorHash with the 
> hash of the actual service descriptor, at least in the Tor browser.
>
> More generally, I've come across several situations (e.g. OCSP!) where 
> someone says "hey, we'd only ever need one of these" and it turned out 
> to be wrong. Algorithm agility is important; if it's not complex to 
> allow multiple hashes with different algos in the standard, we should do it.


I guess I'm a bit confused.  If a certificate contained multiple SANs for (e.g.) exampleimg09876.onion, examplestatic09876.onion, examplecorewww098.onion - wouldn't the certificate need to have multiple Tor Service Descriptor Hash extensions for each of those
(separate) keys?  (I think multiple domains are allowed in EV, but I guess I'm not 100% certain.)  It seems like it would need multiple for this reason alone... as well as some sort of indicator for which one maps to which.



Also coming down the pipe (on an unknown timeline) is an expansion of the .onion URLs - moving from the current length (e.g.
unlikelynamefora.onion) to something like a1uik0w1gmfq3i5ievxdm9ceu27e88g6o7pe0rffdw9jmntwkdsd.onion .  This will be a new key.  I don't know what the transition plan will be, but it seems likely folks would want a cert with both the old and new .onion.  I don't think this has a huge impact on this discussion though.  Either multi-name certs are allowed, and this is fine, or they aren't, and people will need separate certs for the old and new .onion. (Or maybe they want separate certs anyway.)

On the specific topic of whether Tor would want multiple copies of the extension covering multiple hash algorithms for a single .onion key...
I don't think the plumbing to compare the service descriptor and the certificate field is present right now - but I do appreciate algorithm agility highly.  So I'd lean in that direction.

-tom