Subject: Confusion/questions regarding SC-088v3

[Arabella Barks]

Hi all,

I have someting confusion regarding SC-088v3.

Regarding https://github.com/cabforum/servercert/pull/608/files#diff-e0ac1bd190515a4f2ec09139d395ef6a8c7e9e5b612957c1f5a2dea80c6a6cfeR1041:
```

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.
``` 

Defines: the CA MUST NOT use the FQDN returned from a DNS CNAME lookup as the FQDN for the purposes of domain validation. CNAME records MAY be followed when resolving the Persistent DCV TXT Record.

This appears to be contradictory. Is CNAME delegation allowed or prohibited in this context?

For example:
➜  ~ dig txt _validation-persist.domain.example
; <<>> DiG 7.6.5 <<>> _validation-persist.domain.example txt
;; global options: +cmd

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49009
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;_validation-persist.domain.example. IN TXT

;; ANSWER SECTION:
_validation-persist.domain.example. 86400 IN CNAME [random-token].cname.example.
[random-token].cname.example. 3600 IN TXT "authority1.example; accounturi=https://authority1.example/acct/123; persistUntil=1782424856"
[random-token].cname.example. 3600 IN TXT "authority2.example; accounturi=https://authority2.example/acct/abc; persistUntil=1782424856"

;; Query time: 142 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Nov 22 21:28:35 CST 2025
;; MSG SIZE  rcvd: 80

I would like to ask:
- Are those CAs compliant in issuing certificates for domain.example(authority for account 123, authority2 for account abc)?

- Additionally, is the issuance of a certificate for subdomain.domain.example permitted in this scenario?

Thanks.

- (https://github.com/cabforum/servercert/pull/608)[Pull request of Balloc SC-088v3]

[Aaron Gable]

Suppose example.com has a CNAME to example.org, and you want to validate control of example.com. This sentence means that you cannot look up _validation-persist.example.org (i.e. cannot follow a CNAME for the purposes of determining the ADN). But when you look up _validation-persist.example.com, you will of course follow CNAMEs from there, because that is simply how DNS works.

Aaron

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/0462d0a4-4caf-434d-a00d-48148f700354n%40mozilla.org.

[Arabella Barks]

Aaron,

I appreciate your explanation, but I look forward to more confirmation from others.

Thanks!

Ara

[Tobias S. Josefowitz]

Hi Arabella,

On Sat, 22 Nov 2025, Arabella Barks wrote:

> I have someting confusion regarding SC-088v3.
>
> Regarding
> https://github.com/cabforum/servercert/pull/608/files#diff-e0ac1bd190515a4f2ec09139d395ef6a8c7e9e5b612957c1f5a2dea80c6a6cfeR1041
> :
> ```
>

> *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.*```
>
> Defines: *the CA MUST NOT use the FQDN returned from a DNS CNAME lookup as
> the FQDN for the purposes of domain validation. **CNAME records MAY be
> followed when resolving the Persistent DCV TXT Record.*

>
> This appears to be contradictory. Is CNAME delegation allowed or prohibited
> in this context?

I think at the heart of the issue there is a misunderstanding that has
somehow become systemic in WebPKI circles. In DNS, a CNAME record is not a
"delegation" of any sort, in DNS a CNAME is an "alias". As far as DNS is
concerned, a "delegation" is achieved by pointing NS records at a
different nameserver, which designates it as responsible for the "zone" at
the record with the delegation and below.

> For example:
> ? ~ dig txt _validation-persist.domain.example

> ; <<>> DiG 7.6.5 <<>> _validation-persist.domain.example txt
> ;; global options: +cmd
>
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49009
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;_validation-persist.domain.example. IN TXT
>
> ;; ANSWER SECTION:

> [random-token].cname.example. 3600

> [random-token].cname.example. 3600 IN TXT "authority1.example;
> accounturi=https://authority1.example/acct/123; persistUntil=1782424856"
> [random-token].cname.example. 3600 IN TXT "authority2.example;
> accounturi=https://authority2.example/acct/abc; persistUntil=1782424856"
>
> ;; Query time: 142 msec
> ;; SERVER: 8.8.8.8#53(8.8.8.8)
> ;; WHEN: Sat Nov 22 21:28:35 CST 2025
> ;; MSG SIZE rcvd: 80

Keeping the difference between "alias" and "delegation" in mind, in your
example, _validation-persist.domain.example is an "alias" to
[random-token].cname.example. Or in other words, ... software ... should
behave as if _validation-persist.domain.example itself had the records
defined that are defined as [random-token].cname.example, or to make it
explicit:

A the result of a TXT lookup to _validation-persist.domain.example should
result in

TXT "authority1.example;
accounturi=https://authority1.example/acct/123;
persistUntil=1782424856"

and

TXT "authority2.example;
accounturi=https://authority2.example/acct/abc;
persistUntil=1782424856"

Software should at no point - under normal circumstances - even know about
the existence of a CNAME record at _validation-persist.domain.example.

In addition, sub._validation-persist.domain.example is not affected by the
CNAME at all.

> I would like to ask:
> - Are those CAs compliant in issuing certificates for
> domain.example(authority for account 123, authority2 for account abc)?
>
> - Additionally, is the issuance of a certificate for
> subdomain.domain.example permitted in this scenario?

Considering that in the scenario you described, the technical intent in
DNS is that _validation-persist.domain.example is to be treated as if it
had the TXT records that are placed at [random-token].cname.example as its
own records, _validation-persist.domain.example allows account 123 at
authority1 and account abc at authority2 to issue certs for
domain.example.com. As such, CAs having correctly validated this may of
course treat this as successful domain validation for domain.example and
issue for it to the subscriber who proved domain control.

Tobi

[Dimitris Zacharopoulos]

Hi Tobi,

On 11/24/2025 1:03 PM, 'Tobias S. Josefowitz' via dev-secur...@mozilla.org wrote:

Hi Arabella,

On Sat, 22 Nov 2025, Arabella Barks wrote:

I have someting confusion regarding SC-088v3.

Regarding
https://github.com/cabforum/servercert/pull/608/files#diff-e0ac1bd190515a4f2ec09139d395ef6a8c7e9e5b612957c1f5a2dea80c6a6cfeR1041
:
```

*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.*```

Defines: *the CA MUST NOT use the FQDN returned from a DNS CNAME lookup as
the FQDN for the purposes of domain validation. **CNAME records MAY be
followed when resolving the Persistent DCV TXT Record.*

This appears to be contradictory. Is CNAME delegation allowed or prohibited
in this context?

I think at the heart of the issue there is a misunderstanding that has somehow become systemic in WebPKI circles. In DNS, a CNAME record is not a "delegation" of any sort, in DNS a CNAME is an "alias". As far as DNS is concerned, a "delegation" is achieved by pointing NS records at a different nameserver, which designates it as responsible for the "zone" at the record with the delegation and below. 

Although the "NS" delegation is a generic DNS "catch-all" way to pass control of a specific namespace to another entity, I respectfully disagree that this is the only method historically allowed for the WebPKI.

The CA/B Forum has had extensive discussions in the past where the term "delegation" was used in the context of a CNAME record added by the Domain Owner, pointing to some other Domain Name (the "delegated entity").

This interpretation is also supported by the recent language update in section 3.2.2.7 which acknowledges that a Domain Owner could delegate (via CNAME) an underscore-prefixed Domain Label (emphasis mine):

If the CA or an Affiliate of the CA operates a DNS zone to which Applicants can delegate (via CNAME) their underscore-prefixed Domain Label, the CA MUST ensure that each Applicant delegates to a unique FQDN within that zone. A CA or Affiliate of a CA SHOULD NOT operate such a service, and SHOULD direct any Applicants using such a service to use the method described in Section 3.2.2.4.22 instead.

Thanks,
Dimitris.