- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 11 Mar 2014 08:10:02 +0100
- To: Yoav Nir <ynir.ietf@gmail.com>, Martin Thomson <martin.thomson@gmail.com>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
On 2014-03-11 07:16, Yoav Nir wrote:
> 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.
Why?
It seems to me that 401 is totally applicable here.
> 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.
<http://tools.ietf.org/html/draft-thomson-httpbis-catch-00#section-2>
already says:
A challenge with this auth-scheme does not define the use of any
parameters other than "realm". Other parameters MAY be used to
provide a client with information it can use to select an appropriate
certificate. Unknown parameters MUST be ignored.
The question is whether the draft needs to be more specific.
> 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?
In HTTP/2, we forbid renegotiation (I believe), that a UA that speaks
HTTP/2 will know what to do. (But then, how does this work for 2.0<->1.1
intermediation?)
Best regards, Julian
Received on Tuesday, 11 March 2014 07:10:32 UTC