RE: Client Certificates - re-opening discussion

[Mike Bishop <[e-mail]>]

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.

For your forward-facing model, there will need to be something more than just posting the cert -- there has to be a proof that the private key is owned.  But the general model of doing it at the app level is a direction to explore.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Monday, September 21, 2015 11:06 AM
To: HTTP Working Group <[e-mail]>
Subject: Re: Client Certificates - re-opening discussion


> On 21 Sep 2015, at 17:58, Kyle Rose <[e-mail]> wrote:
> 
>> 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.

So there is another question: are the two incompatible? 

It may also be worth having the old solution for a transition period, until new answers come up. Then as they prove themselves, which should be easy as they will be a lot more flexible ( but also therefore in danger of more misimplementations ), the older TLS certificate system can go away.

> 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.

The idea would be for example that a 401 with a 

 WWW-Authenticate: Certificate, upload="/certs" 

The client could then POST the (x509?) certificate to that location, and receive a Location: header containing a URL that it could re-use on future connections, and which it could use for authentication with something like draft-cavage-http-signatures [1]

The nice thing, is that this would allow one to also use URLs of certificates  on remote servers, to avoid the whole process of certificate uploads. ( but the problem of people not having a server would be solved by the POST described above )

Also this provides an easy way to disable certificates by removing them from that URL.

You could then further do content negotiation on that URL and allow many different formats to be returned, enabling a move to JSON certificate formats a la JOSE or based on JSON-LD.

> 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.

Would that require the client to also be able to independently get access to the channel binding? 

Wether the WebAPP UI can do this will depend on wether the WebApp can intercept the 401's sent by the server. This is the type of thing that could be done by ServiceWorkers [2] I am told, but figuring that out from the spec is not really easy. I am going to send a message to the WebApps group to verify that this is possible across origins.

Still even if WebApps were able to do this authentication across origins, it would still be very useful for the browsers themselves to be able to authenticate to a remote origin without going through these WebApps, so that one could test out resources outside of an App. Ie. I think there will always be a need for browsers to provide cross origin authentication mechanisms. WebApps will be more flexible to innovate, but the successful ones should be rolled into the browser.


Henry

[1] https://tools.ietf.org/html/draft-cavage-http-signatures-04

[2] Which just started gone into Candidate Recommendation and feedback is 
saught
https://slightlyoff.github.io/ServiceWorker/spec/service_worker_1/

> 
> Kyle
> 

Social Web Architect
http://bblfish.net/