Final minutes for the 2025-09-18 Validation Subcommittee Teleconference

[Corey Bonnell]

These are the final minutes of the Teleconference described in the subject of this message, prepared by Ryan Dickson (Google) and approved at the 2025-10-02 meeting of the validation sub-committee.

 

Validation Subcommittee Teleconference 2025-09-18

 

# Attendees

 

Aaron Poulsen (Amazon), Adrian Mueller (SwissSign), Aneta Wojtczak-Iwanicka (Microsoft), Ben Wilson (Mozilla), Bineesh Ambali Vadakkekandi (Microsoft), Chris Clements (Google), Clint Wilson (Apple), Corey Bonnell (DigiCert), Corey Rasmussen (OATI), Dimitris Zacharopoulos (HARICA), Gregory Tomko (GlobalSign), Gurleen Grewal (Google), Henry Birge-Lee (Henry Birge-Lee (Private person)), Iñigo Barreira (Sectigo), Jaime Hablutzel (OISTE Foundation), Janet Hines (VikingCloud), Johnny Reading (GoDaddy), Kate Xu (TrustAsia), Luis Cervantes (SSL.com), Mahua Chaudhuri (Microsoft), Martijn Katerbarg (Sectigo), Michael Slaughter (Amazon), Michelle Coon (OATI), Nargis Mannan (VikingCloud), Nate Smith (GoDaddy), Nome Huang (TrustAsia), Ono Fumiaki (SECOM Trust Systems), Pekka Lahtiharju (Telia Company), Rebecca Kelly (SSL.com), Rich Smith (DigiCert), Rob Stradling (Sectigo), Rollin Yu (TrustAsia), Ryan Dickson (Google), Scott Rea (eMudhra), Sean Huang (TWCA), Stephen Davidson (DigiCert), Tim Callan (Sectigo), Tobias Josefowitz (Opera Software AS), Wayne Thayer (Fastly), Wiktoria Więckowska (Asseco Data Systems SA (Certum))

 

# Corey read the note-well

 

# Agenda

 

- Discussion of Base Domain Name definition, ADN definition, CNAME, and interplay with specific DCV methods

- Persistent IP address validation method

- DNSSEC checks for email-based DCV methods

 

# Approval of minutes

 

- 2025-09-04 minutes were approved

 

# 1. Discussion of Base Domain Name definition, ADN definition, CNAME, and interplay with specific DCV methods

 

- Corey B. described the background for this discussion and referenced an open Bugzilla incident report it relates to.

- Stephen described potential paths forward. (A) Parsing history for a method that’s been deprecated, or (B) looking forward to more clearly align expectations going forward. He noted a possible interplay with this discussion and the draft SC-090 ballot, which recommends sunset of additional DCV methods. Stephen wondered whether the SC-090 work could be extended to also consider any clarifications resulting from this discussion. 

- Ryan described a preference to keep this work separate from SC-090. He provided justification that emphasized (A) discussion at the last Validation Subcommittee meeting related to promoting simplicity in the balloting process and (B) commingling outputs from this discussion with SC-090 may needlessly slow progress on all fronts. Ryan emphasized we should push clarifications forward now, regardless of SC-090.

- Rich described research focused on understanding the intent of the definitions being discussed across Bugzilla and on today’s call. Rich stated that he believes the original discussion of the corresponding BR text, going back to 2015, states that where ADN is used, it was intended to allow the following of CNAMEs. He described discussion between Rick Andrews and Kirk Hall regarding Method 8, where Rick wanted to explicitly add CNAME following to that particular method, and Kirk Hall described it already being covered in the revised definition of ADN. Rick pointed out that Method 8 doesn’t use the term ADN and asked it be added, which Kirk then agreed to do. Rich interprets this discussion to signal the authors of the methods and this particular definition were completely cognizant of the fact that adding that phrase into a particular method was enabling that method to follow CNAMEs.

- Ben questioned, regardless of whether what was done in the past, was it the right thing to do then, and should we bifurcate the definition of ADN going forward. 

- Wayne stated that discussion related to the intended use of these words going forward may be overcome by events given the potential deprecation of methods described in SC-090.

- Joe emphasized the perceived value of permitting CNAME following in support of subscribers.

- Tobi offered a counterpoint to Rich’s. Tobi does not believe that intentionally adding reference to ADN in Method 8 means that it wasn’t added in error to any other method. The deliberate intention to place it in Method 8 does not mean anything for the current incident we are discussing.

- Clint responded to Joe and emphasized that the focus of this discussion relates to the use of CNAME lookups in the context of a WHOIS record. He does not believe anyone has raised the possibility of removing the allowance of CNAME redirects in the case of the DNS.

- Dimitris offered his interpretation - that the control of a domain name and the ownership of the domain name being used, at least in his understanding, is done so in an equivalent manner. Meaning if you have a CNAME from A to B, you also trust the owner of domain B to complete domain validation. If you trust the other domain owner to place a file with a random value on their website, you would also trust them to receive an email at their domain contact address in WHOIS. If we don’t consider it this way, it becomes very complicated.

- Martijn, in response to Dimitris, stated there is a difference between CNAME following and CNAME substitution. Following CNAMEs is a basic principle of DNS. Substitution, however, has more complications. As an example, if we consider an email method, if someone sends an email to ad...@martijn.com and martijn.com is a CNAME towards dimitris.com, the receiving server can deliver ad...@dimitris.com to a completely different mailbox than ad...@martijn.com. CNAME following would still deliver the email to the original address, but substitution potentially delivers it to a completely different mailbox. 

- Dimitris described that the bottom line is that a domain was delegated. That is a deliberate action.

- Martijn stated that the described use is not done so in a way that CNAME ordinarily works in the construct of DNS, and therefore the risk attached is not obvious.

- Tobi agreed. When applying the specific expectations of CNAME delegation outside of DNS, and adding additional expectations to it, that is bound to surprise some applicants.

- Clint agreed with Tobi. The described delegation is not what a DNS CNAME is. The described use is using CNAME in a way that the RFC does not intend it to be used for.  

- Dimitris stated when we added this method, CNAME’s referenced use was not specific to the DNS RFC, but the intent to delegate. When we use ownership and control interchangeably, it would be reasonable to expect the destination domain owner is considered as a delegated entity.

- Tobi emphasized that what happens in DNS is framed by the scope of DNS and its corresponding RFCs. Now we’re adding something on top of that scope that applicants may not be aware of. This additional interpretation may be non-obvious.

- Rich indicated the BRs state a CA may use the FQDN returned from a DNS CNAME as the FQDN for the purposes of domain validation. The TLS BRs are not confining CNAME in this respect to what it is used for in DNS. The BRs add its own definition, that you can follow a CNAME for the purposes of domain validation.

- Tobi clarified his position was in response to Dimitris’ earlier point that placing a CNAME declares intent to have it used in the way that is being discussed. Tobi was challenging that intent

- Rich expressed that we can’t define intent - but the related RFCs, just like the TLS BRs, are public documents. By defining the process and having it available, we cannot control whether subscribers read or understand it.

- Wayne described that it seems there are two discussions taking place. Some folks are arguing whether the language permits the practice, and others are looking at whether the practice was a reasonable thing to do. Wayne described himself clearly in the camp with Tobi in that the described behavior is not a good idea because it creates behaviors people wouldn't expect, and it opens up risks that he didn’t think were considered when this method was created. However, Wayne indicated it is not clear that the language forbids this interpretation. Separating these thought processes would make it a more productive discussion.

- Stephen agreed with Wayne. Though he believes the practice was permitted, the discussion is whether this practice should be allowed going forward. He is uncomfortable with a retroactive reading that might involve revocation of certificates.

- Clint agreed with Wayne’s stated bifurcation of topics. While he could understand how someone could read the definition of ADN and come away with the conclusion that they could look up a WHOIS record from a CNAME, that relies on such a deep misunderstanding of domain name systems and what we are doing that it’s just remarkable that it’s happened - and for it to be a longstanding practice that hasn’t been questioned. 

- Slaughter tied the discussion to the ongoing work with SC-088. He was considering explicitly prohibiting use of the FQDN returned from a CNAME lookup as the FQDN for the purposes of the validation method. 

- Henry agreed with Slaughter’s proposed change. Following CNAMEs in the purpose and described scope of DNS is appropriate. However, he did not consider it appropriate to take a label found at a CNAME and then do further processing, though he did see how the current definition supports that reading. 

- Ben said we should look at the definition of ADN and see whether tweaks are needed to improve clarity or better describe how they may be used during validation. 

- Corey B. summarized that the interpretation described in Bugzilla is “reasonable”, however it's uncertain whether it’s desired. 

- Tobi expressed disagreement with that summary. Tobi indicated that while he understands the interpretation provided and why it happened, he did not consider it “reasonable.”

- Wayne countered that it’s a “possible” interpretation.

- In chat, Clint offered that he saw it as an interpretation that can be justified to the extent that it's not quite 100% clear that it's a completely unreasonable interpretation. He said, at the least, it's a worrisome interpretation.

- Corey B. highlighted some comments from this call that agreed with the interpretation. In the spirit of moving forward, perhaps during a future call, we look at the definitions and see how we can improve them. There are opportunities to add clarity.

- Ben highlighted parts of the existing definition that could lead to confusion.

- Corey B. likened the situation to how CAA tree climbing used to work, how it has since been improved, and whether the same approach could be taken here.

- Henry clarified an earlier comment re: concern about the interpretation in question and stated two points of justification. First, as a security researcher, he considers that more attack surface is always worse. The second is on precedent - we should not extend use of well-defined terms in ways that they are not intended to mean. Henry emphasized his opinion and offered no comment on the existing language or the original intent of the authors. This view was strictly focused on a view going forward.

- Stephen asked about the implications of this discussion and how it might otherwise affect CNAME and delegation in other Methods. 

- Clint again emphasized his earlier comment. This discussion is not talking about how CNAME works in the context of DNS use. We’re only talking about it in the context of a method that’s no longer allowed. From his perspective, ensuring that it’s clear that CNAME aliases only allow you to do validations in the context of DNS, and nowhere beyond that.

- Rich asked how restricting CNAME to only DNS affects subscribers relying on this practice today.

- Martijn described CNAME natively as working with other methods.

- Rich questioned what happens if the CDN does not support those methods.

- Martijn described that if the CDN doesn’t support something, that’s their choice.

- Tobi added that this might not be a realistic use case. Instead, it seems the CDN would be more likely to use ACME as it’s the more automateable option. 

- Rich said you might expect that, but maybe they don’t. He said we should be mindful of inadvertent impact.

- Clint agreed that we should avoid unintentional changes.

- As time was running out, Corey B. described next steps:

    - The group should determine the desirable definition and interpretation of ADN going forward. We should map out different possibilities, determine which are desirable and which are not, and create a ballot to improve the existing language. This would be handled separate from SC-090 given complexity. It could also make good discussion at the F2F.

    - Corey B. volunteered to help lead this work going forward, and encouraged others to participate.

 - Tobi added we should look beyond only the definition of ADN, but we should also look at how it’s used throughout the BRs to identify other areas for improvement.

 - We’ll pick up the agenda topics not discussed today next time.

 

# Adjourn.