Re: Client Certificates - re-opening discussion

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

> On 21 Sep 2015, at 15:28, Kyle Rose <[e-mail]> wrote:
> 
>>> The difference is that now the sane design is mandatory, else you get unpredictable results. A sane design works with renegotiation, #209 and HTTP-layer authentication
>> 
>> Not even then. Client may reuse connections on matching certs. There are installations out there that have a cert for +3 domain names, lets say A, B and C. A has anonymous access, B and C both require different client certs. Depending on which tab the browser load first, the one or the other cert gets loaded in, leading the other site to fail since the cert is not accepted.
> 
> Yeah, this is a huge issue that doesn't appear in HTTP/1.1. It sounds
> to me like the real problem is trying to shoehorn application-layer
> client authentication into the transport layer.

How is this different from say if one authenticated to each resource
using public keys at the HTTP layer [1]. We could imagine here A, B and C,
being resources on the same server even with A only accessible by somone 
who can prove he is over 18, the other by someone how is a member of this 
working group, ( provable using either a WebID or an OpenID ), etc.... 

There are two signals the server can set up to help the user agent select
a certificate: A 401 not Authorized, and perhaps a link to an access
control resource that would describe who can have access [2].  The client
needs some logic to help select a certificates or credential to respond 
to the request while putting the user in control, and without being too
much of a pain.

As I understand Martin Thomson  suggested an HTTP header

WWW-Authenticate: Certificate

sent at the HTTP layer, that could then start the certificate 
connection at the TLS layer.  The client could also try to narrow 
down from the ACL list to see if it is even worth bothering the 
user to ask him for a Certificate, and perhaps warn him that some 
links cannot be  followed, because of the lack of access.

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.

But part of the problem you mention has more to do with the logic of
the user agents credential selection and the problems of protected
resources across origins ( which everybody is familiar when looking
at YouTube links that are viewable in one country but not in another ).

Henry

[1] As suggested by one of the following 

• Andrei Sambra's first sketch authentication protocol           
 https://github.com/solid/solid-spec#webid-rsa
• Manu Sporny's more fully fleshed out HTTP Message signature     
 https://tools.ietf.org/html/draft-cavage-http-signatures-04

[2] Following work described here for example
  http://www.w3.org/wiki/WebAccessControl


> 
> Kyle


Social Web Architect
http://bblfish.net/