Re: Subject: Confusion/questions regarding SC-088v3

['Dimitris Zacharopoulos' via dev-security-policy@mozilla.org]

Hi Tobi,

On 11/24/2025 1:03 PM, 'Tobias S. Josefowitz' via dev-security-policy@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

:
```


be placed at the "`_validation-persist`" label prepended to the
Authorization Domain Name being validated (i.e.,

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 FQDN for the purposes of domain validation. **CNAME records MAY be
followed when resolving the Persistent DCV TXT Record.*


in this context?

*Confirming the Applicant's control over a FQDN by verifying the presence of a Persistent DCV TXT Record identifying the Applicant. The record MUST "`_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 Defines: *the CA MUST NOT use the FQDN returned from a DNS CNAME lookup as This appears to be contradictory. Is CNAME delegation allowed or prohibited

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 <https://github.com/cabforum/servercert/blob/main/docs/BR.md#32247-dns-change> 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 <https://github.com/cabforum/servercert/blob/main/docs/BR.md#322422-dns-txt-record-with-persistent-value> instead.

Thanks,
Dimitris.

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:

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

[random-token].cname.example. 3600 [random-token].cname.example. 3600 IN TXT "authority1.example;

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

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 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?

Tobi

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.

--
You received this message because you are subscribed to the Google Groups 
"dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-security-policy+unsubscr...@mozilla.org.
To view this discussion visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/ed76cf1c-14d9-495d-a4a7-da895ba27dd4%40it.auth.gr.

smime.p7s
Description: S/MIME Cryptographic Signature