I mean the cert that the ORIGINAL client presented to the proxy. From: Rifaat Shekh-Yusef <rifaat.i...@gmail.com> Date: Tuesday, October 29, 2019 at 7:57 AM To: Rich Salz <rs...@akamai.com> Cc: Neil Madden <neil.mad...@forgerock.com>, Brian Campbell <bcampbell=40pingidentity....@dmarc.ietf.org>, oauth <oauth@ietf.org> Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt)
Maybe I misunderstood what you meant by "client-cert". If you meant the proxy client certificate, then that is obviously not enough. You seem to suggest that you meant the remote client certificate to be installed on the proxy to be used with the backend system; if this is the case, then this would work and you would not need the signature, but the issue I see with this approach is that you need to reconfigure the proxy every time you change the client certificate, which is not practical if the certificate is short lived. Regards, Rifaat On Mon, Oct 28, 2019 at 2:55 PM Salz, Rich <rs...@akamai.com<mailto:rs...@akamai.com>> wrote: * To avoid the misconfiguration issue Neil raised, you probably need both: a client-cert and a signature over the certificate being forwarded, I am not so sure. One can argue that transport-level identity should be secured by transport-level. But installing a client certificate on a reverse proxy can be difficult. (Not if the reverse proxy is a CDN, of course :) And I don’t see how having both prevents misconfiguration, but that might be my fault. * This could still be achieve by extending RFC7239 with new parameter(s). I have no opinion on this part of it.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
