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

[Andrei Popov <[e-mail]>]

> 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.
In Google's defense, it's a policy for their own TRP; I would not expect public comment on corporate policy.

> 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.
Understood; the problem is that client names aren't scoped globally like Web server names, so conflicts are possible, leading to client impersonation.

> 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.
Just to clarify: the net negative you're referring to is that an extra certificate hierarchy (for client-only certs) needs to be configured on certain deployed TLS clients?

Cheers,

Andrei

-----Original Message-----
From: Nico Williams <[e-mail]> 
Sent: Wednesday, April 1, 2026 1:02 PM
To: Andrei Popov <[e-mail]>
Cc: Peter Gutmann <[e-mail]>; David Adrian <[e-mail]>; Mike Ounsworth <[e-mail]>; Salz, Rich <[e-mail]>; Tls <[e-mail]>; [e-mail]
Subject: Re: [lamps] Re: [EXTERNAL] [TLS] Re: Re: Re: Re: TLS Client Certificates; a survey

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