SC-XXX: Clarify Authorization Domain Name (alternative to #619) #627
Conversation
Simplify the definition of ADN and move the algorithm in 3.2.2.4. Define Base Domain Name as a function of any given FQDN. Move the definition of Domain Contact into the only remaining method that uses it. Simplify the language in each method around pruning labels and wildcard issuance. Add corresponding language about following CNAMEs when choosing the ADN, and around onion issuance. Use "ADN" consistently in method definitions instead of "FQDN" (which is insufficiently precise as to whether it's the applied-for FQDN or the ADN). Clean up the language in the onion section around ADNs. Replace retired methods with language saying they are retired.
aarongable
changed the title
|
I pushed a change breaking out the ADN algorithm into two parts: one where the input is an FQDN and one where the input is a Wildcard Domain Name. The goal of this update is to forbid CNAME lookups when choosing the ADN, if the input was a Wildcard Domain Name. The intuition is that CNAMEs delegate control of a single FQDN and do not imply anything about control of subdomains. When validating |
Also, reuse more of existing pruning language.
|
Updated once more to reflect CNAME-or-prune semantics. I described my thinking in cabforum/definitions#5 (comment). This allowed simplifying things somewhat. I also reverted some of the new description of pruning to use more of the old language, which was fine. |
|
Maybe it's just me and my reading comprehension skills, but I do have a couple comments after reading the proposed verbiage here. If this is way off base, feel free to ignore! First, it seems like the intersection of allowances with the algorithm for choosing an ADN is complex and leaves room for ambiguity. For example, perhaps under 4 it would be worth explicitly stating that following CNAMEs is not allowed for selecting ADNs on Wildcard Domains regardless of if the method allows it or not. Second, further down in the text, there are references to ADNs that aren't clear whether they should be referring to an ADN that was selected from following a CNAME or not. An example of what I mean follows. Under 3.2.2.4.7, we see this heading: Under the ADN selection algorithm provided, however, this ADN could be my domain, a base domain of my domain, or a CNAME that one of those domains pointed to. Is this meant to allow the following condition? Similarly, under 3.2.2.4.4 the ADN is referenced multiple times as the target of the constructed email domains, suggesting in the above example that the emails would/should be send to the target of the CNAME domain (but in this case I assume no pruning would be allowed, therefore the emails would necessarily be to addresses like Again, if I'm just way off base here and these elements seem clear and unambiguous to others, then I can be safely ignored. I simply wanted to point out some items that I had questioned as I was reading through the proposed change. |
Good point. I'll have a think about the clearest way to express this. Ideally the validation methods would say something like "this has property
My goal in writing this is that, once the ADN is selected, the validation method shouldn't have any dependency on how it was selected (i.e. whether a CNAME was followed).
This example uses prune-then-CNAME, which IMO should not be allowed because it doesn't follow the actual semantics of control in DNS. The operator of Perhaps you meant to ask about a situation like this? In this example, the CA would be selecting The idea being that it's better for CNAME following to happen automatically as part of the normal DNS operations that occur during validation. So in this example, there could be
This is why CNAME-then-prune is convenient for subscribers. In my example above, if the validation method is "3.2.2.4.4 Constructed Email to Domain Contact," the CA would be allowed to first follow the single CNAME, resulting in |
Allow CNAME following for DNS Change
|
@cardonator thanks again for the feedback. To clear up the question of CNAME following during validation of a wildcard certificate, I moved the prose allowances ("This method allows CNAME lookups when choosing the ADN") into a table right next to the ADN algorithm. I also gave "3.2.2.4.7 DNS Change" a checkmark in the CNAME column - after thinking about the underscore-prefixed variant, I concluded that disallowing CNAMEs for this method would rule out some validations that were previously allowed and that were semantically valid in terms of how DNS assigns control. |
docs/BR.md
Outdated
|
|
||
| ##### 3.2.2.4.22 DNS TXT Record with Persistent Value | ||
|
|
||
| Confirming the Applicant's control over a FQDN by verifying the presence of a Persistent DCV TXT Record identifying the Applicant. The record MUST be placed at the "`_validation-persist`" label prepended to the Authorization Domain Name being validated (i.e., "`_validation-persist.[Authorization Domain Name]`"). For this method, the CA MUST NOT use the FQDN returned from a DNS CNAME lookup as the FQDN for the purposes of domain validation. This prohibition overrides the Authorization Domain Name definition. CNAME records MAY be followed when resolving the Persistent DCV TXT Record. |
There was a problem hiding this comment.
| Confirming the Applicant's control over a FQDN by verifying the presence of a Persistent DCV TXT Record identifying the Applicant. The record MUST be placed at the "`_validation-persist`" label prepended to the Authorization Domain Name being validated (i.e., "`_validation-persist.[Authorization Domain Name]`"). For this method, the CA MUST NOT use the FQDN returned from a DNS CNAME lookup as the FQDN for the purposes of domain validation. This prohibition overrides the Authorization Domain Name definition. CNAME records MAY be followed when resolving the Persistent DCV TXT Record. | |
| Confirming the Applicant's control over the ADN by verifying the presence of a Persistent DCV TXT Record identifying the Applicant. The record MUST be placed at the "`_validation-persist`" label prepended to the ADN being validated (i.e., "`_validation-persist.[Authorization Domain Name]`"). CNAME records MAY be followed when resolving the Persistent DCV TXT Record. |
These suggested changes should bring method 22 in line with the updated ADN definition in this draft ballot. Essentially this is removing the references to the previous definition of ADN around following CNAMEs as part of ADN determination. That practice is now prohibited for this method per section 3.2.2.4 so the language here no longer makes sense. I decided to leave the clause around CNAME following during DNS resolution mainly to minimize changes but would be open to removing it as well.
docs/BR.md
Outdated
| 1. Initialize `A` to the applied-for FQDN or Wildcard Domain Name. | ||
| 2. Choose a validation method. If `A` is a Wildcard Domain Name, the CA MUST choose a validation method with a check in the Wildcard column below. If `A` is an Onion Domain Name, the CA MUST choose a validation method with a check in the Onion column below. | ||
| 3. If `A` is an FQDN: | ||
| 1. 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`. |
There was a problem hiding this comment.
From discussion in the 2026-01-08 call:
The Validation WG believes that we should rephrase this such that it explicitly allows following multiple CNAME delegations in a chain.
On the one hand, allowing CNAME chaining at this top level is very unusual: it requires the CA to implement a whole layer on top of DNS, since no DNS resolver (stub or recursive) will do this CNAME chaining for you. And it seems like it should be unnecessary, since the methods which allow following CNAMEs during ADN derivation (e.g. dns change, email to caa or txt contact) then also follow CNAMEs during actual validation.
On the other hand, disallowing CNAME chaining at this level may be a surprising change from the status quo, as some ecosystem participants believe that the current ADN definition is recursive and therefore allows CNAME chaining. More importantly, it disallows one specific scenario:
- A CDN wants to get a cert for
example.org, which is CNAMEd toexample.com, which is CNAMEd toexample.com.content.cdn.com. - They want to use a single central solver for ACME DNS-01 challenges, so they CNAME
_acme-challenge.example.com.content.cdn.comtoacme.cdn.com
If CNAME chaining in ADN construction were disallowed in this scenario, the CDN would either need their customer to CNAME example.org to the CDN directly (so that there's not a chain of CNAMEs prior to reaching the CDN), or they would need their customer to place a CNAME record on _acme-challenge.example.com. Both solutions place higher overhead on the customer/cdn relationship, and neither enforces desirable properties.
richardwsmith
left a comment
richardwsmith
left a comment
There was a problem hiding this comment.
Added some suggestions for adding a compliance date, and clarifying "...other FQDNs that end with all the Domain Labels of the validated FQDN."
| | 2026-03-15 | 4.2.1 | Subject Identity Information validation maximum data reuse period is 398 days. | | ||
| | 2026-03-15 | 4.2.1 | Domain Name and IP Address validation maximum data reuse period is 200 days. | | ||
| | 2026-03-15 | 6.3.2 | Maximum validity period of Subscriber Certificates is 200 days. | | ||
| | 2026-03-15 | 7.1.2.4 | CAs MUST NOT use Precertificate Signing CAs to issue Precertificates. CAs MUST NOT issue certificates using the Technically Constrained Precertificate Signing CA Certificate Profile specified in Section 7.1.2.4. | |
There was a problem hiding this comment.
Please add a compliance date for this ballot. Assuming this gets into discussion and voting soon-ish 2026-06-15 should be adequate to allow full code review and any required fixes.
|
|
||
| The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values. | ||
|
|
||
| **Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. |
There was a problem hiding this comment.
Removal of this note and these "Note" statements in other places throughout this section potentially makes very large changes to the section, particularly with respect to, "...other FQDNs that end with all the Domain Labels of the validated FQDN," as the additional text added above in 3.2.2.4 has only explicitly addressed the Wildcard case. Additionally these "Note" sections have been inconsistently treated as many, but not all of them have been deleted.
| 2. If the validation method has a check in the Prune column below, prune zero or more Domain Labels of `A` from left to right until `A` is equal to the Base Domain Name of `A`, or the CA chooses to stop pruning, whichever comes first. | ||
| 5. Use `A` as the ADN. | ||
|
|
||
| | Method | Wildcard | Prune | CNAME | Onion | |
There was a problem hiding this comment.
Text and table specifically states what to do with Wildcards and where they are or are not allowed, however "...other FQDNs that end with all the Domain Labels of the validated FQDN," have not been specifically addressed. I suggest that either 'other FQDNs' be explicitly lumped in with Wildcard in the table, or other specific text and an additional column in the table added to specify when they are allowed. See additional note on this subject below.
docs/BR.md
Outdated
| Confirming the Applicant's control over a FQDN by verifying the presence of a Persistent DCV TXT Record identifying the Applicant. The record MUST be placed at the "`_validation-persist`" label prepended to the Authorization Domain Name being validated (i.e., "`_validation-persist.[Authorization Domain Name]`"). For this method, the CA MUST NOT use the FQDN returned from a DNS CNAME lookup as the FQDN for the purposes of domain validation. This prohibition overrides the Authorization Domain Name definition. CNAME records MAY be followed when resolving the Persistent DCV TXT Record. | ||
|
|
||
| The CA MUST confirm the Persistent DCV TXT Record’s RDATA value fulfills the following requirements: | ||
| Confirming the Applicant's control over the ADN by verifying the presence of a Persistent DCV TXT Record identifying the Applicant. The record MUST be placed at the "`_validation-persist`" label prepended to the Authorization Domain Name being validated (i.e., "`_validation-persist.[Authorization Domain Name]`"). This prohibition overrides the Authorization Domain Name definition. |
There was a problem hiding this comment.
The sentence "This prohibition..." doesn't flow right now that the preceding MUST NOT has been removed.
6 participants
Simplify the definition of ADN and move the algorithm in 3.2.2.4. Choosing an ADN is a precursor to doing validation. Every validation operates on an ADN.
Simplify the language in each method around pruning labels and wildcard issuance. Add corresponding language about following CNAMEs when choosing the ADN, and around onion issuance.
Require record keeping when choosing the ADN.
Replace retired methods with language saying they are retired.
Define Base Domain Name as a function of any given FQDN.
Move the definition of Domain Contact into the only remaining method that uses it (3.2.2.4.12 Validating Applicant as a Domain Contact). Note that this method does not allow CNAME lookups when choosing the ADN, because it previously relied on Base Domain Name, which previously had the language "applied-for FQDN".
Use "ADN" consistently in method definitions instead of "FQDN" (which is insufficiently precise as to whether it's the applied-for FQDN or the ADN).
Clean up the language in the onion section around ADNs.
Here's a table of the methods and what ADN operations can happen on them according to this PR (plus onion issuance):
This is a more in-depth follow-up to #619. It's bigger than I had hoped, but pulling on one thread pulls on many others.