Discussion Period Begins: Ballot SC-101: Clarify Authorization Domain Names

[Aaron Gable]

Ballot SC-101: Clarify Authorization Domain Names

Summary of the Ballot

In Section 3.2.2.4, explicitly describe the algorithm by which a CA may derive an Authorization Domain Name from an applied-for FQDN. The algorithm described is consistent with the most common interpretation of the current definition of ADN, so this is not expected to be a disruptive change for most CAs, but it removes ambiguity and closes one security issue (described below).

Simplify the definition of Authorization Domain Name to be merely descriptive. Update all validation methods to describe how they validate control of the selected ADN. Collapse all previous statements about validation method suitability for wildcard and ending-in-the-same-suffix validation into a table in Section 3.2.2.4. As a knock-on effect, simplify the definitions of Base Domain Name and Domain Contact.

Although these changes are simple, they are also sweeping. As such, the ballot includes a provision that CAs may comply with Section 3.2.2.4 of the previous version of the Baseline Requirements until November 15, 2026. This is derived from the approach taken by v2.0 of the Network Security Requirements.

Background of the Ballot

The existing definition of Authorization Domain Name has two severe issues:

a) It contains normative policy language (describing how to derive an ADN) but attempts to be a concise and descriptive definition, leading to ambiguity as to whether parts of the definition can be performed exclusively, in sequence, repeatedly, or otherwise.

b) Under some interpretations, it allows for issuance of certificates for names over which the applicant has not demonstrated any control.

Specifically, one interpretation of the current definition of an ADN is that a CA may prune labels from the left-hand side of the FQDN, then follow one or more CNAMEs, and then use the resulting FQDN as the ADN. However, just because `example.com` has a CNAME pointing to `example.org`, that does not give the operators of `example.org` any control over subdomains of such as `blog.example.com`. Under this interpretation, an entity capable of demonstrating control of a CNAME (such as a CDN operator) might be able to get issuance of certificates for arbitrary subdomains of names that are CNAMEd to them. This is not good.

This ballot resolves the issue by much more strictly describing the acceptable ADN derivation algorithm. In particular:

- The ADN must be selected after the validation method has been selected.

- Only certain methods (those which perform validation at the name itself, not at a underscore-prefixed subdomain of it) can use the "cname" step of the ADN algorithm.

- Only certain methods (those which currently allow issuance for "other FQDNs that end with all the Domain Labels of the validated FQDN") can use the "prune" step of the ADN algorithm.

- Following CNAMEs must happen before pruning labels, if both operations are performed.

This makes it much easier for CAs to implement provably-compliant ADN derivation algorithms, and closes the security hole described above.

This ballot also explicitly acknowledges something that has always been true: that all validation methods are in fact validating control over the ADN, not the applied-for FQDN (unless the CA has selected the ADN to be exactly equal to the applied-for FQDN). This means that validation data reuse also works at the ADN level: if two applied-for FQDNs can both be turned into the same ADN, then demonstrating control of that ADN is valid for the issuance of both applied-for FQDNs.

The following motion is proposed by Aaron Gable (Let's Encrypt / ISRG) and endorsed by Rich Smith (DigiCert) and Chris Clements (Google).

--- 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...709bb8f4460b1743a7df5f1bf0c728a496c57e4a

--- 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-04 01:30 UTC
• End time: 2026-06-11 01:30 UTC or later

Vote for approval (7 days):

• Start time: TBD
• End time: TBD

[Backman, Antti]

Hi, 

Thank your for this detailed ballot proposal. 

While studying the details of the process introduced in 3.2.2.4 to find the ADN. 

We got to wonder why (per the language) there’s no allowance for CNAME in step 4. when converting the wildcard to ‘A’. 

How we read the presented process described is that only if the ‘A’ is FQDN to begin with (Step 3.), CNAME would be allowed to follow. 

We’re seeking clarity to this to be able to fully understand the process described. 

The table below the process gives possibility to interpret that wildcard / CNAME follow-up combination would be allowed. 

Maybe we have just overthought this, but would appreciate confirmation how we should understand the process?

Thanks,  

//Antti

From: 'Aaron Gable' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Date: Thursday, 4. June 2026 at 3.35
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Cc: Rich Smith <rich....@digicert.com>; Chris Clements <ccle...@google.com>
Subject: [Servercert-wg] Discussion Period Begins: Ballot SC-101: Clarify Authorization Domain Names

Caution: This is an external email. Stop, assess and verify. Please take care when clicking links or opening attachments! When in doubt, report it using “report phishing” function.

--
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/CAEmnErcyw3czaq_XmSvZV_iz3%3DaAh6O%2BiwAcJHNgqL2_eFr9Ug%40mail.gmail.com.

[Aaron Gable]

Hi Antti,

Good question. The reason is the same as for non-wildcard domain names: allowing prune-then-cname opens up the security loophole described in the Ballot Background section. You can think of step 4.1 of the ADN algorithm (removing the leading "*." of the wildcard name) as a mandatory pruning step. Then, since pruning has happened first, no CNAMEs can be subsequently followed.

Note that this does not prevent following CNAMEs during validation itself. For example, if you are validating *.example.com using method 7, and the applicant has set up _underscore-prefix.example.com to be a CNAME, following that during validation is perfectly fine.

Aaron

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/MM0P280MB0630075976E9347B347C501386102%40MM0P280MB0630.SWEP280.PROD.OUTLOOK.COM.

[Backman, Antti]

Hi Aaron

Thanks for your swift response. Now it’s clear, thanks. 

//Antti

From: 'Aaron Gable' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>

Date: Thursday, 4. June 2026 at 17.25
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Subject: Re: [Servercert-wg] Discussion Period Begins: Ballot SC-101: Clarify Authorization Domain Names

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

[蔡家宏(chtsai)]

Hi,

 

We have two quick questions regarding method 3.2.2.4.7 and the ADN validation process:

 

Q1:

Under 3.2.2.4.7, if we have a CNAME chain: a.b.c.example.com ➔ d.e.f.example.com ➔ x.y.z.example.com

When identifying the ADN, must we follow the CNAME chain entirely to the final target (x.y.z.example.com)?

Can intermediate domains (e.g., d.e.f.example.com) or their pruned forms (e.g., f.example.com) also qualify as ADN candidates?

 

Q2:

Regarding the split between "identifying" and "validating" the ADN, during the "validation" phase, is CNAME resolution still permitted within the DNS lookup process, even when validating via the 3.2.2.4.22 method?

 

Thank you for your guidance.

 

 

Best Regards

 

蔡家宏 Chya-Hung Tsai

Director

Identification & Certificate Research
Tel: +886-2-2370-8886 ext. 722
Fax: +886-2-2388-6720
Email: cht...@twca.com.tw

10F., No. 85, Yanping South Road,

Taipei 100002, Taiwan(R.O.C.)
https://www.twca.com.tw

 

 

From: 'Aaron Gable' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>

Sent: Thursday, June 4, 2026 8:35 AM
To: server...@groups.cabforum.org
Cc: Rich Smith <rich....@digicert.com>; Chris Clements <ccle...@google.com>

--

[Aaron Gable]

Hi Chya-Hung Tsai,

Thanks for the questions! Responses inline below:

On Tue, Jun 9, 2026 at 2:27 AM '蔡家宏(chtsai)' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org> wrote:

Q1:

Under 3.2.2.4.7, if we have a CNAME chain: a.b.c.example.com ➔ d.e.f.example.com ➔ x.y.z.example.com

When identifying the ADN, must we follow the CNAME chain entirely to the final target (x.y.z.example.com)?

Can intermediate domains (e.g., d.e.f.example.com) or their pruned forms (e.g., f.example.com) also qualify as ADN candidates?

While deriving the ADN, you do not have to follow the CNAME chain to its final target. In this example, it is acceptable to use d.e.f.example.com as the ADN, or to use f.example.com if the validation method allows pruning during ADN construction (as 3.2.2.4.7 does).

The ballot explicitly allows for this. Step 3.1 of the ADN algorithm says "replace A with the result of a DNS CNAME lookup of A". Notably, when performing DNS CNAME queries, the DNS specification says that the answer returned should only be one hop down the chain. This is why step 3.1 explicitly says that it may be repeated, in order to allow the CA to follow the CNAME chain to its final target if the CA desires.

 

Q2:

Regarding the split between "identifying" and "validating" the ADN, during the "validation" phase, is CNAME resolution still permitted within the DNS lookup process, even when validating via the 3.2.2.4.22 method?

Yes, during the "validation" phase, following CNAMEs is allowed and expected. Specifically, if the validation method requires the CA to perform a TXT query (such as method 3.2.2.4.22), or an AAAA query (such as method 3.2.2.4.18), it is expected that the CA will abide by the DNS specification while performing those queries, and will therefore correctly follow any CNAMEs they encounter while doing so.

Aaron

[蔡家宏(chtsai)]

Hi Aaron,

 

Thank you for the clarification. We have no further questions on this matter.

 

Best regards,

ChyaHung

--

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/CAEmnErfmMr10WdX8yuMhgO5adJHuY4%2BxM9YPcs3Tj_EoKJBZvw%40mail.gmail.com.

[Backman, Antti]

Hi, 

One another thing to ask. 

If we’re not mistaking the effective date for the Ballot is set to September the 15^th but procedure in section 3.2.2.4 is to be adhered by the 15^th of November. Why is this, wouldn’t it be possible to set the effective date for the Ballot to the 15^th of November. 

Just wondering what good will it bring to the intention of this ballot to have other changes effective from the 15^th of September instead of setting effective date for the Ballot to the 15^th of November?

//Antti

From: 'Aaron Gable' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>

Date: Thursday, 4. June 2026 at 3.35

To: server...@groups.cabforum.org <server...@groups.cabforum.org>

Cc: Rich Smith <rich....@digicert.com>; Chris Clements <ccle...@google.com>

Subject: [Servercert-wg] Discussion Period Begins: Ballot SC-101: Clarify Authorization Domain Names

Caution: This is an external email. Stop, assess and verify. Please take care when clicking links or opening attachments! When in doubt, report it using “report phishing” function.

--
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/CAEmnErcyw3czaq_XmSvZV_iz3%3DaAh6O%2BiwAcJHNgqL2_eFr9Ug%40mail.gmail.com.

[Martijn Katerbarg]

Aaron, 

I wonder if a further clarification might be warranted on the bit in 3.1. The text reads "Optionally, if the validation method has a check in the CNAME column below, replace `A` with the result of a DNS CNAME lookup of `A`. This step may be repeated.”.

It might be worth clarifying which “Optionally” is applicable here. Is this:

“Optionally (if there is a CNAME record)”, or is this “Optionally (if there is a CNAME record and the CA chooses to)”. I believe the intent is the second one. 

Maybe rewording this to "Optionally, if the validation method has a check in the CNAME column below, the CA MAY replace `A` with the result of a DNS CNAME lookup of `A`. This step may be repeated.”, provides the required clarity within the text.

In Chya-Hung Tsai’s Q1 example, that would clarify that even using “a.b.c.example.com” or “example.com” (and anything in-between), is allowed as the ADN.

Regards,

Martijn

From: 'Aaron Gable' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Date: Wednesday, 10 June 2026 at 04:35
To: server...@groups.cabforum.org <server...@groups.cabforum.org>

Subject: Re: [Servercert-wg] Discussion Period Begins: Ballot SC-101: Clarify Authorization Domain Names

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/CAEmnErfmMr10WdX8yuMhgO5adJHuY4%2BxM9YPcs3Tj_EoKJBZvw%40mail.gmail.com.

[蔡家宏(chtsai)]

Hi,

 

One more question.

 

If we adopt the method in Section 3.2.2.4.7 (without an underscore), the rule stating "no CNAME allowed after pruning" still fails to prevent a delegated party from unauthorized certificate issuance, correct?

 

This is because, during the "Verify ADN" stage, they can still utilize a CNAME pointing to a domain under the delegated party's control. Does this mean that this specific rule (no CNAME after pruning) is primarily applicable to cases where the label "begins with an underscore character"?

 

Best regards,

CyhaHung

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/8e6361fe90ee46b480b2bf25650b2be6%40twca.com.tw.

[Aaron Gable]

Hi all,

A substantive concern with this ballot has been raised off-list, which I think merits the production of a SC-101v2 and a new discussion period.

The concern is that the changes to 3.2.2.5.3 (validation of an IP Address via Reverse Address Lookup) do not have an effective date in the future. I had considered the changes to 3.2.2.5.3 to merely be a clarification, not a change, and therefore not in need of an effective date. However, it has come to my attention that there are other interpretations of that section, for which this ballot would be a meaningful change. Therefore I will be adding a future effective date to Section 3.2.2.5.3, to match the ballot's existing future effective date for Section 3.2.2.4.

Replies to the three previous messages in this thread inline below:

On Tue, Jun 9, 2026 at 10:23 PM 'Backman, Antti' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org> wrote:

If we’re not mistaking the effective date for the Ballot is set to September the 15^th but procedure in section 3.2.2.4 is to be adhered by the 15^th of November. Why is this, wouldn’t it be possible to set the effective date for the Ballot to the 15^th of November. 

This is simply a typo -- I updated the effective date in Section 3.2.2.4 but forgot to update the effective date in the table at the top of the BRs. Normally this wouldn't require a new version of the ballot, because the Chairs can update that table while merging the ballot, but I will be creating a v2 of this ballot anyway (see above) so I'll get this fixed in that version as well.

 On Wed, Jun 10, 2026 at 12:24 AM 'Martijn Katerbarg' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org> wrote:

It might be worth clarifying which “Optionally” is applicable here. Is this:

“Optionally (if there is a CNAME record)”, or is this “Optionally (if there is a CNAME record and the CA chooses to)”. I believe the intent is the second one. 

This is a good point. I don't think this clarification would be enough to merit a v2 of this ballot on its own, but given that I will be producing a v2 anyway, I'm happy to incorporate a clarification here. I think I will go with removing "Optionally", and adding "the CA MAY" to both step 3.1 and all other optional steps for the sake of consistency.

 On Wed, Jun 10, 2026 at 12:35 AM '蔡家宏(chtsai)' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org> wrote:

If we adopt the method in Section 3.2.2.4.7 (without an underscore), the rule stating "no CNAME allowed after pruning" still fails to prevent a delegated party from unauthorized certificate issuance, correct?

 

This is because, during the "Verify ADN" stage, they can still utilize a CNAME pointing to a domain under the delegated party's control. Does this mean that this specific rule (no CNAME after pruning) is primarily applicable to cases where the label "begins with an underscore character"?

This is correct. However, it is simply how DNS works: when a CA queries for a AAAA, CAA, or TXT record at the ADN, they must follow any CNAMEs from there -- to do otherwise would be to undermine the intended functioning of the DNS itself.

The distinction to keep in mind is that pruning and following CNAMEs during ADN construction is using the structure of the DNS for an unintended purpose. It's a useful purpose, yes, allowing CAs and Applicants to negotiate centralized places to perform all validations. But we have to strictly regulate how it happens to ensure we don't violate any of the underlying assumptions of the DNS. In contrast, once you're doing validation itself, you're merely using the DNS as intended.

Aaron