Slightly off topic

[Mark Gamache]

All,

Sorry that this question is not about Server certs, but there is no Client auth WG nor a list that I can find like a general WG.

What would it take to get a client auth WG with rules about names going into such certs? 

I recently verified from a few CABF scoped CAs and their vendors, that due to lack of rules on client auth cert naming, I can get certs in the names of nearly any org. When looking at the client auth threat model, I am not sure the industry is on the same page about this. I suspect some think there is some governance. I don't love mTLS/client auth, but it seems like it is here to stay. 

If we are going to do client auth, we should all be understanding the threat model. FWIW, I have been working with OWASP a bit on the topic and it is clear that as an industry, we all need to get aligned. 

Thanks,

Mark Gamache 

[Adriano Santoni]

IMO, this is an interesting topic, worthy of discussion (maybe not here), and far from trivial. 

Referring to the specific issue that Mark mentions, the ability to obtain a client auth cert for "nearly any org" is obviously tied to the vetting practices adopted (and not necessarily published, as there is no obligation to do so for these types of certificates) by the CA involved. And since there are no guidelines, let alone binding requirements, for generic client auth certs, it's clear that today any CA can legitimately do as they see fit, and therefore... "caveat emptor". Undoubtedly there is a related threat, but this is also the "fault" of the server that accepts such certificates.

In principle, I believe something like "baseline requirements" for TLS client auth certs are conceivable, although browsers aren't interested in this issue. But is it possible to find consensus and the resources needed to develop them? And besides, who and how could enforce compliance with such BRs, if they existed?

Adriano

Il 04/03/2026 20:24, Mark Gamache ha scritto:

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

--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org .
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/MW5PR16MB484698231365B76EACABB762D17CA%40MW5PR16MB4846.namprd16.prod.outlook.com .

[Dimitris Zacharopoulos (HARICA)]

[SCWG-Chair hat on]

I agree that this is an interesting topic but one that should probably be discussed at the Forum-level (pub...@cabforum.org). Any discussion to create a new Working Group should take place at the plenary level :-)

Best regards,
Dimitris.

--
Dimitris Zacharopoulos
CA/B Forum SCWG Chair

[Dimitris Zacharopoulos (HARICA)]

[Personal-HARICA-hat on]

On 3/5/2026 9:40 AM, 'Adriano Santoni' via Server Certificate WG (CA/B Forum) wrote:

IMO, this is an interesting topic, worthy of discussion (maybe not here), and far from trivial. 

Referring to the specific issue that Mark mentions, the ability to obtain a client auth cert for "nearly any org" is obviously tied to the vetting practices adopted (and not necessarily published, as there is no obligation to do so for these types of certificates) by the CA involved. And since there are no guidelines, let alone binding requirements, for generic client auth certs, it's clear that today any CA can legitimately do as they see fit, and therefore... "caveat emptor". Undoubtedly there is a related threat, but this is also the "fault" of the server that accepts such certificates.

There are obviously common validation policies between Server TLS, S/MIME and Code Signing Certificates reflected in the corresponding WG BRs and EV Guidelines. This goes back to the discussion of the "BR of BRs" where there was a suggestion for the Forum to adopt common identity validation practices (at OV and EV level) that could be used for all "CA/B Forum"-type of Certificates. TLS Client Authentication certificates could easily fall under such similar category.

In principle, I believe something like "baseline requirements" for TLS client auth certs are conceivable, although browsers aren't interested in this issue. But is it possible to find consensus and the resources needed to develop them? And besides, who and how could enforce compliance with such BRs, if they existed?

Today, Apple and Microsoft Root Stores support Client Authentication use cases in their Root Programs. Are there others?


Thanks,
Dimitris.

Adriano

Il 04/03/2026 20:24, Mark Gamache ha scritto:

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

All,

Sorry that this question is not about Server certs, but there is no Client auth WG nor a list that I can find like a general WG.

What would it take to get a client auth WG with rules about names going into such certs? 

I recently verified from a few CABF scoped CAs and their vendors, that due to lack of rules on client auth cert naming, I can get certs in the names of nearly any org. When looking at the client auth threat model, I am not sure the industry is on the same page about this. I suspect some think there is some governance. I don't love mTLS/client auth, but it seems like it is here to stay. 

If we are going to do client auth, we should all be understanding the threat model. FWIW, I have been working with OWASP a bit on the topic and it is clear that as an industry, we all need to get aligned. 

Thanks,

Mark Gamache 

--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org .
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/MW5PR16MB484698231365B76EACABB762D17CA%40MW5PR16MB4846.namprd16.prod.outlook.com .

--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/7b98ba05-bfd1-4431-bfc9-ec6bbdd896f1%40staff.aruba.it.

[Martijn Katerbarg]

>Today, Apple and Microsoft Root Stores support Client Authentication use cases in their Root Programs. 

While they do, they do so only as part of the S/MIME and the TLS certificate profiles. The way I understand it, the MRSP doesn’t allow clientAuth-only certificate issuance. 

Regards,

Martijn

From: 'Dimitris Zacharopoulos (HARICA)' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Date: Thursday, 5 March 2026 at 13:56
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Subject: Re: [External Sender] [Servercert-wg] Slightly off topic

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/servercert-wg/9fa1724b-67f9-4bc5-9619-9ebf4e1ce322%40harica.gr.

[Dimitris Zacharopoulos]

Hi Mark, no worries,

I indicated the list where this topic (formation of a new WG) can be discussed (pub...@cabforum.org).

Please read the CABF Bylaws that describe the process for creating a new Chartered Working Group.

Great initiative btw.


Thanks,

Dimitris.

Mar 4, 2026 21:24:21 Mark Gamache <ma...@markgamache.com>:

--

You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/MW5PR16MB484698231365B76EACABB762D17CA%40MW5PR16MB4846.namprd16.prod.outlook.com.

[Dimitris Zacharopoulos]

MRSP doesn't have a client authentication purpose in their Root Store.

Apple and Microsoft, do so. I don't believe that's part of SMIME. I assume a CA could request a client authentication only Root hierarchy to be included. I'm sure representatives of both Root Programs can correct me if I misinterpreted their Root Store Policies 🙂

DZ.

Mar 5, 2026 15:32:25 'Martijn Katerbarg' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>:

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/SA1PR17MB650374F9CE4070C905D97174E37DA%40SA1PR17MB6503.namprd17.prod.outlook.com.

[Martijn Katerbarg]

>Microsoft, do so. 

They do, but there’s no valid Policy OID you could include in leaf certs IIUC, as that pulls them into the TBR or SBRs. 

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/9796f93d-db82-4ee0-b44e-ae0214633d7f%40harica.gr.

[Corey Bonnell]

Hi Martijn,

What section of MRSP states this restriction?

 

Thanks,

Corey

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/SA1PR17MB6503483D895E9E386BDCE223E37DA%40SA1PR17MB6503.namprd17.prod.outlook.com.

[Dimitris Zacharopoulos]

These can be defined in the CA's CP/CPS.

That's what is actually being audited (CP/CPS) since there are no BRs just for clientAuth.

DZ.

Mar 5, 2026 16:29:34 'Martijn Katerbarg' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>:

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/SA1PR17MB6503483D895E9E386BDCE223E37DA%40SA1PR17MB6503.namprd17.prod.outlook.com.

[Martijn Katerbarg]

https://github.com/TrustedRootProgram/Program-Requirements/blob/main/Requirements.md#3-program-technical-requirements

3.1.15

Regards,

Martijn

From: 'Corey Bonnell' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Date: Thursday, 5 March 2026 at 15:59
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Subject: RE: [External Sender] [Servercert-wg] Slightly off topic

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/DS0PR14MB6216149377A213B4C62F59B4927DA%40DS0PR14MB6216.namprd14.prod.outlook.com.

[Corey Bonnell]

I agree that a strict interpretation of that section would require one of the listed CABF OIDs in client authentication certificates. But that same strict interpretation would also prohibit the issuance of timestamping authority certificates, because the CSBR timestamping OID is not listed in the table.

 

Given this, the strict interpretation is not the most reasonable interpretation of this section.

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/SA1PR17MB6503A5E7856B197141831CFFE37DA%40SA1PR17MB6503.namprd17.prod.outlook.com.

[Dustin Hollenback]

Hi all,

As requested to clarify the Apple Root Program Policy, the current policy (version 1.0) does permit Client Authentication-only hierarchies.

The upcoming version 2.0 draft policy, currently being reviewed by Root CA Owners in the Apple Root Program, further elaborates on this. For the 'Client Authentication' Trust Purpose, the Baseline Requirements are noted as 'CA-defined (subject to Apple approval)'. This acknowledges the lack of a specific CA/B Forum BR or other requirements document for clientAuth-only certificates and places the onus on the CA to define these requirements.

Given that CAs define these requirements, here's an example of a commitment text a CA might propose to include in their CP/CPS, adapting the TLS BRs for client authentication while explicitly excluding `id-kp-serverAuth`:

----

"This CA conforms to the CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (“TLS BRs”), except for the requirement in BR §7.1.2.3(f) that subscriber certificates include id‑kp‑serverAuth in the ExtendedKeyUsage extension.

Within the hierarchies covered by this document, all CAs that issue subscriber certificates are technically constrained to issue only client‑authentication subscriber certificates. Accordingly, BR §7.1.2.3(f) does not apply to subscriber certificates issued under these hierarchies. Such certificates include id‑kp‑clientAuth and do not assert id‑kp‑serverAuth.

All other applicable provisions of BR §7.1.2.3 and all other applicable sections of the TLS BRs, including identity validation for DNS names and IP addresses, certificate content and SAN requirements, algorithm and key size requirements, KeyUsage requirements, CA certificate profiles, audit requirements, key management, revocation, and CP/CPS publication obligations, are fully met by this CA."

----

I'd appreciate the group's thoughts on this example. Are there any immediate concerns or potential problems with this kind of approach for public clientAuth-only certificates, especially considering the points raised earlier in this thread about policy OIDs?

Thanks,

Dustin

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/DS0PR14MB621653E3DC019A832EF8D862927DA%40DS0PR14MB6216.namprd14.prod.outlook.com.

[Mark Gamache]

I tried to send a message to pub...@cabforum.org per this thread, and with some updated thoughts/concerns , but it was rejected.  Not sure if the box is locked, full or what.  =( 

---

From: 'Dustin Hollenback' via Server Certificate WG (CA/B Forum)
Sent: Thursday, March 5, 2026 1:43 PM

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CA6D160C-9DFB-4DF2-A3E7-68DB818F73DC%40apple.com.

[Ben Wilson]

All,

From a Mozilla Root Store Policy perspective, I am not aware of an explicit prohibition on issuing certificates that contain only the id-kp-clientAuth EKU under a root that is trusted in NSS. The MRSP does not appear to include language that expressly forbids client-auth-only issuance.

At the same time, Mozilla’s stated position is that we curate our root store solely for the purposes of TLS server authentication and S/MIME. See Kathleen Wilson’s 2021 blog post for additional context:
https://blog.mozilla.org/security/2021/05/10/beware-of-applications-misusing-root-stores/

However, as with other aspects of our program, Mozilla’s policies and positions may evolve over time based on ecosystem developments and other considerations.

If others believe there is specific policy text that would suggest otherwise, please feel free to point it out, and I will stand corrected.

Thanks,

Ben

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CA6D160C-9DFB-4DF2-A3E7-68DB818F73DC%40apple.com.

[Ben Wilson]

Mark,

Do you want me to add you as an unmoderated subscriber? You don't appear to be subscribed.

Ben

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/MW5PR16MB484623C391A541C0E5DE6692D17AA%40MW5PR16MB4846.namprd16.prod.outlook.com.

[Dimitris Zacharopoulos]

I now see the confusion...

MRSP usually stands for Mozilla Root Store Policy because Microsoft calls it Trusted Root Program 🙂

DZ.

Mar 5, 2026 18:31:46 'Martijn Katerbarg' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>:

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/SA1PR17MB6503A5E7856B197141831CFFE37DA%40SA1PR17MB6503.namprd17.prod.outlook.com.

[Wayne Thayer]

Hi Mark,

Please try sending your message again - I just gave you permission to post to pub...@cabforum.org.

Thanks,

Wayne

On Thu, Mar 5, 2026 at 5:31 PM Mark Gamache <ma...@markgamache.com> wrote:

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/MW5PR16MB484623C391A541C0E5DE6692D17AA%40MW5PR16MB4846.namprd16.prod.outlook.com.