DISCUSSION PERIOD Begins | SC-088v2: DNS TXT Record with Persistent Value DCV Method
Michael Slaughter
The purpose of this ballot is to add section 3.2.2.4.22 "DNS TXT Record with Persistent Value" as a new domain control validation method in the Baseline Requirements for TLS Server Certificates. This method enables domain owners to establish account-scoped DNS validation records that can be reused across multiple certificate issuances, eliminating the need to update DNS records for each certificate renewal while maintaining equivalent security to existing DNS-based validation methods.
MotionThe following motion has been proposed by Michael Slaughter (Amazon Trust Services) and endorsed by Chris Clements (Google Chrome), Ryan Dickson (Google Chrome), Tim Hollebeek (Digicert) and Martijn Katerbarg (Sectigo).
You can view and comment on the Github pull request representing this ballot here.
Motion BeginsMODIFY the "Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates" ("TLS Baseline Requirements") based on Version 2.1.7 as specified in the following redline:
Motion EndsThis ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (at least 7 days)- Start time: September 10, 2025 21:30 UTC
- End time: on or after September 17, 2025 21:30 UTC
- Start time: TBD
- End time: TBD
Tobias S. Josefowitz
On Wed, 10 Sep 2025, 'Michael Slaughter' via Server Certificate WG (CA/B Forum) wrote:
> SC-088v2: DNS TXT Record with Persistent Value DCV Method
>
> The purpose of this ballot is to add section 3.2.2.4.22 "DNS TXT Record
> with Persistent Value" as a new domain control validation method in the
> Baseline Requirements for TLS Server Certificates. This method enables
> domain owners to establish account-scoped DNS validation records that can
> be reused across multiple certificate issuances, eliminating the need to
> update DNS records for each certificate renewal while maintaining
> equivalent security to existing DNS-based validation methods.
>
>
> https://github.com/cabforum/servercert/compare/b6a014d4aee244c019ef6ca41667045cdbfefb81...e5de5f03885b377d2f7d41fc27ca6bc104b2710d
This intends to include the following language:
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]).
The ADN definition mentions following a CNAME and using the CNAME's target
hostname as the ADN. I hence wonder, is that intended to apply here?
In particular, say we have a.b.example.com be a CNAME to foo.example.org.
Would it then be the expectation that, when an Applicant requests a
Certificate for a.b.example.com, a CA using the proposed method 3.2.2.4.22
might follow the CNAME to foo.example.org, then try to find
_validation-persist.foo.example.org, and, if present, perform 3.2.2.4.22
based on the Persisent DCV TXT Record found there?
If this is intended to be allowed, then how would the TTL for the CNAME
record at a.b.example.com factor into the effective reuse period? The
proposed method 22 explicitely mentions
If the Persistent DCV TXT Record has a TTL less than the validation
data reuse period [...] , then the CA MUST consider the validation
data reuse period to be equal to the TTL or 8 hours, whichever is
greater.
This invites the interpretation that in the proposed scenario, the DCV TXT
Record/Authorization might be reused for up to 200 days, for over 199 days
after a.b.example.com's TTL expired even if the record was removed. I
assume that at the very least that is not intended at all.
But maybe in fact the text is simply in this situation because the initial
CNAME chasing is already not intended or considered?
Tobi