Re: Client-Cert Header draft

Graham Leggett <> Tue, 21 April 2020 22:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 258373A0C03 for <>; Tue, 21 Apr 2020 15:21:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.749
X-Spam-Status: No, score=-2.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id svGNLu6aj3IX for <>; Tue, 21 Apr 2020 15:21:17 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 01FFF3A0BFF for <>; Tue, 21 Apr 2020 15:21:11 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jR1D6-00086i-4y for; Tue, 21 Apr 2020 22:17:44 +0000
Resent-Date: Tue, 21 Apr 2020 22:17:44 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jR1D5-00085x-7i for; Tue, 21 Apr 2020 22:17:43 +0000
Received: from ([2001:470:18b1:0:5054:ff:fe6e:d541]) by with esmtp (Exim 4.92) (envelope-from <>) id 1jR1D1-0007we-0F for; Tue, 21 Apr 2020 22:17:43 +0000
Received: from [IPv6:2001:470:18b1:1:39d9:a4f3:4a64:5fb2] (unknown [IPv6:2001:470:18b1:1:39d9:a4f3:4a64:5fb2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: by (Postfix) with ESMTPSA id 828BA2891D0; Tue, 21 Apr 2020 23:17:27 +0100 (BST)
DKIM-Filter: OpenDKIM Filter v2.11.0 828BA2891D0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1587507447; bh=hGgbAlj2WtBZkaW+2yVopE6R+rY/kqIYMGv1bQpjmHM=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=BsI6nLuafGWQNqGGhxr9wYNG6EbYYsPSTMegrN/OaPZwqwkx4RdO22q4Mmpu1DXsI JRSo2wv1drNpQ42t/VO5VFbZOXfTmasWsExp6R4/Xa9Al+Au0W0C5DA+kOIDhI9e/c bbVDM+7N2CjbQOqpW38TtEpcD96dqtuz/vrKsrL0=
From: Graham Leggett <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_1CB151C5-409D-4EFE-B672-8C169AAC16F2"; protocol="application/pkcs7-signature"; micalg="sha-256"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 22 Apr 2020 00:17:17 +0200
In-Reply-To: <>
Cc: HTTP Working Group <>
To: Brian Campbell <>
References: <>
X-Mailer: Apple Mail (2.3445.104.11)
Received-SPF: pass client-ip=2001:470:18b1:0:5054:ff:fe6e:d541;;
X-W3C-Hub-Spam-Status: No, score=-4.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1jR1D1-0007we-0F 3d29b5997fd1422e39ae6bf54e627811
Subject: Re: Client-Cert Header draft
Archived-At: <>
X-Mailing-List: <> archive/latest/37535
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 15 Apr 2020, at 23:01, Brian Campbell <> wrote:

> I've somewhat inadvertently found myself working on this draft <>, 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.

Big +1 for this.

I added JWT support to Apache httpd/apr in an effort to solve this problem, having one single header would be vastly simpler.

> I presented the concept <> at the recent virtual IETF 107 secdispatch meeting <> 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.

Having read the draft, one thing I would suggest is that the ability exists for the contents of the Client-Cert header to be signed, so that anyone who cares can verify that the header came from where it said it came from.

To simplify this even further, if the Client-Cert header was signed by the private key of the certificate of the server that terminated the request, a lot of complexity around figuring out the origin of the header evaporates. (I wouldn’t make this a MUST requirement, but maybe RECOMMENDED perhaps).

As an optional one step further I personally would then connect the terminating reverse proxy and the backend with a client certificate connection using the TTRP reverse proxy’s certificate. The backend can then verify the client certificate (the TTRP cert) as being expected, then verify that the Client-Cert header was signed with the TTRP certificate. If this checks out, and we trust the TTRP as having not been tampered with, we have a strong path.

"A certificate is represented in text as an "EncodedCertificate",
   which is the base64-encoded (Section 4 of [RFC4648]) DER [ITU.X690]
   PKIX certificate.”

To do this the payload of the Client-Cert header would be a base64 of a DER encoded RFC5652 CMS/PKCS7. The payload would be the DER encoded X509 client certificate, and the CMS would be the signed envelope.