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

[Nico Williams <[e-mail]>]

On Tue, Mar 31, 2026 at 08:00:21PM -0400, David Adrian wrote:
> > > Does the IETF have a Liason to the Chrome Root Program?
> 
> Speaking for the Chrome Root Program [1], the policy does not introduce a

Thanks for _finally_ responding.  I don't mean just "in this thread".

> blanket prohibition on all CAs from issuing TLS certificates containing
> both clientAuth and serverAuth EKUs. Rather, after March 15, 2027, the
> Chrome Root Store will, by default, only include anchors representing
> serverAuth-only hierarchies.

"Only", and yet the net effect on the Internet -meaning Internet
Standards, and the IETF standards process, but also the market for
Internet-related services and products- has been disruptive and
negative.  For example, this and other threads have taken a fair bit of
our time.  For another the disappearance of a valuable product/service.

> This does not preclude CAs from:
> - Continuing to issue from hierarchies that may be trusted elsewhere
> - Issuing clientAuth certificates from a new hierarchy

The net effect appears to have been to drive all CAs that used to issue
client certificates to no longer do so under _any_ root, not just the
ones in Chrome's trust anchor store.  Or are there any CAs that do issue
client certificates that I don't know about?

For SMTP and XMPP users are specifically interested in client
certificates with dNSName SANs.  Are there any organizations that have
ACME-style dNSName SAN clientAuth EE cert issuance?  I believe hte
answer is "no", but please disabuse me of that.

When CAs stop providing a valuable service to the market on account of
the Chrome Root Program policy change, then that policy has damaged the
market.  (If there was no way to securely provide that service, then
certainly everyone would agree that ending that service was the correct
thing to do, but _that_ proposition has not been made and is not in
evidence.)

When implementors race to allow clients to use certificates with only
serverAuth, the Chrome Root Program policy has damaged the Internet and
the policy has backfired.  We now have CAs in browsers' trust anchor set
that unwittingly issue client certificates because implementors are
removing the check for clientAuth -- surely this is the inverse of what
the program wanted.

To be fair I can't say yet whether _some_ applications accepting
serverAuth certs as client certs is a particularly bad outcome or a
tolerable one.  If it's just MTAs and XMPP servers, then maybe it's
tolerable.  The problem is that we don't know what more applications
will be affected, and we don't know whether this change will infect TLS
implementation libraries in ways that expose even more applications.

But what bothers me the most about this policy is that it obviously had
a high potential to make changes to RFC 5280 without the IETF approving
those changes.  The moment people suggested accepting serverAuth certs
as client certs is the moment the program should have rethought the
policy and sought to discuss it here or at the IAB at minimum.

You should reconsider your policy.  And in the future please be more
responsive.  Some of us tried to contact the program about this policy
long ago and never got even the courtesy of a non-answer response.

> Nothing also stops non-Chrome clients from altering the content of their
> trust stores to trust CAs relevant to their use case.

This is non-responsive.  If your policy has caused there to be no public
CAs that will issue these certificates, then that's a problem.

> History has taught us that commingling PKI use cases causes more harm than
> good. It is a consistent security problem when PKI hierarchies intended for
> public web sites get entangled in non-web use cases. As an example, such
> behavior slowed the deprecation of SHA-1 in 2018 because payment card
> terminal implementations and their corresponding root stores could not be
> updated.

That example cannot motivate this change.  Do you have a better example?
Changes of this magnitude should require discussion, and not just
between a closed group.  Near as I can tell there was no way for the
public to comment.

I don't see how the IAB, IESG, or IETF can possibly accept the program's
policy change or the program's behavior in light of this survey's
result, and I do not think they would have accepted it had they (we, in
the case of the IETF) been asked.

> The plan to move to serverAuth only was first communicated to CA Owners at
> a CABF meeting in 2021 [2]. It is designed to prevent more situations like
> the one above from happening in the future.

The CA Owners are not the public, and [2] is not public notice.  But
thanks for pointing out that you've been trying to make this happen
since 2021: that means that the policy change and the program's earlier
silence on it could not have been motivated by an urgent need to fix
some serious vulnerability since enough years have passed that it could
have been fixed.

Nico
--