Re: [TLS] TLS-OBC proposal

[Chris Richardson <[e-mail]>]

I think the draft is inconsistent with respect to the
certificate_authorities list.

>From section 3.3: "[if both sides include the extension], client and
server are considered to have negotiated origin-bound client
certificates for the session."

No problem there.

>From section 3.4: "the server MAY use an empty "certificate_authorities" list"

Should that be a MUST, or at least a SHOULD?  If OBC has been
negotiated, why would a CA-signed cert be used?

>From section 3.4: [the client] MUST ignore the "certificate_authorities" list

No problem there, but it again makes me think the server SHOULD/MUST
send an empty list.

Section 3.5: If the "certificate_authorities" list in the Certificate
Request is empty, that certificate SHOULD be an origin-bound
certificate, and it should be selected by the client without any
assistance or approval by the end-user. If the
"certificate_authorities" list in the Certificate Request is not
empty, the client MAY select a regular certificate for inclusion in
the Client Certificate message, and MAY involve the end-user in the
certificate selection process."

The client MUST ignore the list, but MAY take action based upon the
content of the list?


Chris


On Mon, Aug 22, 2011 at 1:53 PM, Dirk Balfanz <[e-mail]> wrote:
>
> 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.
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>