- From: Kyle Rose <krose@krose.org>
- Date: Mon, 21 Sep 2015 12:58:53 -0400
- To: Henry Story <henry.story@co-operating.systems>
- Cc: Stefan Eissing <stefan.eissing@greenbytes.de>, Yoav Nir <ynir.ietf@gmail.com>, Mike Bishop <Michael.Bishop@microsoft.com>, Eric Rescorla <ekr@rtfm.com>, Ilari Liusvaara <ilari.liusvaara@elisanet.fi>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
> It is true that authentication at the TLS layer is much rougher, as > I think the client can only authenticate with 1 certificate not more, > per connection. Right, and the inability to support this leads to a bunch of kludgey-feeling solutions, like 421s. This situation was always possible with HTTP/1.1, but is a lot more likely with H2. Pushing the authentication into the application layer seems like it could be cleaner. Provide browser support for setting a CertificateVerify header (e.g., based on a signature of the channel binding), something that can be cached by the client and server and reused on all relevant streams over the same connection. Signalling for "you need to authenticate" and sending the client certificate to the server would then be entirely at the application layer, possibly with the support of HTTP status codes, and TLS client certificate authentication wouldn't be used in this case. This sort of application layer approach may also make a better client UX more natural, by moving the logic for prompting the user for a certificate into the web app UI. Kyle
Received on Monday, 21 September 2015 16:59:29 UTC