DISCUSSION PERIOD Begins | SC-088v2: DNS TXT Record with Persistent Value DCV Method

[Michael Slaughter]

SC-088v2: DNS TXT Record with Persistent Value DCV Method

Purpose of Ballot

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.

Motion

The 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 Begins

MODIFY 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:

• https://github.com/cabforum/servercert/compare/b6a014d4aee244c019ef6ca41667045cdbfefb81...e5de5f03885b377d2f7d41fc27ca6bc104b2710d

Motion Ends

This 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

Vote for approval (7 days)

• Start time: TBD
• End time: TBD

[Tobias S. Josefowitz]

Hi Michael,

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
>

> *Purpose of Ballot*

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

[Michael Slaughter]

Hi Tobi,

Thank you for raising the TTL interaction issue with CNAME following in Method 22. Your concerns were spot-on and needed to be addressed.

SC-088v3 will include the following changes to address the issues you raised:

• Eliminates TTL complexity entirely - Method 22 will now set a fixed 10-day maximum validation reuse period, regardless of any DNS record TTLs.
• Clarifies CNAME handling during ADN determination - As I mentioned on the 9/18 VSC call, I added explicit language that prohibits using CNAME following to determine the Authorization Domain Name
• Preserves standard DNS behavior for record resolution - "CNAME records MAY be followed when resolving the Persistent DCV TXT Record" ensures normal DNS resolution works as expected for the validation record lookup.

These changes are currently drafted here in GitHub.

My plan is to open the discussion period for SC-088v3 by the end of the day.

Thanks, M. Slaughter

[Aaron Gable]

While I understand that the use of ADNs and CNAME chasing is currently a hot topic, I'd like a little more clarity on one particular aspect of the concern here: why are we concerned about CNAME chasing in this method, but not concerned about CNAME chasing in the extant 3.2.2.4.7 DNS Change method, which explicitly allows looking for the underscore-prefixed subdomain under an ADN? Similarly, the brand new 3.2.2.4.21 makes no reference to ADNs one way or the other, thereby allowing their use by default.

It seems surprising for the three nearly-identical DNS-based methods to have very different rules about CNAMEs.

Aaron

--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/f4cde303-6c94-4047-9338-c300857d5af4n%40groups.cabforum.org.

[Henry Birge-Lee]

Hi Aaron,

I do think you raise a good point, but I am personally in favor of moving forward in the proposed direction on the grounds that:

When adding a new validation method, the community has the opportunity to design it from first principles in the most secure and optimal way. The method comes with no baggage and no issues with existing subscribers or infrastructure. If the method does not accommodate certain types of infrastructure configurations, those subscribers do not need to use this method.

When considering updating language around an existing method, I do believe ecosystem stability is a legitimate concern and the use cases of the subscribers who are using that method that may be impacted by the change should be considered (obviously these concerns need to be weighted proportionately to security concerns, but subscriber behavior is a real concern).

I also believe in minimalist ballots. This ballot has one objective: to introduce the new method and have it designed in the best way possible. If its also deemed that prepending underscore labels to CNAMEs is not a great idea for general DNS validation, I see that as a separate ballot.

Finally, this is not the first method do to something similar as an existing method but with different constraints around how it is done. Almost all of the ACME/non-ACME variants of the HTTP/DNS validation methods contain different processing restrictions when used in the ACME context or the non-ACME context. While its unfortunate this complexity exists in the BRs, this is how it is today.

Best,

Henry

[Tobias S. Josefowitz]

Hi Aaron,

On Tue, 23 Sep 2025, Aaron Gable wrote:

> While I understand that the use of ADNs and CNAME chasing is currently a
> hot topic, I'd like a little more clarity on one particular aspect of the
> concern here: why are we concerned about CNAME chasing in this method, but
> not concerned about CNAME chasing in the extant 3.2.2.4.7 DNS Change
> method, which explicitly allows looking for the underscore-prefixed
> subdomain under an ADN? Similarly, the brand new 3.2.2.4.21 makes no
> reference to ADNs one way or the other, thereby allowing their use by
> default.

Well, for one, 3.2.2.4.7 and 3.2.2.4.21 do not place lifetime authority
upon the DNS values or their corresponding TTL values. Since they do not,
they also do not do this in inconsisent ways, like by making the TTL of
the underscore-prefixed subdomain under an ADN have meaning while making
the original CNAME's TTL have no meaning.

> It seems surprising for the three nearly-identical DNS-based methods to
> have very different rules about CNAMEs.

They were written at different times, for different use cases, with
different histories of incidents and challenges in mind that have been
observed for pre-existing methods. As such I really do not find that all
too surprising. Keeping methods minimal in scope should somewhat correlate
with minimal amounts of fundamental issues we possibly overlooked
introducing them, as that is often the consequence of less complexity in
security-relevant questions.

This method in particular seems well-suited for a Domain Owner to
explicitely delegate authority over getting Certificates issued to a
Domain or subtree of a Domain to a third party while retaining control
over for how long this authority is delegated. Not by placing a CNAME, but
by placing the explicitly desired Persistent DCV Record.

Following CNAMEs before applying the _validation-persist label - or in
fact even with the _validation_persist label applied - removes this signal
of expliciteness again.

While both approaches have a huge overlap in use cases they are suited to
serve well, I think it is worth considering which one is the most
beneficial here for the WebPKI ecosystem going forward. But in any case,
since both approaches have their merits (ease vs. explicit signal of
intent), I think it is extremely good to understand which one SC-088vX
intends to introduce, so that it can be checked properly against its own
intention.

Tobi