Final Minutes of the F2F meeting of the validation-sc on 2025-10-16

[Corey Bonnell]

Below are the final minutes of the meeting indicated in the subject, as captured by Ben Wilson and approved at the 2025-10-30 meeting of the validation-sc.

 

Validation Subcommittee - Warsaw F2F 66 Minutes

Date: October 16, 2025
Chair: Corey
Recorder: Ben Wilson
Next Meeting: October 30, 2025
Prior Minutes: October 2 minutes approved without objection.
Administrative: Antitrust statement read; in-person sign-in sheet circulated. Corey presented slides on subcommittee progress since the Toronto F2F.

---

1. Progress Since the Last F2F Meeting

Corey began with a summary of recent accomplishments:

• The Persistent DV Ballot was approved. The effort was led by Michael Slaughter and represented the culmination of many months of discussion in the Validation Subcommittee.
• The group continued discussions on sunsetting manual DCV methods, which remain under consideration for deprecation.
• A Persistent IP Address Validation ballot was introduced. It closely mirrors Ballot SC-88 and has wide support. At the meeting, Dimitris volunteered to be the second endorser for this ballot.

---

2. DNSSEC Checks for Email-Based DCV Methods

Background: The group revisited a topic first raised by Roman and discussed on the mailing list: whether DNSSEC validation should be required when performing email-based DCV, specifically for MX record lookups.

Key Points Discussed

• Roman’s proposal: Suggested exempting email servers from DNSSEC validation since email-based DCV methods are expected to be deprecated soon. Building a feedback loop between DNSSEC validation and the mail delivery process would be operationally challenging.
• Martijn: Clarified that DNSSEC validation should occur in the CA’s DNS resolver, not at the mail server. MX records are ordinary DNS records, and validation could happen like any other lookup, though the lack of a back-channel to the CA system is the main challenge.
• Roman: Added that without such a feedback channel, failed lookups result in undelivered email and support escalations.
• Tobi: Argued that these undelivered emails highlight precisely the risk the DNSSEC requirement is meant to prevent.
• Dimitris: Warned that enforcing DNSSEC at this layer could make CAs responsible for diagnosing global DNS configuration problems. He noted frequent CAA misconfigurations and said CAs’ help desks are already burdened with DNSSEC-related troubleshooting. He favored Roman’s pragmatic view.
• Operational and Security trade-offs: Corey summarized that while the DNSSEC checks may provide some security benefits, their operational complexity—especially for cloud-based mail systems—was significant.
• Volume and Threat Context:
• Roman observed that email-based DCV represents only a small portion of issuance volume.
• Tobi replied that attackers focus on the weakest link, and this method could be exploited.
• Timing and TTL considerations:
• Tobi pointed out that CAA checks are refreshed frequently (maximum 8 hours or TTL), whereas email-based validations can remain valid for a year.
• Dimitris said that DNSSEC-protected zones already mitigate spoofing risk, while Tobi countered that timing issues between checks leave small windows of exposure.

Outcome and Next Steps

• No immediate changes were agreed upon.
• The group will seek Henry’s input to help describe a realistic threat model that would justify any additional requirements.
• Roman volunteered to summarize the discussion and send an email to the Validation Subcommittee list within two weeks to gather feedback and continue the conversation asynchronously.

---

3. Cleanup of “FQDN” vs. “Wildcard Domain Name” Terminology

Background: Corey introduced a related issue (GitHub Issue #621) concerning inconsistent terminology in the BRs, specifically between FQDN, Wildcard Domain Name (WDN), and Authorization Domain Name (ADN). The goal is to clarify when each term applies and to fix inconsistencies introduced over the years.

Key Discussion Points

• Current definitions:
• FQDN: A fully specified domain name including all domain labels up to the root.
• Wildcard Domain Name: An FQDN prefixed with *. (e.g., *.example.com).
• The BRs sometimes treat them interchangeably, which leads to ambiguity.
• Core issue: Section 3.2.2.4 requires the CA to validate every FQDN in the certificate. Taken literally, this does not include wildcards, which means wildcards could be considered unvalidated.
• Clint: Explained that in practice, a wildcard is validated by validating its underlying FQDN, so the BRs should clearly reflect that relationship.
• Tim H.: Provided historical context: the Authorization Domain Name (ADN) concept was introduced to represent the base domain that authorizes issuance for subdomains and wildcards. Over time, however, “FQDN” was reintroduced in places where ADN should have remained, reintroducing ambiguity.
• Ben: Commented that ADN is poorly understood; the BRs define it but do not explain its purpose or relationship to other terms. The group agreed that an explanatory section should describe how ADNs work and why they exist.
• Dimitris: Asked whether the confusion stemmed from unclear definition or insufficient explanation of how ADN interacts with validation rules.
• Tim: Suggested that the ADN definition should be concise (“the domain used to validate control of an FQDN”), with a new explanatory subsection describing its usage and relationship to other terms.

Wildcard, CNAME, and CAA Clarifications

• Wildcard validation:
  A wildcard domain (*.example.com) is not an FQDN itself but depends on validating the base name (example.com). CAs never validate a literal *. label.
• CNAME behavior:
  A CNAME record aliases one domain to another. A domain with a CNAME cannot have other records like CAA or TXT. For DCV, if the requested name is a CNAME, the CA must follow the alias to find the target record containing the validation token. This principle will be reviewed to ensure consistent wording.
• CAA validation (RFC 8659):
• CAA must be checked for each DNS name in the SAN independently.
• The CA follows CNAME chains as described in RFC 8659, which always yields one definitive record set for the name.
• The search walks up the DNS tree until a CAA record is found or the root is reached.
• The algorithm ensures predictable results even when multiple CNAMEs exist.
• For multi-SAN certificates, CAA must be checked for each domain, even if they share a base name; a single failure blocks issuance.
• .onion domains remain a special case and must stay explicitly excluded.
• A key rule: a DNS name that is a CNAME cannot have a CAA record at the same label.

FQDN vs. ADN in the BRs

• Tim H. noted that many methods were originally written to validate an ADN, not an FQDN. The BRs should restore that intent without changing meaning.
• Clint recommended replacing FQDN with ADN in places where the authorizing domain is intended.
• Group consensus: Each DCV method should clearly specify whether it validates:
• An FQDN (exact label),
• A wildcard (through the base FQDN), or
• An ADN (the domain authorizing one or more subordinate FQDNs).

Normative “Notes” in DCV Methods

• Several validation methods end with informative notes that effectively define normative behavior (e.g., “This method is suitable for wildcard validation”).
• Tim H. and Clint agreed that these should be converted into explicit normative requirements instead of left as notes.

Structural and Editorial Improvements

• Proposal: Move detailed explanations of ADN, wildcard relationships, and method applicability into a new explanatory subsection within §3.2, supplemented by a summary table showing which methods:
• Permit wildcard validation,
• Allow CNAME following,
• Support ADN use, and
• Exclude .onion names.
• Minor edits: Fix small grammatical issues (e.g., missing periods) and remove obsolete text (e.g., dated transition clauses).

Follow-Up Actions

• Tim H. and Martijn: Review every instance of FQDN, WDN, and ADN in the BRs and prepare recommended redlines.
• Tobi: Examine how email-to-ADN validation interacts with CNAME delegation to avoid unintended cross-domain authorization.
• Slaughter: Monitor how these edits affect CAA references.
• Tim H. and Martijn: Draft explanatory text and a summary table for inclusion in the BRs.

---

4. Summary and Next Steps

• DNSSEC + Email DCV: No immediate BR changes; Roman to draft summary and consult Henry for threat analysis.
• Terminology cleanup: Proceed with a full audit of FQDN, Wildcard Domain, and ADN usage; convert normative notes to explicit requirements; prepare explanatory section and method table.
• Editorial maintenance: Correct minor text errors and remove outdated language.

---

Adjournment:
With no further discussion, the meeting was adjourned early. The next Validation Subcommittee meeting is scheduled for October 30, 2024.