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

Re: FYI: proposal for client authentication in TLS

From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 10 Mar 2014 10:39:05 +0100
Message-ID: <CABkgnnWav+7tp-72=eVO=CE7SearZTSNJuokk96ut5kiRZiawQ@mail.gmail.com>
To: "henry.story@bblfish.net" <henry.story@bblfish.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, Tim Berners-Lee <timbl@w3.org>
On 10 March 2014 10:16, henry.story@bblfish.net <henry.story@bblfish.net> wrote:
> 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.

My reading of the certificate_authorities text is that it can be
ignored, if " there is some external arrangement to the contrary" --
http://tools.ietf.org/html/rfc5246#section-7.4.4

> 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

This seems like a reasonable extension is exactly an "external
arrangement" as above.  That's certainly how I'd do it.

Given the time-critical nature of this work, I'm reluctant to add
anything extra in the current draft, but I don't see any reason that a
new specification couldn't define this sort of extension.  I have no
opinion about whether this needs to be defined here in the IETF, or
elsewhere, but I'm not aware of a rule that prevents either.
Received on Monday, 10 March 2014 09:39:32 UTC

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