- From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
- Date: Sat, 8 Mar 2014 14:43:48 +0200
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Sat, Mar 08, 2014 at 11:39:12AM +0000, Martin Thomson 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. Some comments: - Reference to RFC 5764 (which is some DTLS extension). Did you mean RFC 6347 (DTLS 1.2)? - "[...]need to authenticate can initial renegotiation, [...]". That sounds odd, should it be "initial" or "initiate"? - Under what circumstances server ignores the extension even if it is supported? Some points: - If the client has other active streams there, away might not be apropirate. - The 401 www-authenticate header value might contain some information about acceptable client certificates (similarly to TLS CertificateRequest), so the client can pick apropriate cerificate before initiating new connection. - The proper client certificate might have been issued by the server or service provoder. Or even be self-signed[1]. [1] I haven't seen self-signed client certs for HTTPS, but I have seen those for e.g. IRCS (Internet Relay Chat over TLS). -Ilari
Received on Saturday, 8 March 2014 12:44:13 UTC