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

Re: FYI: proposal for client authentication in TLS

From: Yoav Nir <ynir.ietf@gmail.com>
Date: Tue, 11 Mar 2014 08:16:15 +0200
Message-ID: <CAGvU-a57wsvyDf980psq7x5774YeRAM09OZM8_YwAdska=RABg@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Hi, Martin

Thanks for writing these drafts. Three comments about this one:

1. I would prefer a special response code that says "go away and don't come
back without a certificate" rather than reusing 401, but that's just an
aesthetic issue, not substantive.

2. I'm wondering if the message sent to the client can be expanded enough
so that the browser sometimes does not need to pop up a certificate picker.
For example, suppose I use a certificate with DN "CN=ynir,OU=users" to log
in to my SSL-VPN portal. The portal has stored this information in my
browser via a cookie. If a string representation of this DN in sent in the
401 message, the browser can open the new connection without bothering the

3. There is the issue of discovery. With current browsers (and TLS 1.0-1.2)
the server initiates a renegotiation. A new browser (with TLS 1.0-1.3)
would use this new mechanism. How does the server tell an old browser from
a new one?


On Sun, Mar 9, 2014 at 9:37 AM, 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/
Received on Tuesday, 11 March 2014 06:16:44 UTC

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