W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2014

Re: FYI: proposal for client authentication in TLS

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 10 Mar 2014 11:19:15 +0100
Message-ID: <531D91A3.8050405@gmx.de>
To: "henry.story@bblfish.net" <henry.story@bblfish.net>, Martin Thomson <martin.thomson@gmail.com>
CC: HTTP Working Group <ietf-http-wg@w3.org>, Tim Berners-Lee <timbl@w3.org>
On 2014-03-10 10:16, henry.story@bblfish.net wrote:
> 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
> ...

Note: it would be

   WWW-Authenticate: ClientCertificate IAN=WebID

(see grammar in 

Best regards, Julian
Received on Monday, 10 March 2014 10:19:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:24 UTC