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.

--

[Nick France]

Thanks, Ryan - my question around ‘what part of the DN is verified’ was more because I’m not sure many or any implementations using clientAuth or mTLS are checking anything (at least in my experience).

Client authentication with (publicly-trusted) certificates seems to be little more than glorified bearer tokens most of the time. I’m not saying that’s necessarily bad, just that many implementations are key-possession checks only.

While that’s probably ‘just worked’ for a long time, I’m certain there are better solutions available nowadays.

Unlike a browser or TLS client checking control over an FQDN, or S/MIME client confirming control of an email address - client authentication checks seem to be simply checking if a certificate was issued and nothing more. Sometimes from a specific set of CAs or roots that are out of date or even distrusted.

The level of authentication here is not ‘demonstrate control over an FQDN and maintain that control’ it’s ‘has an internet connection, possibly’.

The one case that Maria mentioned had the caveat of ‘…does not require publicly trusted certificates’ and I suspect this is the case with many cases - though I’m still interested to see more use-cases brought forward.

(I was previously talking to some folks at Verisign and will re-start that discussion).

Nick

From: Ryan Hurst <ryan....@gmail.com>
Date: Saturday, 21 March 2026 at 18:58
To: pub...@groups.cabforum.org <pub...@groups.cabforum.org>
Subject: Re: [public] Client Authentication - Initial investigation

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

[Dimitris Zacharopoulos (HARICA)]

Dear Members,

As discussed at the recent F2F, clientAuth support from a publicly-trusted CA is a requirement by organizations that need support from a credible PKI with a decent assurance level, at least within Europe. I am fully aware that "credible" and "decent assurance" are subjective and can be measured differently but the bottom line is that there is a need for "recognized" PKIs in the sense that they are at least audited against internationally recognized standards (ETSI, WebTrust), and "supervised" by at least one major Certificate Consumer (today, we have at least Apple, Cisco and Microsoft, Members of the CABF, consuming such certificates). Any other "Private PKI" comes without a baseline or common rules regarding their core PKI policies/practices.

Taking a step back, this Forum has recognized that the first BR document produced and currently managed by the Server Certificate Working Group, was used as a basis for the BR documents produced by the Code Signing and S/MIME Working Groups. During the BR-of-BRs discussion, Paul van Brouwershaven was able to demonstrate that the 3 BR documents have a large part that is exactly the same and this could become even larger with small language modifications that do not change the actual requirements. And that is totally reasonable because the BRs are supposed to reflect Industry "good" practice (not necessarily "best"). Public CAs supporting multiple certificate types and use cases should have a core PKI that meets the minimum requirements of all "BRs", and build on top of that depending on the specifics of each certificate type, applying additional policies and restrictions based on the regulatory framework of each certificate type.

Some CAs prefer to use the stricter "baseline" as a basis for all certificate types because they know, by doing so, it will automatically meet the bare minimum of all types, and at the same time it reduces the overhead of maintaining multiple infrastructure settings which increases complexity.

ClientAuth is no different. The CABF could produce a BR document that meets those minimum good practices as identified by the industry and leave flexibility, as needed, to support the current clientAuth industry use cases. "Validation" is not the only thing associated with a PKI. Even if we could establish ground rules for a clientAuth-only PKI and leave validation completely "not stipulated" (I am not suggesting that of course), it would be better than what the industry currently has. The closest document with specific requirements for clientAuth in an Internationally-recognized standard I currently recall, is ETSI EN 319 411-1. I'm sure there are others but I'm referring to this ETSI document because it is known to this Forum.

I believe the Forum could produce a BR document for the clientAuth specific use case that would be beneficial for the trust-service industry by taking the already-established minimum good practices reflected in the existing BRs, and add validation requirements based on existing industry use cases. As we move forward, those validation requirements can become clearer and stricter as more experts put focus on the nuances of each use case, as demonstrated with other working groups.


Thanks,
Dimitris.

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

[Lahtiharju, Pekka]

Hi Nick,

 

I can provide some real-life examples. Telia has always been enrolling (non S/MIME) client certificates for multiple purposes to Telia Customers. Instead of forcing customers to create their own Private CA they can get client certificates from Telia where CA key is HSM protected and processes&infra are validated by auditors. In these Client use cases Telia just verify Subject O values using TLS OV rules. When utilizing those certificates Customers must to verify the O value (and public issuer) to know that the certificate is their valid client certificate. Or Telia can also verify dns-SAN values of client certificates using DCV validation rules in the same way than TLS DV is doing in pre-validated use case.

 

Typical use cases for such client certificates are identifying partners or internal users to get access to some own Intranet systems. In my opinion this is better than creating own loosely defined&protected private CA by the Customer. If BR would be generated for client certificates it would make more sense to these kinds of use cases and I think it would be good.

 

Br

Pekka Lahtiharju

Senior Development Manager | Certificate Services

Telia Company

 

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

This email may contain information which is privileged or protected against unauthorized disclosure or communication. If you are not the intended recipient, please notify the sender and delete this message and any attachments from your system without producing, distributing or retaining copies thereof or disclosing its contents to any other person.

Telia Company processes emails and other files that may contain personal data in accordance with Telia Company’s Privacy Policy.

[Adriano Santoni]

I agree with Dimitris. 

I'd like to add that in our experience, when customers need TLS client certificates, in most cases these certificates are issued to companies (rather than individuals) or, more often, to "applications/services" run by companies. For example, such a certificate might have a Subject like "O=Some Company, CN=Some Service" (possibly with country and other attributes as well). In these cases, it is therefore usually a matter of verifying that the applicant (Some Company) actually exists, that its official name is the one specified in the request, and that someone (not the janitor :) ) at Some Company actually requested that certificate. Therefore, it is an OV-style validation (aside from domain validation, which is irrelevant in this case) like the one required for TLS Server OV certificates or for S/MIME OV/SV certificates or for Code Signing certificates. At least we operate that way, but perhaps not all CAs do, and I think it would be good to have – if not requirements – at least shared guidelines on how this should be done. At that point, a "standard level" of assurance could be attributed to such a client certificate, and consequently some relying parties could decide that incoming connections from external systems must authenticate themselves (if with TLS client auth) with a client certificate that meets those guidelines.

Adriano

Il 25/03/2026 07:47, 'Dimitris Zacharopoulos (HARICA)' via Public (CA/B Forum) ha scritto:

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

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/public/ffa6ec7b-5412-4f12-8423-7f07fd8ee210%40harica.gr .

[Pedro FUENTES]

I mostly agree with these statements, but I’d have a doubt… Who would be the relying party or “consumer” that would participate in the definition of these “clientAuth BR”?

I’m under the impression that such “certificate consumers” aren’t clearly represented in the CABF, and in particular the Browsers aren’t (AFAIK!) checking anything in the client cert when processing mTLS to see if are “compliant”, as the suitability of a clientAuth cert is left as a decision of the application that is processing the authentication.

I’d appreciate if someone can clarify this doubt I have.

BR/P

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/public/10d53704-7d64-4f3e-8e4b-30f56a2cedda%40staff.aruba.it.

WISeKey SA

Pedro Fuentes
CSO - Trust Services Manager
Office: + 41 (0) 22 594 30 00
Mobile: + 41 (0) 791 274 790

Address: Avenue Louis-Casaï 58 | 1216 Cointrin | Switzerland

Stay connected with WISeKey

THIS IS A TRUSTED MAIL: This message is digitally signed with a WISeKey identity. If you get a mail from WISeKey please check the signature to avoid security risks

CONFIDENTIALITY: This email and any files transmitted with it can be confidential and it’s intended solely for the use of the individual or entity to which they are addressed. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. If you have received this email in error please notify the sender

DISCLAIMER: WISeKey does not warrant the accuracy or completeness of this message and does not accept any liability for any errors or omissions herein as this message has been transmitted over a public network. Internet communications cannot be guaranteed to be secure or error-free as information may be intercepted, corrupted, or contain viruses. Attachments to this e-mail are checked for viruses; however, we do not accept any liability for any damage sustained by viruses and therefore you are kindly requested to check for viruses upon receipt.

[Adriano Santoni]

That's a good question.

Adriano

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/public/4B129AFC-6821-43CC-A082-F537D6686B47%40wisekey.com.

[Dimitris Zacharopoulos (HARICA)]

On 3/25/2026 10:47 AM, 'Pedro FUENTES' via Public (CA/B Forum) wrote:

I mostly agree with these statements, but I’d have a doubt… Who would be the relying party or “consumer” that would participate in the definition of these “clientAuth BR”?

I am aware of at least one European Agency that uses clientAuth certificates to enable strong authentication to access web resources associated with critical infrastructure.

If others are aware of similar widely used use cases, now would be a good time to share :-)

I’m under the impression that such “certificate consumers” aren’t clearly represented in the CABF, and in particular the Browsers aren’t (AFAIK!) 

I'm not sure why you mentioned "Browsers" here. Just to clarify, the broader definition in the CABF is "Certificate Consumers". "Browsers" are the "Certificate Consumers" only in the Server Certificate WG.

As mentioned in previous emails, the CABF already has Apple, Cisco and Microsoft that in this context can act as "Certificate Consumers" for Client Authentication Certificates, just like they are "Certificate Consumers" for S/MIME Certificates, and Microsoft for Code Signing Certificates.

It will be challenging to scope the "Certificate Consumer" category in relation to popular and widely-used use cases (like the European Agency I mentioned earlier), but we could also create a WG without the "Certificate Consumer" category. The Bylaws allow that. This was also suggested at the recent F2F.

checking anything in the client cert when processing mTLS to see if are “compliant”, as the suitability of a clientAuth cert is left as a decision of the application that is processing the authentication.

Indeed. I've seen use cases that:

• just check that a certificate is signed by a particular Root CA (used as a Trust Anchor)
• just check that a certificate is signed by a particular Issuing CA (used as a Trust Anchor)
• Check that a certificate chains to a Root or Issuing CA (use as Trust Anchors) AND:
• nothing else; OR
• check the subject:commonName of the end-entity certificate; OR
• check the certificate serial number of the end-entity certificate; OR
• check the email address of the end-entity certificate; OR
• check the entire subjectDN of the end-entity certificate; OR
• various combinations of the above

I’d appreciate if someone can clarify this doubt I have.

Not sure if this helped, please reply if you had something else in mind.

Thanks,
Dimitris.

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/public/4B129AFC-6821-43CC-A082-F537D6686B47%40wisekey.com.

[Pedro FUENTES]

Hi Dimitry,

Thanks for your reply.

I think I'd still have my doubts as before, as I don’t see any relying party in the CABF that really acts as such for client certificates. I would say that the role of the consumers you mention is only to “technically support” clientAuth certificates, but they don’t take any decision about accepting or not the certificate, in contrast of what happens with serverAuth certs.

Also, all these checks you list below are performed by the application processing the authentication, but not the operating system that provides the TLS stack.

Again, I may be terribly wrong here.

Anyhow, note that I started my mail saying that I agree with yours and Adriano’s comments. My point is only about identifying the relying parties here.

Best

P

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/public/9037cca6-f813-4757-83af-dfdfaf4869f4%40harica.gr.

[Inigo Barreira]

> If others are aware of similar widely used use cases, now would be a good time to share

 

The French RGS (Référentiel Général de Sécurité) along with ANSSI still lists authentication certificates (clientAuth) to connect to secure portals or for strong authentication. So, there should be use cases for that.

 

De: 'Dimitris Zacharopoulos (HARICA)' via Public (CA/B Forum) <pub...@groups.cabforum.org>
Enviado el: miércoles, 25 de marzo de 2026 11:29
Para: 'Pedro FUENTES' via Public (CA/B Forum) <pub...@groups.cabforum.org>
Asunto: Re: [External Sender] [public] Client Authentication - Initial investigation

 

On 3/25/2026 10: 47 AM, 'Pedro FUENTES' via Public (CA/B Forum) wrote: I mostly agree with these statements, but I’d have a doubt… Who would be the relying party or “consumer” that would participate in the definition of these “clientAuth BR”?

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender This message came from outside your organization.

Report Suspicious    ‌

ZjQcmQRYFpfptBannerEnd

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/public/9037cca6-f813-4757-83af-dfdfaf4869f4%40harica.gr.

[Dimitris Zacharopoulos (HARICA)]

On 3/25/2026 12:52 PM, 'Pedro FUENTES' via Public (CA/B Forum) wrote:

Hi Dimitry,

Thanks for your reply.

I think I'd still have my doubts as before, as I don’t see any relying party in the CABF that really acts as such for client certificates. I would say that the role of the consumers you mention is only to “technically support” clientAuth certificates, but they don’t take any decision about accepting or not the certificate, in contrast of what happens with serverAuth certs.

I'm not sure I understand that part. If a certificate meets the requirements of the BRs, it doesn't mean it is automatically trusted by Certificate Consumers. They still need to add a Root CA into their corresponding Root Store for that to happen. That's a different process.

Also, all these checks you list below are performed by the application processing the authentication, but not the operating system that provides the TLS stack.

How would you consider -for example- "Thunderbird" processing S/MIME Certificates? It's an application, right? It "processes" the Certificates, checks that the certificate has the necessary properties, and then checks against the application Root Store to find a Root Certificate used as a Trust Anchor. Using ClientAuth is no different, except that in this case there may not be "an application" but "a use case". Example, an EU Agency may have multiple web sites for authorized individuals/companies to perform strong client authentication with client TLS certificates. I would consider that "one use case" consuming such certificates. That's my personal perspective of course :)


Thanks,
Dimitris.

--
HARICA Public Key Infrastructure
 
Dimitris Zacharopoulos
PKI Manager
t : +30 2310 998483
www.harica.gr

[Pedro FUENTES]

Hi Dimitry,

Let me try to explain me better...

My question is about the existence in the CABF of certificate consumers that actively participate in the decision to accept or not a client certificate while processing it.

This happens in Thunderbird (and other email clients) because they have a Root program and they apply compliance rules when processing (e.g.) a mail signature, also the client software will present to the user a digital signature as “valid” or not, so there’s a certain degree of “liability" derived of the acceptance or not of the certificate (because it’s the cert consumer who “renders" a trust decision to the user). Of course this also happens when a browser processes a clientAuth certificate.

But (AFAIK) this doesn’t happen when a certificate consumer (of the ones present in the CABF) processes a clientAuth cert during a mTLS negotiation, beyond (e.g.) presenting a list of non-expired certs that suit the CA list specified by the server (CertificateRequest message).

In serverAuth, the browsers and other consumers are relying parties, and therefore is normal that they participate in the development (and voting) of the BR. Same for S/MIME.

In clientAuth, even if some of the consumers present in the CABF “technically support” clientAuth certs, they aren’t acting as relying parties, as the acceptance decision on a certificate is done by the application that is receiving if (like those European agencies you mentioned, amongst others).

So my question is… thinking on developing (and voting) a clientAuth BR… Who will be the certificate consumers participating in the process?

I hope I explained myself properly now.

BR/P  

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/public/7d0dfb51-9460-4793-ab58-d7e65476d2ad%40harica.gr.

[Pedro FUENTES]

Sorry Dimitris, not Dimitry.

I just saw a typo… When I said below:

“Of course this also happens when a browser processes a clientAuth certificate.”

It was:

"Of course this also happens when a browser processes a serverAuth certificate."

BR/P

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/public/A4FFDC4E-A2E8-4634-89CD-2CE3C708D935%40wisekey.com.

[Mark Gamache]

The one use case I know of, that is not servable by private PKI, is client auth in SMTP. That is becoming a thing more commonly, though how the cert is validated. Beyond chaining to a trusted root, varies considerably.  Almost all other use cases could use private PKI, but that does create pitfalls, depending on who runs the PKI and whether they are trusting their own PKI, and of course have a good way of vetting names in their certs.

The reason I prompted this discussion is that I believe in the CABF and the way you have driven the industry. Looking at what is being done right now, what the gaps are, and how to narrow them, has gone very well and made us all safer. While Client auth is less used and far less understood, I assume a few public use cases will persist.  I always feel better trusting CABF scoped cert. I assume I am preaching to the crowd when saying that designing, building, and running PKI well is not small task. 

My thoughts are that you define what identity looks like in a cert, them make rules and timelines. As I mentioned on a different thread, I even feel OK about a dual auth cert with client and server EKUs, so that I can be sure that the requestor had to prove DCV for the DNS SANs. That is something, though being far more loose, than the server auth scenario.  

Thanks,

Mark Gamache

Interested Party  

---

From: 'Pedro FUENTES' via Public (CA/B Forum)
Sent: Wednesday, March 25, 2026 4:03 PM
To: pub...@groups.cabforum.org
Subject: Re: [External Sender] [public] Client Authentication - Initial investigation

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/public/977C925F-12B3-47E7-B790-0480DFB34115%40wisekey.com.

[Sebastian Robin Nielsen]

In this case, I would suggest that the trusting party, issues the certificate himself.

 

Since the certificates have different use cases, for example, one company might need a certificate to logon to the domain control panel, while another company might need a certificate to login to the tax declaration form.

 

Not the same persons in these cases should have access. In the case of domain panel, the IT department is the ones that should have access.

In the case with tax declaration, its the accounting department that should have access to that.

 

 

This is why this in eIDAS is usually solved by assigning a personal eIDAS certificate to the position in question. So the IT guy’s personal ID number is entered as ”authorized access” in the domain control panel, and the tax declaration is made by assigning ”access” to that company to a specific guy’s ID-number in tax declaration.

 

Here is two examples:

Domain control panel: https://www.loopia.se/loggain/bankid/151e3a2ee9357908a6aebbcb0b16fc802d74de81/

Tax declaration form – assign access to employees: https://www.skatteverket.se/foretag/drivaforetag/ombudforettforetag.4.5a85666214dbad743ff1156e.html

 

You basically login as owner of a company, and then you tell the system which employees are authorized to submit tax declaration.

 

And what if that janitor needs to login to the system where you order cleaning supplies and windex bottles?. Then you WANT the janitor to have access.

 

 

Thats why I feel a CA should not go into business of issuing clientAuth certificates.

 

That a S/MIME certificate has the clientAuth extension, doesn’t mean a login system will ”magically” trust it, it must be configured to trust that particular sub-CA, and usually, only the company that makes use of the certificate (ergo requested the certificate), will use it also for clientAuth to login to example email systems where said S/MIME certificate is used.

 

So the whole thing does already have a good solution within each country’s ecosystem for digital identities, and if two ”Organization” type of entities need to verify each other, its better that they issue a certificate from their own internal CA for access to each other’s systems.

 

 

Best regards, Sebastian Nielsen

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/public/10d53704-7d64-4f3e-8e4b-30f56a2cedda%40staff.aruba.it.

[Mike Shaver]

On Thu, Mar 26, 2026 at 4:22 AM 'Sebastian Robin Nielsen' via Public (CA/B Forum) <pub...@groups.cabforum.org> wrote:

In this case, I would suggest that the trusting party, issues the certificate himself.

 

Since the certificates have different use cases, for example, one company might need a certificate to logon to the domain control panel, while another company might need a certificate to login to the tax declaration form.

 

Not the same persons in these cases should have access. In the case of domain panel, the IT department is the ones that should have access.

In the case with tax declaration, its the accounting department that should have access to that.

I'm a bit confused, so apologies in advance if this question is overly basic: are we not talking about using client certificates for authentication, rather than authorization? I am not in favour of CAB/F taking on this charter, since browsers are not meaningful consumers (versus transporters) of clientAuth certificates and their users are not commonly parties who rely on authenticating the bearers of them, to be clear, but the examples of different authorization policies don't seem germane to a discussion about whether CAB/F should set some rules (that would bind some unclear groups!) about how clientAuth(entication) certificates are issued.

Mike

[Sebastian Robin Nielsen]

You are correct, but what Im trying to say, is that organizations is a different subject than individuals.

 

And im pretty sure clientAuth certificates with OV validations will not get any traction, unless a scheme with OIDs that identify different job positions (IT administrator, IT support, Janitor, Accountant, CEO, Facility Maintenace, Security Guard, Security Officer, Receptionist, etc) is encoded into the certificate.

 

The proposal here, is that a CA should be able to verify a Organization, and issue clientAuth certificates to ”identify as the organization” to a third party, lets say a webshop or a government entity.

 

But if you also need authorization, (that you also have the right job position) then such a scheme is completely useless unless the job position is encoded into the certificate. And then it must be encoded in such a way its ”programmatically” readable by the verifying system, so ”IT administrator” is the same thing as ”IT administrator” regardless if you work at Apple, Microsoft, Google or ”Johnny’s Websites”

 

So coding this in a free-text field is not good, because then someone might write ”Tech administrator”, another one would write ”Computer guy” and so on.

 

If you just want to authenticate, then you just issue the certificates yourself, in a internal CA. Like a ”cookie”.

Like, if you operate a webshop for cleaning supplies, then you validate that person X is janitor at company X, and then you issue a certificate from your internal ”webshop CA”, which you then give to the janitor after having exchanged CSR.

Since you still need to verify the job position and then it doesn’t become the ”seamless” experience of just logging into the webshop anyways.

 

 

And also about web browsers being consumers of client certificates, thats exactly what client certificates are for.

 

Its a excellent system where you can authenticate securely via an secure tunnel to the website in question. Its also extremely MITM secure since the tunnel is secured both ways, meaning a MITM cannot break the tunnel as even if he can present a fake certificate to the client (and hope he press ”continue anyways” on the HTTPS warning) you cannot present a fake certificate to the server and have it accepted.

 

But as I said, its only useful as a ”authentication cookie”, not for actually verifying the identity of someone.

 

 

Best regards, Sebastian Nielsen

 

 

Från: 'Mike Shaver' via Public (CA/B Forum) <pub...@groups.cabforum.org>
Skickat: den 26 mars 2026 14:33
Till: pub...@groups.cabforum.org
Ämne: Re: Re: [public] Client Authentication - Initial investigation [invalid signature!]
Prioritet: Hög

 

On Thu, Mar 26, 2026 at 4:22 AM 'Sebastian Robin Nielsen' via Public (CA/B Forum) <pub...@groups.cabforum.org> wrote:

--

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/CANx79dSXA3ZU88QuWXWcd%3D%2BkHDqv%3DgftTisoV86P2PYCQ_C4aQ%40mail.gmail.com.

[Wendy Brown (Protiviti)]

vLEI – Verifiable Legal Entity Identifiers may be more appropriate for conveying an individual's role in a given organization across organizational boundaries.  But I think that is different from the potential need for organizational server clientAuth certificates.

And I would suggest we should not conflate authorizations with authentication. For authentication you may just need to be sure that a given identity is bound to the certificate - the RP can then tie that identity (authentication) to an account which contains all the other attributes that provide t-what the individual is authorized to do for/with/on that application. The certificate does not necessarily have to contain all the attributes required for authorization.

---

From: 'Sebastian Robin Nielsen' via Public (CA/B Forum)
Sent: Thursday, March 26, 2026 11:52 AM
To: pub...@groups.cabforum.org
Subject: Sv: Re: [public] Client Authentication - Initial investigation [invalid signature!]

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/public/003701dcbd38%249cb02500%24d6106f00%24%40sebbe.eu.

NOTICE: Protiviti is a global consulting and internal audit firm composed of experts specializing in risk and advisory services. Protiviti is not licensed or registered as a public accounting firm and does not issue opinions on financial statements or offer attestation services. This electronic mail message is intended exclusively for the individual or entity to which it is addressed. This message, together with any attachment, may contain confidential and privileged information. Any views, opinions or conclusions expressed in this message are those of the individual sender and do not necessarily reflect the views of Protiviti Inc. or its affiliates. Any unauthorized review, use, printing, copying, retention, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email message to the sender and delete all copies of this message. Thank you.