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
--
You received this message because you are subscribed to the Google Groups
"[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/50965ddf-95e1-fabe-65a9-6015100fe981%40opera.com.
