Client Authentication - Initial investigation

[Nick France]

All,

After the client auth discussions last week in-person and on-list, I’d like to start on some level of exploration into the use-cases of client authentication with ‘public’ certificates, which may help towards formation of a WG and ultimately a CA BRs, if the use-cases are deemed suitable.

(For clarity, when I say ‘public’ certificates, I’m talking about certificates with a validation path to an anchor included and distributed by one or more of the major trust-store programs).

What I’d like to gather is a list of examples of implementations which:

• Use the clientAuth EKU
• Require public trust (not just as a convenience)
• What parts of the DN of the client certificate are verified by the authenticating party, and how.

The last item is specific but important - we need that to determine what information is required in these certificates, and what we’d need to define as ‘validated' so that we can ensure that is reflected in any subsequent Baseline Requirements.

Just like browsers rely on validated subjectAltName entries, S/MIME clients on rfc822Names - we need to be sure what is relied upon (if anything) so that we can define validation processes.

Any implementations that cannot currently use separate certificates for client and server authentication should be detailed too, I think.

One I know is common with our customer base is Cisco Expressway - which does appear to have a planned fix to remove the requirement:

https://www.cisco.com/c/en/us/support/docs/field-notices/743/fn74362.html

Waiting for all your examples!

Thanks,

Nick

[Maria Merkel]

Hi Nick,

One use case that comes to mind from prior experience is EPP (domain name management) communication between domain name registrars and registries. Technically this use case does not require publicly trusted certificates, but they may be desirable to use the same certificate for multiple registries. Some registries (such as Verisign) require using a publicly trusted certificate. Verisign is removing the clientAuth EKU requirement next month but this is a workaround and not the ideal case. I am sure they would like to reinstate the requirement, but it is not feasible right now due to the new CABF requirements.

These registries typically validate the Common Name field against a whitelisted value (usually an FQDN, but it can be something else).

Maria Merkel

--
You received this message because you are subscribed to the Google Groups "Public (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to public+un...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/public/PH0PR17MB4923EBDCB8BCDD7BF21BDAA1DA41A%40PH0PR17MB4923.namprd17.prod.outlook.com.

[Sebastian Robin Nielsen]

My personal stance on this, is that public CA’s shouldn’t even put their hands in issuing ClientAuth-only certificates.

It should be limited to S/MIME certificates as today.

 

Here is why:

In a internal corporate environment, the security model is not ”who it is”. The security model is more ”It is the same person who I hired” – like a cookie.

Relying on a public CA for this, breaks that link.

 

Remember that theres multiple persons with the same name. For example, I have a S/MIME certificate I sign this mail with , which is issued to ”Sebastian Robin Nielsen in Sweden”

CN = Sebastian Robin Nielsen

G = Sebastian Robin

SN = Nielsen

C = SE

 

But if you see two ClientAuth certificates (with no email adress) for ”Sebastian Robin Nielsen in Sweden” – is it the SAME Sebastian Robin Nielsen in Sweden?

This is why trusting a public CA for internal ClientAuth is pretty dangerous, and should never be done by any company.

 

You could trust the email adress, because its a unique token – then you know its really ”that particular” Sebastian Robin Nielsen – because the other one has another email address – but then you can use a S/MIME certificate with ClientAuth as today. Every S/MIME certificate today includes ClientAuth.

 

So the CN, G, SN and C fields of a certificate is only useful to attach a real world identity – if you already have a unique token (like in this case, seba...@sebbe.eu ) that can be used to identify a unique instance of the person in question.

 

I can only see one use for a ClientAuth certificate issued by a Public CA, and that is logging into public websites, like banks and such.

But every country, and also EU, has already digital solutions that works for this, including apps and other infrastructure.

 

And same issue here – if you present a ClientAuth certificate containing a specific name – how do you know its the same person (and you should give him access to an already present account) or if its a new person (where you should create a new account for him)?

 

So im totally against this idea, and don’t see any practical use cases without also introducing huge security risks.

Let ClientAuth be handled internally by companies as today.

 

 

Best regards, Sebastian Nielsen

--

[Rob B]

Totally agree & well said.

R

---

From: 'Sebastian Robin Nielsen' via Public (CA/B Forum) <pub...@groups.cabforum.org>
Sent: Saturday, March 21, 2026 12:01
To: pub...@groups.cabforum.org <pub...@groups.cabforum.org>
Subject: Sv: [public] Client Authentication - Initial investigation

 

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/public/03af01dcb94b%24e96c31e0%24bc4495a0%24%40sebbe.eu.

[Ryan Hurst]

Nick, all,

I'm somewhat on the fence on this one, but I think the discussion so far is conflating two very different use cases that deserve separate treatment.

The human identity case is the relatively easy part

Sebastian makes a fair point about name collisions. I'm Ryan Hurst, the security practitioner, and there's also Ryan Hurst the actor (Remember the Titans, Sons of Anarchy). A public CA asserting "Ryan Hurst" in a DN doesn't help a relying party figure out which one of us is authenticating. S/MIME addresses this through the rfc822Name in the SAN, which is at least unique at the time of issuance, but unique isn't sufficient. The identifier also needs to be reachable. An email address is reachable, a social security number is not, and a DN of "Ryan Hurst, US" is neither unique nor reachable. The WebPKI's intent is to make things reachable in an authenticated way. DNS names and email addresses fit that model, DNs do not.

Even with email, there's a temporal problem. Addresses get reassigned, domains lapse, providers recycle accounts, and throwaway addresses exist by design. CAs can't monitor for reassignment, so these are inherently short-lived assertions. Broader questions around PII and auditability are really about how Key Transparency (https://datatracker.ietf.org/doc/draft-ietf-keytrans-protocol/) can be bolted into the ecosystem. I wrote about this here: https://unmitigatedrisk.com/?p=749

There is valuable work happening though. Ballot SMC015v2 enabling mDLs and EU digital identity wallets for S/MIME identity proofing, shows this evolving in a meaningful direction. Client authentication and signed email under S/MIME belong together. Apple has argued that emailProtection EKU should mean mandatory S/MIME BR compliance, closing the loophole where CAs omit email addresses to avoid the BRs. I think that's right.

One nuance. S/MIME bundles signing, authentication, and encryption, and I think that's right for the first two but not the third. Signing and authentication are real-time assertions that work well as short-lived credentials. Encryption is different. The key is bound to an identifier that may not be durable, and without frequent rotation, you risk bygone-SSL style (https://insecure.design/) attacks where a new holder of an email address could access messages intended for the previous one.

Browsers are actively looking to remove client auth from TLS certificates, and I don't disagree, given how poorly specified it has been. That signals whatever comes next needs to be much more tightly defined.

Bottom line. Human client auth is covered by S/MIME, browser-based client auth is on its way out for good reason, and a new WG doesn't need to revisit the human case.

Machine/service identity is the actual gap

Cross-organizational service-to-service authentication on the public internet is mostly handled today with API keys, OAuth client credentials, or IP allowlisting, all with well-known limitations. mTLS with publicly trusted client certs could fill a real gap, but only if the identity model is built correctly.

Many current uses are misplaced. A publicly trusted cert for payments.example.com tells you that the entity controlling that domain authenticated, nothing more. Public trust gives you an authenticated identity, not authorization. Organizations that conflate the two will accidentally open up access based solely on someone having obtained a client cert.

The examples collected so far, Cisco Expressway and EPP, are mostly legacy compatibility problems being fixed. The better foundation is authenticated service-to-service communication across organizational boundaries. For machines, name collisions largely disappear since DNS names are globally unique by design.

Nick, to your question about what parts of the DN the relying party verifies. There is no global X.500 directory, and even local directories matching DN structures don't exist in meaningful density. The better question is what SAN types are needed and what validation methods can we define for them.

Concrete SAN types for machine client auth

dNSName works today with no new validation methods needed:

• payments-api.example.com
• erp-connector.supplier.example.net
• registry-client.registrar.example.com (Maria's EPP use case, done properly)

uniformResourceIdentifier SANs encode not just the organization but the specific service:

• https://example.com/services/payments
• urn:example:service:billing:v2

This URI-based approach isn't speculative. SPIFFE already uses URI SANs in Kubernetes mTLS contexts, proven and widely deployed within private PKI. Extending it to public trust for cross-organizational federation is a natural evolution. URI SANs can be validated through .well-known challenge methods (like ACME HTTP-01 scoped to a URI path) and ALPN-based methods, extending battle-tested ACME-era infrastructure rather than building from X.500-era assumptions.

If this moves forward, scope matters

I'm not advocating for or against a WG, just sharing how I think about this. But if the Forum takes this on, the scope needs to be narrow IMHO:

• Machine/service client auth only, identity in the SAN using dNSName and uniformResourceIdentifier
• DN fields not relied upon for authentication decisions
• Validation methods building on existing domain control mechanisms
• Human client auth stays in S/MIME
• BRs should address the authentication vs authorization distinction explicitly
• Dedicated issuing CAs, separate from server auth hierarchies. Remember how SHA-1 migration was held back for years by payment terminals. Don't entangle these ecosystems.

TL/DR: If this becomes formalized I think the foundation should be authenticated cross-organizational service communication, not backward compatibility with systems that conflated client and server auth.

--