Re: Client-Cert Header draft

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 <mailto: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./
>