Fwd: FYI: proposal for client authentication in TLS

The draft-thomson-tls-care comes with a draft-thomson-httpbis-catch. 
I wrote to the https-bis mailing list with the following suggestion.

Begin forwarded message:

> From: "henry.story@bblfish.net" <henry.story@bblfish.net>
> Subject: Re: FYI: proposal for client authentication in TLS
> Date: 10 March 2014 10:16:01 CET
> To: Martin Thomson <martin.thomson@gmail.com>
> Cc: HTTP Working Group <ietf-http-wg@w3.org>, Tim Berners-Lee <timbl@w3.org>
> 
> 
> 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/
> 

Social Web Architect
http://bblfish.net/

Received on Monday, 10 March 2014 09:24:28 UTC