[cabfpub] .onion proposal
brian at briansmith.org
Wed Nov 19 13:22:53 MST 2014
Gervase Markham <gerv at mozilla.org> wrote:
>> I don't think that this should be required. It could have very
>> negative consequences.
> It may not be required, but it should certainly be allowed. A strong
> cryptographic binding between a non-Tor and a Tor identity is an awesome
> thing, because a browser who encountered the cert on a non-Tor site
> would then know for certain how to connect over Tor in the future. In
> fact, it would be cool if someone specced out the right way of doing that.
Your argument about the usefulness of specifying a way to identify a
Tor-based alternative service is one reason to not allow it now, when
there's no spec for doing that. (FYI, Mozilla has been trying to
standardize a different, but similar, mechanism for finding "Alternate
Services" in the IETF HTTP working group.) The fewer legacy
certificates there are to deal with, the more likely that
standardizing such a mechanism will be useful.
Also, when you say "it should certainly be allowed," do you mean that
you verified that browsers do the correct thing with respect to SPDY
and HTTP/2 connection coalescing when a certificate has both an .onion
and a non-.onion dNSName subjectAltName? I think TorBrowser probably
does the right thing, but I could see how it could easily go wrong. It
seems like unnecessary risk.
More information about the Public