Re: Client Certificates - re-opening discussion

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


Received on Monday, 21 September 2015 16:59:29 UTC