- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Fri, 25 Sep 2015 10:08:50 -0700
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Cc: Yoav Nir <ynir.ietf@gmail.com>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
On 25 September 2015 at 03:14, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: > What I tried to say above is that we don't know which cookie > identifies the session. That's definitely true. Cookies are a pretty crude tool for something like this. I think that your general observation about client certificates is overwhelmingly true. On the web at least, I'm seeing a general trend away from using the TLS layer to authenticate clients. If cookies are crude, client certificates make them look like a picture of sophistication by comparison. As you say, they are a poor fit for both the protocol and the architecture. What I neglected to mention earlier is that client certificate mechanism that was being added was viewed more as a necessary evil than an important feature. No one liked having to do this, but as Mark pointed out, there are far more people relying on having the functionality than we previously thought. I'd like to find other solutions for the use cases that drive this, but the view was that we still needed something like this so that we don't strand those users on old protocols. We don't have to *like* it though. There was strong agreement that this feature would be accompanied by a prominent and severe admonishment against using it. I definitely want to talk about what the alternatives look like, but perhaps we should start a separate thread on that subject.
Received on Friday, 25 September 2015 17:09:18 UTC