[TLS] TLS-OBC proposal

[Dirk Balfanz <[e-mail]>]

Dear TLS-WG,

I few weeks ago I presented a proposal for an "origin-bound certificates"
TLS extension at IETF 81. It's much easier to understand what this extension
is trying to accomplish when presented in a broader context of web
authentication (which I tried to give in Quebec), so I put together a little
web site that is supposed to do just that for those who couldn't be at the
IETF meeting: http://browserauth.net (This took me a little while, hence the
delay in sending out the I-D).

Anyway, here is the I-D: http://tools.ietf.org/html/draft-balfanz-tls-obc,
which I submit for your comments/feedback. (Again, remember to read
http://browserauth.net for some context.)

All feedback is welcome, of course, but if you can't think of anything to
comment on, I have a couple particular questions:

- in Section 2.1.1 we currently stipulate that the client include the origin
of the origin-bound cert as part of the OBC X.509 extension. When we
implemented this, we didn't really know what to do with that data on the
server side. If the client also uses TLS-SNI, then we could imagine
comparing the SNI and OBC origins in some manner on the server side, but
there isn't really a vehicle to signal an error back to the client saying
"your SNI and OBC origins don't match". Similarly, we could perhaps at some
higher layer compare the HTTP "Host" header with the OBC origin, but then
again - what do you do when they don't match? Respond with a 400 at the HTTP
layer? An alternative to the current language in the I-D would be to simply
mark the cert as origin-bound, but without putting the origin itself into
the cert. Any thoughts?

- What do you think of the privacy-enhancing power of using per-origin
certs? The idea there is that different domains see different "identities"
(public keys) for the same client. Of course, if two domains choose to
collaborate, they can probably find a way to correlate the two identities
they see for the same client. This is similar to cookies, where normally
"identities" (cookies) for one domain are not revealed to another domain
unless, of course, they choose to collaborate. How much privacy would we
really lose if we just used one certificate for all origins? It would
certainly make the design and implementation simpler. (I tend to favor
per-origin certs, but I'm curious as to what other people think.)

Thanks for your consideration!

Dirk.