Client authentication Working Group

[Mark Gamache]

Hi,

I started this conversation on the Server auth WG, as there is no client auth WG. There was great participation and folks seemed to get my point and brought up other good points. 

Given I was told this is the better place, I am starting a new email, as some of the points made on that thread are important and nuanced.

First off, my main thrust, not called out in the email, is that the CABF and their baselines are, to me, and even OWASP, a key reason that public PKI is trustworthy. That and and some great unilateral moves by Chrome. This however mainly covers server auth, SMIME, and Code Sign. 

Client auth has been neglected and with Chrome making a unilateral decision to only care about server certificates, it has brought to light risks around client authentication that may not be well known or understood. I was engaged with OWASP on this topic, before the Chrome mandate, and even then, it was messy and confusing. Most of the talk at that time was around how to use the certificates and never even looked at the path to get a public PKI CABF scoped certificate.  Adding this to the threat model makes it even more likely that the threat model is misunderstood.

As I mentioned in the other email, I can get client certs from many vendors, in names that one would assume I shouldn't be able to get and someone relying on this may not know that and assume some name validation was done. I was able to get CN = www.microsoft.com and CN = citi.com certs. Being client auth only, the also aren't CT logged. If this is going to be the case long term, I will advise OWASP to set best practices accordingly, but even then, not everyone reads those. 

Taking a step back, most CA vendors were issuing client auth EKU along with the server auth EKU. This conferred all the CABF Server Baseline requirements on to the certificate, even if used only for client auth. We all got some safety by being in a safe space. The certs were CT-Logged, DCV rules were followed for the DNS SANs. I am still not clear why Chrome cared enough to make the change and that may or may not be relevant to the threat model. With changes coming, I think it is important that the security community all be on a similar page in terms of the overall threat models here, including how certificates are issued and how the server validates a client certificate. Or at least which options there are, and the pros and cons.  I plan to take that part back up with OWASP, as I get a better understanding of the vetting/verification/proofing for client cert naming and issuance changes that could be forthcoming.  

There was some discussion on the thread about Apple and Microsoft choosing to trust client auth only Roots or roots that are used for more than one use case, which of course Chrome would not trust.  That is a bit orthogonal to the discussion, though the OS vendors probably have a vested interest in being sure how client auth certs are issued, if they are going to let their OSs trust them. I think we'd all be better served if the OS vendors had the same standard if they make rules around client auth issuance. 

FWIW, at this time, some vendors have CAs that still issue Dual auth certs, which aren't good for web servers (Due to Chrome), but still work for client auth. My company, for now, is choosing to standardize on them in order to show that server name DCV was passed. This is less assurance that in the server use case, as client DNS names don't have to match the certificate, but it does prove DCV was done for the name.  This may be theater in some use cases, as who know how the server is using the cert. In most cases, servers just trust any client cert for mTLS and maybe record the data. Some may pass the cert to the application layer and apply cert pining. As pinning is a pain and caries operation burden and availability risk, we will suggest to those validating our certs to check the chain is valid and that a specific DNS SAN is present. 

I have written far too much, sorry, but I am passionate about PKI and everyone being on the same page in a threat model like this.

My main point is, can we have a Client auth WG? Then, can we talk about issuance and naming requirements.

Thanks,

Mark Gamache 

[Sven A Rajala]

Plus one for my interest in this. 

Sven Rajala

Deputy PKI Officer

 

M: +1 540 687 0761

sven.rajala@keyfactor.com

---

From: Mark Gamache <ma...@markgamache.com>
Sent: Monday, March 9, 2026 12:52:32 PM
To: pub...@groups.cabforum.org <pub...@groups.cabforum.org>
Subject: [public] Client authentication Working Group

 

--
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/MW5PR16MB4846875A9C64EC81EB7E7EDCD179A%40MW5PR16MB4846.namprd16.prod.outlook.com.

[Maria Merkel]

I agree that it would be good to have a Working Group and Baseline Requirements for Client Authentication certificates.

I would participate in such a Working Group as an Interested Party if given the opportunity.

Maria Merkel

[Mike Shaver]

(not speaking for Fastly)

I think some industry rigour around client cert issuance practices could be valuable, but it’s not clear to me that the CABF is the right place for it. the entities managing the trust decisions are not browsers but (many, many) application developers and server operators. who would represent their interests, and what category would they be part of as members?

I put another way, I agree that (sadly) some unilateral moves by Chrome have been essential to maintaining and advancing the integrity of the web PKI. who would be the Chrome for the client auth ecosystem?

Mike Shaver (he/him) | VP Engineering | Toronto

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/public/adcac44d-ed9e-4031-a8ef-53f0bcbd3e2en%40groups.cabforum.org.

[Dustin Ward]

I would be interested in this as well.

Thanks,

Dustin Ward

Executive Vice President of Technology

SSL.com

---

From: Maria Merkel <ma...@maria.cc>
Sent: Monday, March 9, 2026 1:14:39 PM
To: Public (CA/B Forum) <pub...@groups.cabforum.org>
Cc: sven....@keyfactor.com <sven....@keyfactor.com>
Subject: [public] Re: Client authentication Working Group

 

You don't often get email from ma...@maria.cc. Learn why this is important

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/public/adcac44d-ed9e-4031-a8ef-53f0bcbd3e2en%40groups.cabforum.org.

[Maria Merkel]

Hi Mike,

My view is that Client Certificate consumers could join the CABF as Certificate Consumers if a Client Certificate Working Group existed.

According to the website the requirement is very broad ("Certificate Consumer: The member organization produces a software product, such as a browser, intended for use by the general public for relying upon certificates and is a member of one of the CWGs").

Maria Merkel

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/public/CANx79dTopxG7Sjcf2gO3m8YYsB5LUz5UWCv7q5mJYXtE1q7R2Q%40mail.gmail.com.

[Mike Shaver]

Hi Maria,

The requirements are somewhat broad, but do require that the software product can be downloaded from some specified URL and is intended for use by "the general public for browsing the Web securely". I would have a hard time imagining that applying to, for example, the developers of a service that authenticates users based on TLS client auth certificates.

Who do you see as joining as Consumers in the client auth case, as examples?

Mike

[Mike Shaver]

Apologies, I had too many tabs open -- that requirement is for the SCWG only.

I'm still interested in who would be able to join as a Consumer, and how large proponents of the client auth WG imagine that set becoming, though!

Mike

--

[Maria Merkel]

Hi Mike,

I can think of a few parties.

I used to be active in the domain registrar space. Most registries (like Verisign) would require you to use a publicly trusted client certificate. Others would issue one for you off their private PKI however.

It is true, though, that the number of consumers could become impossibly large. Perhaps this could be offset by a requirement to actively attend meetings, similar to the requirement in the Server Cert WG?

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/CANx79dQdHKP9%3D6yqZRFtyTSkoB_Tvh1g6T2S5JnzN15FvGRgvg%40mail.gmail.com.

[Mark Gamache]

FWIW, my employer Salesforce, is looking to join the CABF. We just have been super busy. If approved, we'd join this WG if it existed.

Also, all of my current statments are mine as interested party and may not fully reflect the views of Salesforce. I have to say that, for the lawyers. 

---

From: Sven A Rajala <Sven....@keyfactor.com>
Sent: Monday, March 9, 2026 11:12 AM
To: pub...@groups.cabforum.org <pub...@groups.cabforum.org>

Subject: [public] Re: Client authentication Working Group

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/public/CO6PR22MB249745C9C0F0E2661F1D255AFA79A%40CO6PR22MB2497.namprd22.prod.outlook.com.

[Corey Rasmussen]

OATI would be interested in participating in a client certificate working group as well.

 

Thanks,

 

Corey Rasmussen

Corey.R...@oati.net

Vice President & Chief Information Security Officer

Phone: 763.201.2000 

Fax: 763.201.5333

Open Access Technology International, Inc.

7901 Computer Ave, Bloomington, MN 55435

 

CONFIDENTIAL INFORMATION:  This email and any attachment(s) contain confidential and/or proprietary information of Open Access Technology International, Inc.  Do not copy or distribute without the prior written consent of OATI.  If you are not a named recipient to the message, please notify the sender immediately and do not retain the message in any form, printed or electronic.

 

From: 'Dustin Ward' via Public (CA/B Forum) [mailto:pub...@groups.cabforum.org]
Sent: Monday, March 9, 2026 1:20 PM
To: pub...@groups.cabforum.org
Subject: Re: [public] Re: Client authentication Working Group

 

{External email message: This email is from an external source. Please exercise caution prior to opening attachments, clicking on links, or providing any sensitive information.}

I would be interested in this as well.

 

Thanks,

 

Dustin Ward

Executive Vice President of Technology

SSL.com

 

---

From: Maria Merkel <ma...@maria.cc>
Sent: Monday, March 9, 2026 1:14:39 PM
To: Public (CA/B Forum) <pub...@groups.cabforum.org>
Cc: sven....@keyfactor.com <sven....@keyfactor.com>
Subject: [public] Re: Client authentication Working Group

 

You don't often get email from ma...@maria.cc. Learn why this is important

I agree that it would be good to have a Working Group and Baseline Requirements for Client Authentication certificates.

 

I would participate in such a Working Group as an Interested Party if given the opportunity.

 

Maria Merkel

sven....@keyfactor.com schrieb am Montag, 9. März 2026 um 19:12:28 UTC+1:

Plus one for my interest in this. 

 

Sven Rajala

Deputy PKI Officer

 

M: +1 540 687 0761

sven.rajala@keyfactor.com

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/public/LV8PR13MB675621CC48F18D1E356BFE4EBF79A%40LV8PR13MB6756.namprd13.prod.outlook.com.

[Nick France]

All,

 I'm trying to understand why we're encouraging this by looking to form a group for client authentication.
Client authentication with publicly-trusted certificates is bad. Let's not pretend otherwise.
Convenient, easy, and perhaps with a couple of decades of 'it just works’ behind it. I understand the impetus to keep it around, but shouldn't we as an industry be promoting and encouraging actually secure, anti-fragile solutions instead?

Since CRP's (correct) deprecation, the key thing I've been asking users/customers/subscribers is: what are you authenticating? (Or at least, what do you think​ you’re authenticating).
As Mark pointed out, and in my experience - the answer is nothing. The DN is almost checked, not that it practically could be.
Doing some kind of pinning or serial-number checking requires a user to login and upload their cert first, negating the point of using an externally-issued certificate. Even then, there's no guarantee of uniqueness across CAs. We know pinning is fragile and is something all good CAs openly discourage.

We should all understand the way certs work for TLS and that for each connection the client is actively verifying the connection address with the details in the certificate. Client authentication from publicly-trusted CAs does none of that, relying on 'well, it got verified when it was issued, so that should be good enough'.

Again, I agree with Mark that this is all security theatre and that we should do what we can to ensure everyone is on the same page, especially subscribers.

The absolute *best* case here is the authenticating party is able to confirm that the client...has an internet connection. That's it. That's the baseline. That isn't authentication at all.

I'd go so far as to say if you want to authenticating using certificates, you really have​to have issued them yourself. Millions of organisations do it today with device authentication to networks/wireless/VPNs - all from private CAs, because it'd be a huge risk to do otherwise.

Why are we considering trying to support what we know to be a highly insecure and inherently fragile solution? Is it purely out of convenience? Money?
I fully understand the difficulty of migrating subscribers to a better, safer solution and I think CRP's move of their deadline reflects this. It doesn't mean it's time to carry on something we know is bad.

We should do better as a group, even if that means recommending more appropriate solutions that may not involve PKI.

 

nick

From: 'Corey Rasmussen' via Public (CA/B Forum) <pub...@groups.cabforum.org>
Date: Monday, 9 March 2026 at 13:58
To: pub...@groups.cabforum.org <pub...@groups.cabforum.org>
Subject: RE: [public] Re: Client authentication Working Group

This Message Is From an External Sender

This message came from outside your organization.

Report Suspicious

 

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/public/5a25433c4f714b1eaa8a3f5c4cb521b9%40oati.net.

[Mark Gamache]

FWIW, there have been a ton of consumers getting client auth certs and using them for it, even it they were doing it badly, due to so many CAs adding the client EKU to server certs. 

The use cases aren't climbing, just awareness and complexity. 

---

From: Maria Merkel <ma...@maria.cc>
Sent: Monday, March 9, 2026 11:36 AM
To: pub...@groups.cabforum.org <pub...@groups.cabforum.org>
Cc: sven....@keyfactor.com <sven....@keyfactor.com>
Subject: Re: [public] Re: Client authentication Working Group

 

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/public/CAKtZuQ4fawPYe-2k5FavyiibFzWHz3f%2BVwmBi63bdnH6Qga4_w%40mail.gmail.com.

[Mark Gamache]

I am not sure calling it good or bad is the right mindset. Though, if forced to pick one. I do think it is more bad than good. If the Public PKI industry were even to say, no client auth EKUs on CABF scoped CAs, I could work with OWASP on this to create some guidelines.

That said, nearly all of the Public PKI problems exist in the same way for private PKI. It still suggests the need for fragile pinning or some sort of name checking at both issuance and at TLS handshake time. Shifting this risk outside of CABF scope and making that clear, would be fair, but I don't think it serves the larger issue well. I trust the CABF to be smart and do better, and have visibility that is lost with private PKI. I trust almost no one to do private PKI well. 

Further, I am a client auth hater. I always try to advise the use of almost any other option, so I am not looking to make it more common. I regularly point out that there are still a lot of risks around stolen keys (like stolen passwords), if they are not in an HSM.  There are often use cases, with legacy protocols like SMPP and SMTP, where the protocol has no chance of being changed, but for some reason extra security is helpful.  I'd also point out that the successful use cases mentioned tend to be enterprise use cases where one org owns both sides of the handshake and cert issuance, such as networks/wireless/VPNs.  My concern is B2B and maybe B2C, but I am not sure consumers are up to the task of using client certs, unless they happen to be on something like a smartcard or Yubikey. 

Cheers,

Mark Gamache

---

From: 'Nick France' via Public (CA/B Forum) <pub...@groups.cabforum.org>
Sent: Monday, March 9, 2026 1:09 PM
To: pub...@groups.cabforum.org <pub...@groups.cabforum.org>
Subject: Re: [public] Re: Client authentication Working Group

 

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/public/PH0PR17MB4923E2165059DB7B8CF3D7A3DA79A%40PH0PR17MB4923.namprd17.prod.outlook.com.

[Aaron Gable]

My thoughts generally align with Nick France's. Even if we handwave the huge number of potential Certificate Consumers in this space, we come back to the fundamental problem: how do you validate a TLS client's identity? An HTTP client is just an IP address. Sure, we can validate IP addresses and put those in tlsClientAuth certs, but I don't think that's what most mTLS servers want to be presented with.

There have been several recent documents in the IETF ACME Working Group presenting various kinds of mTLS client identifiers (e.g. device IDs, attestations, etc) and challenges to validate those identifiers. The thing that all of those challenges have in common is that they require the CA to trust a different Identity Provider. In the end, all the CA is doing is acting as a middle-man between the thing the server truly trusts (the IdP) and the client.

I'm of the opinion that this means it is outside the purview of the CABF. The Identity Provider should be issuing the client certificate directly, and the servers which want clients to present these certs should trust that IdP directly. Putting the public WebPKI in the middle of that relationship is inefficient, both socially and technically.

Aaron

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/public/MW5PR16MB4846D050209C67F3B9B96B6AD179A%40MW5PR16MB4846.namprd16.prod.outlook.com.

[Nick France]

Thanks, Mark - I very much appreciate the discussion (and in public this time)!

I do disagree on the good/bad designation. It’s a positive thing to be clear and direct. We’ve seen many things that are ‘bad’ still be used or implemented, and the consequences to us and many relying parties as a result. Pinning is a great example - I’ve seen first-hand with a recent acquisition the damage from certificate pinning, despite it being ’not recommended’. I don’t just mean broken apps, I mean real humans at risk. 

We need to be more clear when things are bad, because we’re this tiny industry of experts upon which large chunks of the world (often unwittingly) rely.

Publishing guidelines on what not to do - and alternatives - is more beneficial, I think.

I also don’t think the issues with public PKI are the same with private. The fundamental problem is that of who issues the certificate and who uses it for authentication. It has to be one and the same, as you pointed out. Then you can control who gets a certificate, what that certificate looks like and actually​ authenticate against the details within it.

Those are all possible with private PKI, but with any form of public or ecosystem PKI - you are beholden to third parties beyond your control.

B2B/B2C/ecosystems are different, yes - perhaps they shouldn’t use PKI, or they should have a private PKI to issue certificates to their clients just as they would their own infrastructure.

At least we agree on being client auth haters! (From publicly-trusted CAs, at least…)

To all:

Let’s say we do validate a new WG, then a new ‘BR for Client Auth’. Apple and Microsoft accept roots for that purpose into their program. Life moves forward. Millions use it to authenticate. Then Apple or Microsoft decide they want to make a change to their program - and we’re back where we are today, except we’ve convinced people it was a good idea and we’re faced with the same problems.

That seems bad.

nick

From: Mark Gamache <ma...@markgamache.com>
Date: Monday, 9 March 2026 at 17:23
To: pub...@groups.cabforum.org <pub...@groups.cabforum.org>
Subject: Re: [public] Re: Client authentication Working Group

This Message Is From an Untrusted Sender

You have not previously corresponded with this sender.

Report Suspicious

 

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/public/MW5PR16MB4846D050209C67F3B9B96B6AD179A%40MW5PR16MB4846.namprd16.prod.outlook.com.

[Mark Gamache]

Between Aaron G's and Nick F's reasoning, I can easily get on board.  That said, should the CABF then say , no client auth EKUs, like Chrome has, so we can start pointing the world in a better direction? And if so, on what timeline? What I am imagining is, if the EKU goes away completely, we all need time to plan and move to private PKI. Productizing this for many orgs is not a fast thing nor cheap. 

Or, we agree to leave things as is, and I will work with OWASP to point out that getting the client auth EKU from a public CA does not get one the assurance they may have assumed.  I am still partial to the middle ground of having the server auth EKU, so that DNS DCV is required for issuance. It still doesn't meant the same thing when used for client auth, but it means something that is meaningful

---

From: 'Nick France' via Public (CA/B Forum) <pub...@groups.cabforum.org>

Sent: Monday, March 9, 2026 4:11 PM

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/public/PH0PR17MB49237A6C72977532EC4C4228DA79A%40PH0PR17MB4923.namprd17.prod.outlook.com.

[Adriano Santoni]

ACTALIS would also be interested in participating in a Client Certificate Working Group, should one be created.

Il 09/03/2026 18:52, Mark Gamache ha scritto:

External sender. Verify for authenticity before opening any links or attachments.

[Ganesh Mallaya]

Hi All,

This has been a really useful discussion.

I tend to agree that the core challenge here is not the EKU itself, but the semantics that relying parties assume from a publicly trusted client certificate. In many deployments the certificate ends up being treated as an identity assertion, when in reality the issuance process may not provide the level of identity assurance the relying party believes it does.

At the same time, client authentication via TLS is widely used today in enterprise environments, particularly for mTLS between services, devices, and APIs. In many of those deployments the organization issuing the certificate and the organization validating it are the same entity, which aligns with the private PKI model that Aaron and Nick describe.

Given that direction, it may be reasonable for publicly trusted WebPKI to continue focusing primarily on server authentication. If that is the intended long-term direction, however, it would be helpful for the ecosystem to have clarity and transition guidance. Many organizations currently rely on public CAs for client certificates, and moving those deployments to private PKI or alternative identity systems will take time and planning.

In the meantime, clearer guidance to relying parties on what assurance a publicly issued client authentication certificate actually provides and what it does not could be valuable. A number of systems implicitly assume stronger identity guarantees than the issuance model necessarily supports.

Rather than a formal WG, we should consider whether the end result is a formal prohibition, a phase-out timeline, or simply clearer documentation, I think providing explicit direction would help reduce ambiguity for both implementers and relying parties.

Thanks again for raising the topic.

Regards,
Ganesh Mallaya

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/public/5d1df1fa-b66e-48db-a28a-a700492c39ca%40staff.aruba.it.