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: Tue, 11 Mar 2014 09:22:17 +0100
Message-ID: <CABkgnnX38kK3OoUKsq4_CqcQZsE94Sv37B7mWH091dF3oi+EGg@mail.gmail.com>
To: Yoav Nir <ynir.ietf@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
I think that Julian covered some of the points here.

On 11 March 2014 07:16, Yoav Nir <ynir.ietf@gmail.com> wrote:
> 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.

It seems like 401 is OK to me.

> 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 user.

I considered a number of options, but none seemed particularly useful.
 The CertificateRequest in TLS already has a set of DNs.

> 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?

This can be very simple.  The server initiates renegotiation.  A
browser that doesn't support this feature will accept the
renegotiation and whatever happens today, happens.

A browser that supports this feature will reject the renegotiation (a
no_renegotiation alert in response to the hello request) and the
server can send its 401 response.
Received on Tuesday, 11 March 2014 08:22:45 UTC

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