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

[Viktor Dukhovni <[e-mail]>]

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

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

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

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

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.

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.

-- 
    Viktor.  🇺🇦 Слава Україні!