Re: Client-Cert Header draft

On Fri, Apr 17, 2020 at 12:23 PM Mike Bishop <mbishop@evequefou.be> wrote:

> Despite the distaste for client certificates from some quarters, they are
> still both used and useful.  I’m certainly interested in seeing this
> progress.
>
>
>
> In today’s situation, the intermediary checks that the cert matches the
> rules it has been given to authenticate clients, and only forwards the
> requests from valid clients.  Arguably, the origin is offloading less trust
> in this draft’s model – the intermediary is responsible for validating that
> the client possesses the claimed certificate, but might leave the origin to
> decide what scope of access the certificate actually grants.  That allows
> finer-grained access control, but also allows greater ability to send
> requests back to the origin.  It also opens the door for intermediaries
> which don’t support this header to accidentally forward requests containing
> it.  Requiring intermediaries to drop it doesn’t get you much, since only
> those intermediaries aware of the spec will comply by dropping the header.
> To help address these, I’d like to see this mix in something that the
> intermediary holds and the client doesn’t, such as an exporter from its TLS
> connection to the server.
>

I'm sure unsurprisingly to nobody, I second Mike's comments here.

-Ekr


>
> But all that is refinement – the core concept here is beneficial, and I’d
> like to see more engagement here.
>
>
>
> *From:* Brian Campbell <bcampbell@pingidentity.com>
> *Sent:* Wednesday, April 15, 2020 5:01 PM
> *To:* HTTP Working Group <ietf-http-wg@w3.org>
> *Subject:* Client-Cert Header draft
>
>
>
> Hello HTTP Working Group,
>
>
>
> I've somewhat inadvertently found myself working on this draft
> 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.*
>