Re: Client-Cert Header draft

[Roberto Polli <[e-mail]>]

Hi Brian,

I think the work is interesting and useful, though it has complexities.

TL;DR: I'd only standardize the header semantic and file a detailed
Security Considerations
section with different sections addressing the different issues.

More follows:

1- standardizing the header name is good;
2- it is correct to investigate the impacts of this header when the
network topology is not trivial
    ( I see use cases for TTRP + re-encryption). I suggest providing subsections
    in the Security Considerations;
3- the only reason for trusting that header is an actual agreement
between the owners
    of the services: I am not sure we should detail things like `Use
of the technique is to be a configuration or deployment`
    but please provide your thoughts;
4- I am not sure that adding processing rules in the spec can provide more
    guarantees to the backend server,  as it's completely "delegating
the authentication"
    to the upstream server and cannot verify the received information.

My2c,
R.

Il giorno gio 16 apr 2020 alle ore 10:05 Brian Campbell
<[e-mail]> ha scritto:
>
> 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 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.
>
> 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.