[lamps] Re: [EXTERNAL] [TLS] Re: Re: Re: Re: TLS Client Certificates; a survey

[Nico Williams <[e-mail]>]

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