Re: Client-Cert Header draft

On 15 Apr 2020, at 23:01, Brian Campbell <bcampbell@pingidentity.com> wrote:

> 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.

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 <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.

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.

Regards,
Graham
—