Discussion Period Begins: Ballot SC-103: Require EKUs for Cross-Certified Subordinate CAs

[Aaron Gable]

Ballot SC-103: Require EKUs for Cross-Certified Subordinate CAs

--- Ballot Background ---

The CCADB Policy v2.1 requires that the Extended Key Usage extension exist and have specific values in "cross-certificates [whose] Subject CA’s public key [...] might exist in a publicly-trusted self-signed Root CA certificate whose hierarchy should be considered dedicated to a specific PKI use case".

Simultaneously, several Root Program Policies require that all CA certificates be dedicated as such. For example, the Chrome Policy v1.8 requires that all Subordinate CA Certificates must include the EKU extension and assert only id-kp-serverAuth. Similarly, the Mozilla Policy v3.0 requires that all Subordinate CA Certificates assert either id-kp-serverAuth or both that and id-kp-clientAuth.

This ballot is an attempt to harmonize the Baseline Requirements with those existing root program requirements.

--- Ballot Summary ---

In the Cross-Certified Subordinate CA Certificate Profile, indicate that the Extended Key Usage extension is required in all circumstances. Remove the language distinguishing between "unrestricted" and "restricted" cases. In the table, direct readers to the subsection detailing restricted EKUs.

Remove the contents of the old "unrestricted" subsection, marking it as deprecated.

Rewrite the "restricted" subsection to clearly indicate exactly what combinations of EKU OIDs are acceptable. This is significantly stricter than the current version of the BRs, as the current language allows many combinations of EKU OIDs, as long as the certificate does not also assert id-kp-serverAuth. But it mirrors the restrictions in existing root program policy, and is much simpler to read and understand.

This ballot does not currently have an effective date, as generation of Cross-Certified Subordinate CA Certificates is a comparatively rare event, and this change is only intended to harmonize the BRs with existing root program policy. However, an effective date in the future could be added if others deem it necessary.

This ballot is endorsed by Chris Clements (Google / Chrome) and Ben Wilson (Mozilla).

--- Motion Begins ---

Modify the "Baseline Requirements for the Issuance and Management of Publicly-Trusted Server Certificates", based on Version 2.2.7, per the following redline:

https://github.com/cabforum/servercert/compare/1bcb34993331313c92ac7d6af778e81ca3d5faff...d390a2b10943ff60f3be565422ed199e87cc5f07

--- Motion Ends ---

This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:

Discussion (at least 7 days):

• Start time: 2026-06-12 17:00 UTC
• End time: 2026-06-19 17:00 UTC or later

Vote for approval (7 days):

• Start time: TBD
• End time: TBD

[Martijn Katerbarg]

Hi Aaron,

While I’m in support of the general direction of this ballot, I feel like there’s some nuance within the CCADB policy, that got lost in this ballot.

Quoting the CCADB Policy, emphasis mine: "when new cross-certificates are issued across PKI hierarchies and the Subject CA’s public key (a) exists in or (b) might exist in a publicly-trusted self-signed Root CA certificate whose hierarchy should be considered dedicated to a specific PKI use case, the following EKU values MUST exist”

Using the example of some Sectigo Root CAs, this would seem to mean that our “USERTrust RSA Certification Authority” would not be bound by this requirement, as this root CA is a legacy, multi-purpose root. On the other hand, our “Sectigo Public Server Authentication Root R46” is specifically a TLS-purposed root CA, and thus bound by this policy.

The proposed BR language however, seems to prevent this even for the multi-purpose root CAs we have. 

Now I’m not directly opposed to these constraints, but I would in that case suggest we add some further language to allow other EKUs as well, as long as the listed EKUs are not present. For example, the current ballot would prevent issuing a cross-signing between a Document Signing purposed Root CA and an existing multi-purpose Root CA. 

I’m not directly sure what other EKUs might be being used for public trust, perhaps the group has some additional thoughts.

Regards,

Martijn

From: 'Aaron Gable' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Date: Friday, 12 June 2026 at 19:00
To: server...@groups.cabforum.org <server...@groups.cabforum.org>; Chris Clements <ccle...@google.com>; Ben Wilson <bwi...@mozilla.com>
Subject: [Servercert-wg] Discussion Period Begins: Ballot SC-103: Require EKUs for Cross-Certified Subordinate CAs

This Message Is From an External Sender

This message came from outside your organization.

Report Suspicious

 

--
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/CAEmnErfhhy5rCaK1dT3eVqoft2nVLR0zQGJAsPcfjYbfw-NDcA%40mail.gmail.com.

[Ben Wilson]

Hi,

If the intent is to allow legacy multi-purpose roots to create different types of subordinate CAs, what about something like this?

"This requirement applies only when the Subject CA's public key exists in, or may exist in, a publicly trusted Root CA hierarchy that is dedicated to a specific PKI use case. A hierarchy shall be considered dedicated to a specific PKI use case when the publicly trusted certificates issued from that hierarchy are limited to that use case."

However, I see potential confusion with this when/if a hierarchy transitions from being multi-purpose to dedicated to a specific PKI use case. At what point, if any, should these restrictions begin to apply?  I think the various root programs have different ways of determining whether a hierarchy is dedicated to a particular use case.

Ben

[Aaron Gable]

Hi Martijn and Ben,

I attempted to address this in the ballot background section, but perhaps I didn't do a good enough job, or perhaps I'm now misunderstanding you.

Note that the CCADB requirement is conditioned not on the multi-purpose-ness of the issuing CA, but on the multi-purpose-ness of the new Subordinate CA. Several root programs already require that all new Subordinate CA Certificates (including Cross-Certified ones) be dedicated to a single use: Chrome requires that all new Sub CAs which chain up to roots they trust be serverAuth-only; Mozilla similarly requires that they be TLS server(-and-client)-auth-only; Microsoft requires single-purpose issuing CAs; and Apple's upcoming policy requires the same. So I think the world of creating new multi-purpose Subordinate CAs has passed.

In that light, having the BRs simply state that all Subordinate CAs must assert one of this limited set of options seems perfectly in line with existing root program policy.

Am I missing or misinterpreting something?

Thanks,

Aaron

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CA%2B1gtaZpSBatSGHDBMPYe2GHHDmi_dwkufG_ni%2B4CRDkDUWkhA%40mail.gmail.com.

[Martijn Katerbarg]

Hi Aaron,

I agree the world of creating new multi-purpose SubCAs has passed. However, I do believe the current language prevents a legacy multi-purpose Root CA from creating a new (single purpose) Document Signing cross-signed SubCA. 

Again, I’m not sure if any other EKUs might be of interest to anyone here. For us I’d at least request, if nothing else, to add the Document Signing EKU in the allow list.

Regards,

Martijn

From: Aaron Gable <aa...@letsencrypt.org>
Date: Tuesday, 16 June 2026 at 01:59
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Cc: Martijn Katerbarg <martijn....@sectigo.com>; Chris Clements <ccle...@google.com>
Subject: Re: [Servercert-wg] Discussion Period Begins: Ballot SC-103: Require EKUs for Cross-Certified Subordinate CAs

This Message Is From an Untrusted Sender

You have not previously corresponded with this sender.

Report Suspicious

 

[Aaron Gable]

Ah yes, that makes sense. I'm absolutely happy to add the Document Signing OID (1.3.6.1.5.5.7.3.36) to the list of acceptable EKU values (although the CCADB Policy does not allow it, so any CA included in a root program which requires compliance with the CCADB Policy will not be able to take advantage of it). I'll wait a few more days for any further discussion and then send a v2 of this ballot.

Aaron

[Christophe Bonjean]

Hi Aaron

 

While I can follow the deprecation of unrestricted CAs’ section, I wonder about the proposed updates for the restricted section.

 

The CCADB policy defines requirements from the root store point of view, with various use cases.

 

When we bring these use cases in scope of the TLS BRs (through the EKU table), I wonder if we are not expanding the scope of the TLS BRs too much.

 

Additionally, the conversation provides a few examples of edge cases related to single-use/multi-purpose/other EKU use cases (how will we make sure we cover all possible EKUs?).

 

I’m generally not sure whether the TLS BR is the appropriate document to mirror this requirement of the CCADB policy, and see a risk of unintended side effects given the complexity of cross-signing as seen by the examples. Any thoughts?

 

Kind regards,

 

Christophe

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CAEmnErdhhAhED4oGxX9LO8TZrkQEBYjTkZ8LrtxJ5u%3D4qYFHpg%40mail.gmail.com.

[Aaron Gable]

Hi Christophe,

While I understand that putting (for example) the Code Signing and S/MIME EKUs directly into the BRs feels like "bring[ing] those use cases in scope", I don't think that's what this ballot is really doing. When the BRs place restrictions on the profile of some particular certificate type, what they're actually doing is placing restrictions on the behavior of the issuer. In my opinion, this ballot isn't saying "cross-signed certificates must be single-purpose", it's saying "CA certificates subject to the TLS BRs must only issue single-purpose subordinate CAs". So it's not really bringing anything new in scope of the BRs, it's merely further constraining the behavior of CAs already in scope of the BRs.

I think this also addresses the concern about covering all possible EKUs: we simply don't need to. The requirements for "the Issuance and Management of Publicly-Trusted TLS Server Certificates" (emphasis mine) don't need to concern themselves with every possible EKU. In theory, the ideal version of this ballot would forbid all EKUs except for tlsServerAuth and tlsClientAuth. Of course, I don't believe that's workable today due to backwards compatibility with legacy hierarchies, but it may be a very realistic future change.

In fact, the SCWG meeting this morning raised the concern that adding the Document Signing EKU would actually be the wrong move: there's no clear bar for what EKUs get added, so simply matching the existing CCADB restrictions is the simplest and clearest, and makes it most likely that those restrictions will be removed from the CCADB policy in the future.

Aaron

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

[Christophe Bonjean]

Hi Aaron,

 

What clarifies things in the CCADB policy is the “If the subject hierarchy is dedicated to” condition, which to me also implies that “if the subject hierarchy is not dedicated to any of the following EKUs, then the table does not pose a restriction”. This allows other EKUs such as the DocumentSigning. – from a CCADB point of view only of course, other root program restrictions may apply.

 

Also note that the CCADB policy mentions “In support of ubiquity use cases, CA Owners sometimes issue cross-certificates from non-dedicated hierarchy Root CAs (i.e., “multi-purpose hierarchies”) to dedicated-use hierarchy Root CAs.” With the proposed changes in the TLS BRs, we’re focusing a lot on the Single-purpose Root case, not the multi-purpose hierarchy the CCADB policy describes.

 

From this point of view, I would expect the TLS BRs to define the permitted EKUs for crosses dedicated to TLS, and not restrict others?

 

Perhaps this achieves the objective of aligning with the CCADB requirement, while not completely copying it over.

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CAEmnErf2XBUG3pPt4mY5mZakohV4qizSznsT_GUC5V_ELiKyaw%40mail.gmail.com.

[Dimitris Zacharopoulos (HARICA)]

The more I read the CCADB policy language the more I believe this ballot has the requirement misunderstood. In my understanding, the CCADB policy tries to limit the scope of the NEW hierarchy when it is cross-signed by a legacy multi-purpose Root. Based on the first column "If the subject hierarchy is dedicated to…" of the table, there are specific rules for the issuer of the cross-certificate.

Examples:

1. If the new hierarchy is TLS server authentication only, the cross certificate issued from the legacy (ubiquitous) Root must include an EKU with `only id-kp-serverAuth`
2. If the new hierarchy is S/MIME (generic) email protection and client authentication, the cross certificate issued from the legacy (ubiquitous) Root must include an EKU with only `id-kp-clientAuth` and `id-kp-emailProtection`

If the new hierarchy is also multi-purpose, then all bets are off. It also does not forbid the creation of a new cross-certificate for a new hierarchy that is out of scope of the CCADB (e.g. document signing, VMC, IoT, QES, etc) that may include other EKUs than the ones listed.

Based on that interpretation, the best course of action would be to add language in the BRs in relation to the server TLS use case only. A high level description would be: "If the CA wants to cross sign a dedicated server TLS hierarchy with a legacy multi-purpose hierarchy, the cross-certificate must include an EKU extension with allowed values (`id-kp-serverAuth`) or (`id-kp-serverAuth` AND `id-kp-clientAuth`). No other combination is allowed". We could even extend this to "If the subject hierarchy does not intend to support server TLS, then the cross-certificate must include an EKU extension and the value `id-kp-serverAuth` MUST NOT be included".

That means if the CA wants to cross-sign something that IS NOT a "dedicated server TLS hierarchy", the BRs remain silent or at a minimum mandate that the `id-kp-serverAuth` EKU is not included in the cross-certificate. CCADB rules or other WG BRs might apply but the TLS BRs should not really mandate exactly what kind of EKUs should be included in a cross-certificate that is not intended for server TLS. It would make sense to mandate not to include the `id-kp-serverAuth` which is "controlled" by the SCWG.

Dimitris.

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