Re: Client Certificates - re-opening discussion

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Fri, 18 September 2015 17:49 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39F701B2CCD for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 18 Sep 2015 10:49:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level:
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZsfzDTnZ0o2K for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 18 Sep 2015 10:49:29 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C5B61ACE02 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 18 Sep 2015 10:49:29 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1ZczjV-0004o9-2w for ietf-http-wg-dist@listhub.w3.org; Fri, 18 Sep 2015 17:46:01 +0000
Resent-Date: Fri, 18 Sep 2015 17:46:01 +0000
Resent-Message-Id: <E1ZczjV-0004o9-2w@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <ilari.liusvaara@elisanet.fi>) id 1ZczjQ-0004n7-4p for ietf-http-wg@listhub.w3.org; Fri, 18 Sep 2015 17:45:56 +0000
Received: from emh07.mail.saunalahti.fi ([62.142.5.117]) by maggie.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <ilari.liusvaara@elisanet.fi>) id 1ZczjO-0007Ow-GI for ietf-http-wg@w3.org; Fri, 18 Sep 2015 17:45:55 +0000
Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id BDE973FF7; Fri, 18 Sep 2015 20:45:30 +0300 (EEST)
Date: Fri, 18 Sep 2015 20:45:30 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Mark Nottingham <mnot@mnot.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20150918174530.GA9394@LK-Perkele-VII>
References: <63DECDF0-AB59-4AFD-8E48-8C2526FD6047@mnot.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <63DECDF0-AB59-4AFD-8E48-8C2526FD6047@mnot.net>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Received-SPF: pass client-ip=62.142.5.117; envelope-from=ilari.liusvaara@elisanet.fi; helo=emh07.mail.saunalahti.fi
X-W3C-Hub-Spam-Status: No, score=-4.8
X-W3C-Hub-Spam-Report: AWL=-0.851, BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: maggie.w3.org 1ZczjO-0007Ow-GI 156b9a34e8d549c2a1d0ca6e1da0cb93
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Client Certificates - re-opening discussion
Archived-At: <http://www.w3.org/mid/20150918174530.GA9394@LK-Perkele-VII>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/30217
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

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.


-Ilari