Re: Client-Cert Header draft

Justin Richer <jricher@mit.edu> Fri, 17 April 2020 21:02 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 (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 030133A017E for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 17 Apr 2020 14:02:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.651
X-Spam-Level:
X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 QU0MXr_V-0CE for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 17 Apr 2020 14:02:18 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 261F33A0143 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 17 Apr 2020 14:02:17 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1jPY4d-0002SL-85 for ietf-http-wg-dist@listhub.w3.org; Fri, 17 Apr 2020 20:58:55 +0000
Resent-Date: Fri, 17 Apr 2020 20:58:55 +0000
Resent-Message-Id: <E1jPY4d-0002SL-85@lyra.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <jricher@mit.edu>) id 1jPY4c-0002Ri-PN for ietf-http-wg@listhub.w3.org; Fri, 17 Apr 2020 20:58:54 +0000
Received: from outgoing-auth-1.mit.edu ([18.9.28.11] helo=outgoing.mit.edu) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <jricher@mit.edu>) id 1jPY4a-000773-85 for ietf-http-wg@w3.org; Fri, 17 Apr 2020 20:58:54 +0000
Received: from [192.168.1.13] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 03HKweUO012846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 17 Apr 2020 16:58:40 -0400
From: Justin Richer <jricher@mit.edu>
Message-Id: <C8B0E972-CE82-495D-B657-E5B52B6EAE20@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2B818CF5-4293-454F-A77D-848C32B7EBF8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Fri, 17 Apr 2020 16:58:40 -0400
In-Reply-To: <CA+k3eCRQhuS9TyEVdF6ZAfLSyPngjDLvctUTc++2Ok+RJmw0qA@mail.gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
To: Brian Campbell <bcampbell@pingidentity.com>
References: <CA+k3eCRQhuS9TyEVdF6ZAfLSyPngjDLvctUTc++2Ok+RJmw0qA@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-W3C-Hub-Spam-Status: No, score=-10.2
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1jPY4a-000773-85 650b84057347edf8416e9b3dbc228105
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Client-Cert Header draft
Archived-At: <https://www.w3.org/mid/C8B0E972-CE82-495D-B657-E5B52B6EAE20@mit.edu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37515
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: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

+1 for seeing this adopted and progressing within this group. This is a simple thing that different developers have had to solve for decades and each has solved it in trivially different ways. I would love to see one commonly-accepted way to do this.

TLS terminators aren’t going away any time soon, so I think we should make them at least a bit more manageable. 

 — Justin

> On Apr 15, 2020, at 5:01 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
> 
> Hello HTTP Working Group,
> 
> I've somewhat inadvertently found myself working on this draft https://datatracker.ietf.org/doc/draft-bdc-something-something-certificate/ <https://datatracker.ietf.org/doc/draft-bdc-something-something-certificate/>, which aspires to define a "Client-Cert" HTTP header field that allows a TLS terminating reverse proxy to convey information about the client certificate of a mutually-authenticated TLS connection to an origin server in a common and predictable manner.
> 
> I presented the concept <https://datatracker.ietf.org/meeting/107/materials/slides-107-secdispatch-client-cert-http-header-00> at the recent virtual IETF 107 secdispatch meeting <https://datatracker.ietf.org/meeting/107/materials/minutes-107-secdispatch-00> and the outcome from that was basically that there seems to be some interest in pursuing the work and the suggestion that the conversation be taken to the HTTPbis WG (and also keep TLS WG involved - presumably if the work progresses). And that's what brings me here. I also hope to get a little bit of time at one of the upcoming virtual interims to present/discuss the draft.
> 
> Thanks,
> Brian 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.