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