Final Minutes: Validation Subcommittee - March 10, 2026 (F2F 67)

[Corey Bonnell]

These are the final minutes of the teleconference described in the subject of this message as prepared by Trevoli Ponds-White. These minutes were approved at the Validation Subcommittee call on June 11th, 2026.

 

F2F Validation Meeting

Agenda

1.      Progress since previous F2F

2. Authorization Domain Names (AND) improvement ballot discussion
3. Validation of data sources
4. DNSSEC validation of subdomains under insecure domains (time permitting)

 

Progress Since Previous F2F

SC-91 (Persistent IP Address validation) - Final wording completed for the IP address variant of the DNS persistent method (building on the passed SC-88 ballot).

SC-94 (DNSSEC carve-out for email validation) - Discussion finalized in the subcommittee and passed up to Server Cert working group.

 

ADN Improvement Ballot Discussion

The intent of the discussion at the F2F meeting was to close on open questions for the ADN ballot. A key question around ADNs relates to validation reuse. Namely, should validation reuse be scoped to validated FQDNs or validated ADNs?

Given the example mysite.example.com with a CNAME to mysite.cdn.com. The CA would observe at the time of ADN construction that mysite.cdn.com is pointed to by mysite.example.com. The CA validates the record at mysite.cdn.com. So that reuse should be reusable by other FQDNs where the ADN algorithm resolves to mysite.cdn.com. However, the CA can’t reuse that validation for subdomains of mysite.example.com, such as admin.mysite.example.com. Said another way: following a CNAME during ADN construction (aka determining WHAT to validate) is different than following a CNAME during validation (aka the mechanics of HOW you validate.)   

 

Reliable Data Sources Discussion

This discussion was a deep dive into “Reliable Data Sources”. Discussing how Certificate Authorities (CAs) determine what qualifies as a "Reliable Data Source" under the Baseline Requirements (BRs), specifically focusing on Section 3.2.2.7 (Data Source Accuracy). It was noted that while the BRs require CAs to evaluate data sources for reliability, accuracy, and resistance to falsification there are no metrics, guidelines, or calibration around how these criteria should actually be interpreted or applied. For example, does "age of information" favor older data (more established) or newer data (more current)?

There were two goals of the presentation. 1) Determine if people had historical context for how to evaluate the data. 2) Determine if there is a way to produce supplementary guidance that doesn’t create new prescriptive rules.

For historical context there were some examples of how some auditors approach this section. Specifically that the expectation is that CAs are expected to use risk-based judgement to evaluate and that is why the current text is not more prescriptive. To allow that.

The conclusion of the discussion was that Scott Reas will produce a example language to move the conversation forward.

 

DNSSEC Discussion

We discussed how there is some confusion around the existing DNSSEC language. While the goal of the original ballot where it was added was that DNSSEC checks should work the way DNS lookups are intended to work the language can be read to imply additional steps are needed. For example, generally when you do a DNSSEC lookup you don’t need to check if child domains have DNSSEC enabled if parent domains did not.

Conclusions:

1. Fix the DNSSEC language to make it clear it should be done as a standard DNS lookup.
2. As part of clarifying DNSSEC lookups will not have a reuse time specified by the BRs. Instead it should align with the TTL of the DNS records.
3. Move all the DNSSEC language to a common place.