Re: Client-Cert Header draft

That's really quite different than the intended scope of the draft, which
was/is a reverse proxy that's terminating TLS (from the client's
perspective anyway) and taking HTTP with the backend.

On Fri, Apr 17, 2020 at 3:25 PM Soni L. <fakedme+http@gmail.com> wrote:

> if I may, I'd like to suggest a websocket-like mechanism that's initiated
> by TLS terminators.
>
> if the TLS terminator thinks a request needs to reach the server, it can
> let the client request directly from the server that way, including client
> certs and whatnot. if done right, this would also allow protection of other
> sensitive user data (e.g. direct messages) from the TLS terminator.
>
> On 2020-04-17 5:58 p.m., Justin Richer wrote:
>
> +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/,
> 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.*
>
>
>
>

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