Re: FYI: proposal for client authentication in TLS

[Julian Reschke <[e-mail]>]

On 2014-03-10 10:16, [e-mail] wrote:
>
> On 9 Mar 2014, at 08:37, Martin Thomson <[e-mail]> wrote:
>
>> On 8 March 2014 11:39, Martin Thomson <[e-mail]> 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 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-26.html#access.authentication.framework>)

Best regards, Julian