Re: Client Certificates - re-opening discussion

["[e-mail]" <[e-mail]>]

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