Re: FYI: proposal for client authentication in TLS

On 9 Mar 2014, at 08:37, Martin Thomson <martin.thomson@gmail.com> wrote:

> On 8 March 2014 11:39, Martin Thomson <martin.thomson@gmail.com> wrote:
>> Pursuant to our discussion on TLS renegotiation, I've submitted part 1
>> of the solution I proposed as an internet draft.
>> 
>> http://datatracker.ietf.org/doc/draft-thomson-tls-care/
>> 
>> If we agree to a mechanism whereby we augment the 401 status code with
>> a "go away and make a new TLS connection with client authentication",
>> then this is necessary, so that the server knows to request a client
>> certificate.
> 
> Now with part 2:
> 
> http://datatracker.ietf.org/doc/draft-thomson-httpbis-catch/

I really like both of these.  I allready responded on the TLS mailing list
about draft-thomson-tls-care [1]. For draft-thomson-httbis-catch I would
like to suggest an improvement that would be essential for "self-signed"
or rather "unknown server signed" certificates, i.e., certificates signed
by some server that is not a CA. This allows for much more widespread
creation of client certificates, since they don't anymore need to be
verified by a few CAs, but instead allows the deployment of a web of
trust - a linked data web of trust to be precise. This allows one client
side certificate to be used to sign on to any web site.

A WebID is just an http(s) URL that refers to an Agent ( human, robot, 
organisation, ...) We have defined it in the spec "WebID 1.0" [2]. One
can then place a WebID in the Subject Alternative Name (SAN) field of an X509 
certificate as shown  in WebID Authentication over TLS [3] ( or even in the 
Issuer Alternative Name field (IAN)). The last spec relies on TLS as it is
currently, but would be redundant if draft-thomson-httpbis-catch went through.
(Until wide deployment of TLS1.3 which I suppose may take some time). 

Now I am not absolutely sure where this improvement I want to suggest, 
needs to be added: at the HTTP layer, or at the TLS layer. Currently TLS
allows a server to specify using the certificate_authorities list what
the list of Certificate Authorities the server accepts, so that the client
does not send Certificates that are not signed by one that is known to the server,
and which the server would then have to refuse.
But with WebID Authentication we don't need a CA, so it would be nice to be
able to specify that the server knows how to do WebID verification, ie part
5 and 6 of 
  http://www.w3.org/2005/Incubator/webid/spec/tls/#authentication-sequence
bB
If in TLS the server sends the empty certificate_authorities list. But that
is too wide, since that means the client can send ANY Certificate. The
server may not know what to do with most of them ( other than perhaps
identify the user indirectly by the public key, but that is only minimally
interesting - it does not allow one to build a web of trust ). 
 
My guess is that since this could evolve faster than the TLS layer, it may
be better if this were done in the HTTP header. So perhaps a header like

  WWW-Authenticate: ClientCertificate,SAN=WebID

would do. One could also imagine a 

  WWW-Authenticate: ClientCertificate,IAN=WebID

so that services with a lot of WebIDs could allow people to verify certificates
by verifying the issuer. A client seeing this would know that if the
server sent the empty certificate_authorities list, that it could filter its
available certificates by those that have the SAN or IAN fields filled in.

We have quite a few implementations of WebID on numerous servers, and in
pretty much every language, and we are finding it very useful. To get
a full overview of how this ties into a bigger picture including Web Access
Control, other authentication schemes, Linked Data Protocol,  etc... see our main 
intro page

  http://www.w3.org/2005/Incubator/webid/spec/

Hope this helps.

  Henry


[1] http://www.ietf.org/mail-archive/web/tls/current/msg11449.html
[2] http://www.w3.org/2005/Incubator/webid/spec/identity/
[3] http://www.w3.org/2005/Incubator/webid/spec/tls/

> 

Social Web Architect
http://bblfish.net/

Received on Monday, 10 March 2014 09:17:07 UTC