- From: <henry.story@bblfish.net>
- Date: Fri, 18 Sep 2015 19:11:20 +0100
- To: HTTP Working Group <ietf-http-wg@w3.org>
> On 18 Sep 2015, at 18:45, Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote: > > On Thu, Sep 17, 2015 at 06:10:49PM -0400, Mark Nottingham wrote: >> Hi, >> >> We've talked about client certificates in HTTP/2 (and elsewhere) >> for a while, but the discussion has stalled. >> >> If you have a proposal or thoughts that might become a proposal >> in this area, please brush it off and be prepared. Of course, we >> can discuss on-list in the meantime. > > Basically, the ways I know one could do client certs in HTTP/2 have > both been floated before: > > 1) Signal about client cert being needed, client can establish > new connection for the authenticated stuff. > > 2) Do client cert at HTTP level, using the usual HTTP authentication > headers and TLS channel binding mechanisms[1] (but certificates > themselves require some special handling, due to size[2]). > > > [1] SPDY/3 did something like this, except with its own frame > types. > > [2] Bit crazy idea: PUT with .well-known resource. You mean: don't send the certificate, link to it on the web? Then you are close to WebID-TLS http://www.w3.org/2005/Incubator/webid/spec/ WebID-TLS only published the public key, but one could also publish the full certificate. ( people had suggested that before, but we were waiting for larger use cases to consider it ) The advanage following that pattern is you put the certificate anywhere you like, not just in .well-known. You can think of the WebID-profile document as a certificate linked on the web. Then we are close to the WebID-RSA and HTTP-signature proposals I mentioned earlier, but Mark pointed out that its out of scope in this thread. I could open another thread to discuss those when/if people are interested. Henry > > > -Ilari > Social Web Architect http://bblfish.net/
Received on Friday, 18 September 2015 18:11:52 UTC