W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2015

Re: Client Certificates - re-opening discussion

From: <henry.story@bblfish.net>
Date: Tue, 22 Sep 2015 11:24:37 +0100
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <127A9C80-F0F0-486A-99F9-D3C459D306D9@bblfish.net>
To: Stefan Eissing <stefan.eissing@greenbytes.de>

> On 22 Sep 2015, at 10:08, Stefan Eissing <stefan.eissing@greenbytes.de> wrote:
> 
> 
>> Am 21.09.2015 um 20:23 schrieb Mike Bishop <Michael.Bishop@microsoft.com>:
>> 
>> I have no issue with defining something at the application layer that becomes a viable alternative to move toward.  In the meantime, though, we want a way for applications built on the old/current model to use HTTP/2.
> 
> Thanks, Mike. My feelings exactly.
> 
> We want sites to enable HTTP/2. We do not want them to crash and go down in flames, because the existing HTTP/1 config was not suitable. We'd like predictable (or at least defined) behaviour of clients when running into whatever the server sends back in such scenarios.
> 
> 
> In order to completely avoid renegotiations on HTTP/2 (and I think we all agree on that), one approach would be to force the client back to HTTP/1.1 using another (new or open) connection. The response should indicate the realm where this restriction applies.
> 
> Note that servers may be unable to trigger client certs on connection setup. This often happens on the first request, triggering a renegotiation. Often specific TLS parameters only apply to special locations on a server (in existing configurations - I do not say that this is a good approach).
> 
> This may be done by extending the 421 response with additional headers to indicate the desired behaviour. It would be good to hear from people on the client side what their thoughts about this are.

Ok, this does make the use case much clearer: how does one allow a company with an HTTP/1.1 enabled web site using client certificates to switch to HTTP/2.0 without the site acting very differently ( e.g. with parts of the page showing the user as not logged it whilst still showing in other parts information only that user can see ).

The problem is that there also is another use case: a web site that wishes to use all the advantages of HTTP/2.0 (SPDY) to build sites that use it for what it was designed for: namely highly data driven Single Page Application that requires a lot of connections, and that takes into account the asynchronous nature of HTTP/2.0 by redrawing the web page as data becomes available to create a coherent view.

So one would ideally like a TLS+Certificate answer that can satisfy both use cases. 

Is that a correct summary?

Henry


> 
> //Stefan
> 
> <green/>bytes GmbH
> Hafenweg 16, 48155 Münster, Germany
> Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
> 
> 
> 
> 

Social Web Architect
http://bblfish.net/
Received on Tuesday, 22 September 2015 10:25:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:46 UTC