+1 for removing tls_client_auth_root
> Am 28.08.2017 um 20:24 schrieb John Bradley <ve7...@ve7jtb.com>: > > Having discussed it with Brian, I agree that removing “tls_client_auth_root” > is the way to go. > It would be hard to implement in some cases, and it is up to the AS to > configure the roots it trusts for client authentication. > > In reality every TLS client auth deployment is likely to have custom rules > about trust. I think this parameter adds confusion rather than reducing it. > > John B. > > >> On Aug 28, 2017, at 10:05 AM, Brian Campbell <bcampb...@pingidentity.com> >> wrote: >> >> Some feedback was received recently off-list that pointed out difficulties >> with implementation around the "tls_client_auth_root_dn" constraint in the >> PKI method of OAuth MTLS client authentication from >> draft-ietf-oauth-mtls-03. Basically the feedback was that popular web >> servers such as Nginx and Apache don't expose sufficient information (easily >> or in some cases at all) from the client certificate chain to the >> application to enable proper checking of "tls_client_auth_root_dn". >> >> Following from that and some additional reasoning below, I'm proposing that >> "tls_client_auth_root_dn" be dropped from the draft-ietf-oauth-mtls draft. >> >> The original idea behind the "tls_client_auth_root_dn" client metadata >> parameter came from an MTLS client authentication feature we added to our AS >> product years ago. The feature provided a way to allow the AS to more >> tightly constrain trust in a particular context (from an otherwise global >> list of trust anchors). It was fine as a specific product feature but should >> have stayed at that. When I added metadata to the OAuth MTLS draft, I added >> the "tls_client_auth_root_dn" parameter with that AS product feature in mind >> as something an AS *might* want to be able to do (without thinking thorough >> it all sufficiently). But having it as a client metadata parameter has wider >> implications including shifting trust control to the client and requiring >> ASs to support it. So, after thinking about it some more and also seeing the >> potential implementation difficulties, I don't believe it's appropriate to >> have in the specification. The AS should be at liberty to do chain >> validation with the PKI method however is most appropriate for it. And not >> be required to support one specific way of doing things implied by >> "tls_client_auth_root_dn" (which is even infeasible to implement in some >> environments). >> >> >> >> 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._______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
