RE: Client certificates in HTTP/2

There is also a pull request around adding client certificate support to TLS outside of renegotiation.  That can be found at: https://github.com/tlswg/tls13-spec/pull/209.  I think this is the best path forward -- maintaining the behavior in TLS and keeping the interaction consistent.  It does still leave us with the discussion of what to do in 1.2, but it sets the right path for the future.

There was some post-WG discussion that this PR should be split in two; one piece creating the new client cert mechanism and one piece expanding the ability to specify which certificate the server wants.  There's still work to be done here before it actually goes in, but this is a glimpse of the direction the TLS WG is moving.

-----Original Message-----
From: henry.story@bblfish.net [mailto:henry.story@bblfish.net] 
Sent: Thursday, September 3, 2015 7:28 AM
To: Yoav Nir <ynir.ietf@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: Client certificates in HTTP/2

I would like to point out that there is a discussion at the W3C Technical Architecture Group started by Tim Berners Lee relating to client certificates in the browser and authentication, following attempts by the WHATWG to deprecate the <keygen> functionality.

  https://lists.w3.org/Archives/Public/www-tag/2015Sep/0000.html


A good story about how one could authenticate in HTTP/2.0 using client certificates ( whatever form they take, be the JOSE or ASN1. ) would be extreemly helpful.

( I suppose there is a need to tie this into TLS to avoid man in the middle servers attacks like the secure resumption attack https://www.secure-resumption.com/ . Is that what the talk about "certificate slots" in SPDY is about? ) 

> On 9 Jun 2015, at 09:58, Yoav Nir <ynir.ietf@gmail.com> wrote:
> 
> Hi
> 
> Long time ago there was a long discussion about using client certificates on the web with HTTP/2. Feel free to skip the next paragraph if you remember the issue.
> 
> Most of the web does not use client certificates. Websites that do don’t like users to get a certificate picker when they first land on the page. So what they do is protect the site with regular, server-authenticated TLS and have a landing page. On the landing page there’s going to be something clickable that says “login with certificates”. When the user clicks that, it sends a request for some resource (maybe “/loginWithCerts.html”). When the server gets that request, it triggers the TLS layer to re-negotiate, this time with the certificate request message that causes the certificate picker to pop up. This is the way it’s usually done in HTTP/1, but for HTTP/2, section 9.2.1 prohibits this use or renegotiation and hints at future specification that might provide this.
> 
> So a year ago Martin Thomson wrote a pair of draft for solving this: one an HTTP authentication scheme that just says, “go away and come back with a certificate”, while the other is a TLS extension that tells the server that the client would like to authenticate:
> https://tools.ietf.org/html/draft-thomson-httpbis-catch-00

> https://tools.ietf.org/html/draft-thomson-tls-care-00

> 
> Neither was adopted, here or at TLS, so currently HTTP/2 is not usable with mutual authentication. Why has this (useful IMO) extension withered on the vine rather than progressed?  If anyone needs help in pushing this along, I’ll be glad to help.
> 
> Yoav
> 
> 

Social Web Architect
http://bblfish.net/

Received on Thursday, 3 September 2015 20:04:54 UTC