- From: Adrien de Croy <adrien@qbik.com>
- Date: Tue, 09 Jun 2015 21:34:48 +0000
- To: "Mike Bishop" <Michael.Bishop@microsoft.com>, "Yoav Nir" <ynir.ietf@gmail.com>, "HTTP Working Group" <ietf-http-wg@w3.org>
------ Original Message ------ From: "Mike Bishop" <Michael.Bishop@microsoft.com> To: "Yoav Nir" <ynir.ietf@gmail.com>; "HTTP Working Group" <ietf-http-wg@w3.org> Sent: 10/06/2015 5:51:39 a.m. Subject: RE: Client certificates in HTTP/2 <snip> > >A client which has a client cert ready to offer will send an extension >setting TLS_RENEG_PERMITTED advertising that it's willing to accept a >server-initiated renegotiation. > I don't really like this approach. When would the client send this option? a) always -> let's tell every site we have a client cert b) only on sites where the client previously received a request for a cert -> yay another database to maintain c) after some strange UI (open this link with client cert) d) by magic What's wrong with being challenged for a client cert, it's just like being challenged for auth, we're not proposing deprecating 403 are we? Some sites may wish to make it conditional whether a client cert is required based on other things. This requirement to pre-advertise support just seems like bad engineering when TLS already has a mechanism to deal with client certs Adrien
Received on Tuesday, 9 June 2015 21:37:09 UTC