- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Tue, 11 Mar 2014 09:22:17 +0100
- 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