On Wed, Apr 01, 2026 at 06:52:58PM +0000, Andrei Popov wrote: > > So what actual problem was disallowing clientAuth intended to solve? > > I would invert this: what problem does a public CA-issued client cert > solve? [...]
If client certs was a greenfiled project, then that would be a fair question to ask. Given that it's not, and that uses existed, and users have been negatively impacted by a policy that was never publicized in the right places and for which no public comment was allowed, the only fair question is the original. > [...]? When is it OK for a TLS server app or service to trust every > client cert issued by an arbitrary root in a SW vendor's TRP? Typically applications that support client certificates will have a list of client _names_ that are allowed to access the service, or some other form of authorization ultimately keyed by the client's authenticated name. Applications that do not support client certificates will simply ignore client certificates. The inference you're making, that client certificates that chain to a WebPKI trust anchor somehow create a vulnerability in applications that either don't support client certificates for authorization (subsequent to authentication) or for ones that do, is not in evidence. By the way, I'm not objecting to having separate roots for client certs. What I am objecting to is the subsequent disappearance of a product from the market which was an indirect consequence of the policy change, and that disappearance is leading people to engage in workarounds that effectively defeat the policy change but in a way that is a net negative to the Internet. The policy change has simply backfired and needs revision. Nico -- _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
