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

[Nico Williams <[e-mail]>]

On Wed, Apr 01, 2026 at 02:55:24PM -0700, Eric Rescorla wrote:
> WARNING: Potentially bad idea ahead.
> 
> id-kp-serverAuth is actually defined for "TLS WWW server
> authentication", so ISTM that using it for an SMTP server is actually
> already not really conforming to the Extended Key Usage requirements
> in RFC 5280. I'm not as familiar with the specifications for SMTP and
> XMPP, but AFAICT they don't update RFC 5280 to expand the meaning
> of serverAuth.

Which is why I was suggesting new EKUs, but yeah, deploying new EKUs for
existing protocols is not easy.

> [...]
> 
> Given that using certificates with {client,server}Auth in these
> other protocols is already off the fairway, it seems like we could,
> if we wanted, clarify matters by (1) explicitly permitting
> serverAuth in these protocols and (2) stating that for at
> least some of them, server-to-server connections needed the
> TLS client to have a serverAuth certificate rather than
> (or more likely in addition to) a clientAuth one, but with
> serverAuth preferred going forward.
> 
> This may well be a bad idea, and people should definitely feel
> free to say so, but it seems like at least one potential
> way out of this mess, given that we know that a lot of
> endpoints are going to do this in any case.

Ironically this _could_ be a bad idea if the Chrome Root Program policy
change was a good idea, unless there is something about this use case
that elides whatever problems there were with clientAuth cert issuance
by WebPKI CAs.

On the other hand, this could be a desirable change anyways.  Which
would also be ironic given my complaints about ending up here (but my
complaints are about process or lack thereof).

To take this proposal seriously -which we should- we need to understand
the vulnerabilities that the Chrome Root Program policy change was meant
to prevent.  So far we've not seen a reference to a single CVE.

But also: how much does this differ from changing the Chrome Root
Program policy to say that intermediate CAs chaining to WebPKI roots can
only issue EE certs with clientAuth when they have only dNSName SANs
(and either empty DNs or just CN=<FQDN>)?  Because this alternative is
much cheaper in terms of code that needs to change.

Nico
--