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

[Nico Williams <[e-mail]>]

On Wed, Apr 01, 2026 at 03:15:08PM +1100, Viktor Dukhovni wrote:
> On Wed, Apr 01, 2026 at 02:05:14AM +0000, Blumenthal, Uri - 0553 - MITLL wrote:
> > Also, when I authenticate my browser’s TLS connection to an
> > email server via PIV smartcard (seems to fit whatever you guys call
> > “webPKI”?) — what EKU do you expect to see in my certificate?
> 
> Well, to be a TLS client, the EKU (if present) needs to include
> "clientAuth".

Because the relevant specs say so.

> > (Hopefully, not SAN with domain name? I assure you my identity does
> > not include one! 😉)
> 
> Why are you suddenly conflating EKUs with subject (alternative) names?
> A TLS client's identity (subject name, or SAN) application dependent.
> With a client certificate issued by a KDC it could be a kerberos
> principal SAN, it could be a DNS name, it could be an IP address or
> email address, or as you note just a CN/DN.
> 
> EKUs are about the key usage, not about the subject name.

They can go together though.  E.g., the PKINIT SANs have corresponding
EKUs.  But yes, they don't have to go together.  My preference would be
to have more application-specific EKUs to augment clientAuth and
serverAuth.

> > I don’t understand where you get the idea that CN/DN would get “only a
> > domain name”.
> 
> That's all it can be when issued by a WebPKI CA that authenticates
> domain control.

Right.

> > Regardless, unlike IPsec/IKE that that is described as a peer-to-peer
> > protocol (Initiator and Responder — but not Client and Server), TLS
> > has been defined as a Client-Server protocol. Thus, both ends
> > presenting “TLSServerAuth” EKU appears weird.

It's worth reminding everyone that in IPsec/IKE the initiator/responder
roles are symmetric in that any pair of nodes can trade which node plays
which role at any time.  This is not the case for TLS.  Sure TLS servers
can also be clients of other systems, but generally there is no random
traffic-initiation-related trading of which node is the TLS client or
server, except in the cases of SMTP and XMPP, which are or can be in
fact symmetric in this sense.  But its not true of web servers and their
clients -- they do not trade client and server roles.

> There are plenty of systems that are clients in some TLS connections,
> and servers in others.  The WebPKI's previous issuance of dual EKUs
> "clientAuth + serverAuth" after "verifying" domain control and binding a
> DNS SAN in the certificate met the needs of those systems.  They'll now
> to either switch to new trust anchors, or to implement software
> workarounds (that'll take a long time to percolate through the
> ecosystem) that equate serverAuth with clientAuth.

Yes.

> In many cases the right solution is to issue your own certificates
> to your clients, without sloppily relying on a 3rd-party PKI, but 
> that's not always possible.

Right!!  But also, this is something that should have required
discussion with the public rather than the Chrome Root Program's dictat.

This Chrome Root Program policy change has damaged the market and the
Internet.

Nico
--