Final minutes for the Validation Subcommittee teleconference - December 11, 2025
Corey Bonnell
Below are the final minutes of the meeting indicated in the subject, as captured by Chris Clements and approved at the 2026-01-08 meeting of the validation-sc.
Meeting Date: 2025-12-11
Attendees: Aaron Gable (Let's Encrypt), Aaron Poulsen (Amazon), Adriano Santoni (Actalis S.p.A.), Arman Asemani (Apple), Ben Wilson (Mozilla), Clint Wilson (Apple), Dustin Hollenback (Apple), Eric Kramer (Sectigo), Georgy Sebastian (Amazon), Henry Birge-Lee (Henry Birge-Lee (Private person)), Iñigo Barreira (Sectigo), Julie Olson (GlobalSign), Martijn Katerbarg (Sectigo), Michael Slaughter (Amazon), Michelle Coon (OATI), Nargis Mannan (VikingCloud), Nate Smith (GoDaddy), Nome Huang (TrustAsia), Ono Fumiaki (SECOM Trust Systems), Rich Smith (DigiCert), Rollin Yu (TrustAsia), Scott Rea (eMudhra), Sean Huang (TWCA), Shiloh Heurich (Fastly), Sven Rajala (Keyfactor), Thomas Zermeno (SSL.com), Tobias Josefowitz (Opera Software AS), Trevoli Ponds-White (Amazon), Wayne Thayer (Fastly), Wendy Brown (US Federal PKI Management Authority), Wiktoria Więckowska (Asseco Data Systems SA (Certum))
Note well:
- Wayne Thayer read the note well.
Agenda:
- Call for approval for the 2025-10-30 meeting minutes (sent to the management list last week)
- Continue discussion on https://github.com/cabforum/servercert/pull/627
Minutes Approval:
- Minutes from the November 13th meeting were sent to the list last week. Those minutes are approved.
Continue discussion on https://github.com/cabforum/servercert/pull/627:
- Some significant discussion has occurred in the PR.
- Aaron Gable stated that the two major changes since the last on call discussion are (1) the DNS change method does now allow CNAME chasing during the derivation of the ADN (this is one of the things that early drafts of this ballot removed, however feedback was received saying that it was too big of a change) and (2) all of the language around which methods allow which pieces of the ADN derivation algorithm - whether you can prune labels or chase CNAMEs etc. - has been moved so that instead of it being a collection of sentences at bottom of each individual method - which while nice while your reading that method - also introduces confusion about whether those sentences are just triggers for the ADN algorithm or just natural English that can be interpreted outside of the ADN algorithm - all of these sentences have been removed and is now represented as a table at the top of section 3.2.2.4.
- Wayne suggested that the main concern he has is that this ballot removes the ability to follow CNAMEs for wildcard lookups. Aaron confirmed that is correct. Wayne’s sense is that CAs serving cloud providers make extensive use of this and that feels like a major change. He doesn't have any data to back this up though. Aaron stated that we need to remember that what we’re talking about is not whether you can follow CNAMEs once you are hunting for the actual validation TXT record - that is definitely allowed. The question is whether you can follow CNAMEs when determining where you even want to go looking for the DNS TXT record. Martijn Katerbarg suggested so long as you use example.com which is the requested domain name and we use that as the ADN, then the CNAME lookup from example.com to example2.com would still be allowed to be followed. You just wouldn't be able to substitute itself. Aaron confirmed. There are two possibilities here (1) you are trying to get a certificate for *.example.com and example.com itself is CNAME’d over to a CDN - if you end up looking for a TXT record or if you do a validation method that tries to resolve example.com itself then example.com is the ADN - you follow CNAMEs from there over to the CDN and then you find the relevant TXT record there - this is completely acceptable (2) what’s not acceptable is during ADN construction, following the CNAME from example.com over to the CDN - then descending downward into the tree so the thing you’re looking for is _acmechallenge.CDN.com and then following potential CNAMEs from there during validation. Martijn suggested we’re still allowed to follow the CNAMEs but we’re not allowed to substitute them and then follow any further trees on them. His personal opinion is that this should not be allowed on any request.
- Rich Smith suggested that in the last meeting he promised to do a full deep dive into this and try to sort it out. He apologizes for not doing that. Rich thinks one of the things in Jacob’s presentation in the last meeting was that he was coming from a position that he didn’t consider this a significant change to existing interpretation even though it's a significant change to wording. Rich doesn’t think that's the case. He thinks there is a chance that this is a very significant change to the actual requirements. It may be unintentional because we just haven't got the wording down precisely and it may be in some cases very intentional. The case we just walked through is a significant change in at least to how the existing wording can be interpreted. Maybe it's not the way it should be interpreted but maybe it's a way that it could have been interpreted. Rich asks that we insert a 6-month implementation rather than have it immediately in effect when it passes IPR. His organization will have to do a deep dive into code just to make sure they haven't interpreted something somewhere differently than what this ballot is proposing. There's a good chance they may have.
- Aaron stated a reasonable implementation timeline makes sense. The intent is that there are no changes to what is actually allowed except for no longer allowing any form of prune then CNAME because as we’ve discussed in previous meetings - if you go from www.blog.example.com to blog.example.com to example.com to CDN.com because example.com is a CNAME - control of CDN.com does not at all reflect control of www.blog.example.com - and so doing prune than CNAME is actually not at all a demonstration of control. The requirements should not at all ever allow prune than CNAME. Rich stated their development staff suggests that this would affect them because they kind of allow the customer to choose the ADN in a way. Let’s say the customer orders a certificate for www.blog.example.com and the owner of example.com is the Subscriber - they say they’re only ordering this one certificate but they want validation of their whole domain so they don’t have to go through this exercise next time so validate example.com - so they are pruning but not without the customer’s knowledge. He understands that this is hard to police from an audit but it's the owner of the domain that's asking them to do this and then if they CNAME over to their CDN it is actively them saying they’re delegating the entirety of their domain over to their CDN. Martijn suggested you should be able to do pruning and then follow CNAME but you shouldn't be allowed to CNAME and then prune off of those. If I’ve got www.example.com and then go to example.com itself, which is a CNAME, I should be allowed to follow the CNAME but if that CNAME points to www.example2.com, I then shouldn't be able to go to example2.com itself. But, if example.com is a CNAME and that CNAME is another CNAME to an actual TXT record somewhere, it feels like that is still natural DNS CNAMEing. Rich agrees but he doesn’t think that's what the current wording is aiming for. Aaron stated the issue is that if during ADN construction, you go from www.blog.example.com to blog.example.com to example.com to CDN.com - you say okay I did some pruning and then I followed a CNAME and now CDN.com is going to be my ADN, then you prepend _acmechallenge.CDN.com and then you do a TXT record lookup on _acmechallenge.CDN.com and then that CNAMEs over to somewhere else - who knows where that is going and control of that has no bearing on control of www.blog.example.com. That’s why the ADN algorithm says don’t prune then CNAME. What is acceptable is having the company that says what we want to do is use example.com for all of our validations and we’ve told you that this is the ADN we want to use and by the way our ADN is CNAME’d over to some CDN. Then one option you have is to prune www.blog.example.com down to example.com, declare that example.com is the ADN and then during actual validation you lookup example.com and you do a TXT query on example.com and it’s CNAME’d to CDN.com so you find the TXT records at CDN.com and one of those is the relevant TXT record that your looking for… or you do a TXT query for _acmechallenge.example.com and you make sure that your customer has also CNAME’d _acmechallenge.example.com to somewhere appropriate over on their CDN. Either of these still work - they can still CNAME their base domain name or _acmechallenge.their.base.domain.name - it's just that CDN.com is not an appropriate ADN that you can start from. Martijn confirmed this explanation makes a lot of sense from his point of view.
- Rich will do more of a deep dive but he thinks the words need to be more clear. We don’t want to trade one set of unclear requirements for another set of unclear requirements. Aaron suggested we’re replacing a set of poorly written and poorly understood requirements with a set of clearly written but easy to misunderstand if your mental model is still based on the old requirements. Someone reading this draft from scratch would understand what's going on without all of the mental baggage this group has built up.
- Aaron stated that doing CNAME lookups is something that feels like it is truly a validation activity. The vast majority of CAs would be much happier living in a world where the only time you’re doing DNS queries is during validation itself where you are hunting for the correct record or the correct IP address to find the TXT file at and the ADN algorithm is purely local. Following CNAMEs during determination of an ADN feels really weird because in theory determination of an ADN happens before validation because validation starts with “oh what ADN am I looking at”, yet those CNAME lookups that happen during ADN construction are still subject to everything else in the BRs, including specifically you MUST be doing DNSSEC, you MUST be logging, etc. They are parts of the validation process and therefore subject to all of the audit logging requirements in section 5. Getting rid of CNAME chasing during ADN construction actually makes CA operations more simple and more clear. All but one of the methods that allow CNAME chasing during ADN construction are going away in the next 2 years. The only method in the future that will allow CNAME chasing during ADN construction is the DNS change method - at that point, what are we doing? It should not be chasing CNAMEs during ADN construction, rather only when doing validation. This makes everyone's lives easier. Rich doesn’t disagree, but banning CNAME chasing during ADN construction for those manual methods creates more work for everyone without any added security benefit. Aaron stated that’s why the current ballot text still allows CNAME chasing for all of those methods. This was a conscious decision that they made while drafting the ballot.
- Trevoli Ponds-White enjoys the table in the draft and suggests spelling out more clearly things like wildcard applies to this part of the rule etc. In short, make the columns more verbose or call out the terms more explicitly at the beginning of the requirements.
- Tobias Josefowitz emphasized that the claim that there are no security reasons for disallowing CNAME chasing during ADN creation is not true. Allowing this itself is a security issue that leads to unintended consequences where people that don’t control or own a FQDN can still get certificates signed for them - this is both an unintended consequence and a security issue. Furthermore, saying that your customers make the decision themselves regarding which domain to use based on CNAME chasing during ADN creation - your customer doesn't necessarily have to be the site owner, it could be the adversary - so this is not giving us anything. Lastly, considering this is currently an existing security issue in the webPKI and we’re basically discussing this because we had perceived contradictions in the BRs that led to interpretations of the ADN construction and CNAME chasing that several root programs did not agree with - to say this isn’t urgent doesn’t seem right. It’s active undesired behavior that is currently allowed according to some interpretations of conflicting sections of the BRs. There should be some urgency in fixing this. He’s supportive of where this draft is headed.
- Wayne stated the call to action is for members to review the PR.
Discussion about RDAP in EVGs https://github.com/cabforum/servercert/issues/642:
- Clint Wilson introduced the topic. We went through a process to make sure the BRs allowed both WHOIS and RDAP. We never updated the EVGs. The data reuse requirements in the EVGs have prerequisites of checking the WHOIS record and confirming that the organization ownership information has not changed. As more domain registrars switch to only having RDAP available to surface information about domains, it means that this part of the EVGs and EV issuance workflow kind of breaks.
- From his reading this seems like it needs to be a change in the EVGs because while WHOIS and RDAP are both surfacing the same type of information, the information surfaced in an RDAP lookup is not technically a WHOIS record and that’s what the EVGs require. Is this a valid interpretation and if so is a cleanup ballot appropriate? Clint wanted to highlight this in case there are CAs that have been using RDAP based on the assumption that it is an equivalent to WHOIS in this context of EV certificates.
- Do folks believe that the current EVGs allow RDAP to be used for the purpose of determining whether information can be reused from a prior validation event? Wayne believes they’ve always tried to use the failed closed concept with the guidelines and within that context it doesn't seem like it would be allowed.
- Does anyone think this needs a ballot aside from it just going into the cleanup ballot? No response and it seems like a cleanup ballot is appropriate. CAs should definitely take a second look and make sure that they are not and have not been using RDAP for the purpose of EV certificate data reuse.
- Ben Wilson asked if it could be argued that RDAP is just a version of the lookup that is version 2 or an advanced version of WHOIS? Clint thinks it can be argued that RDAP is a protocol that replaces the WHOIS protocol, but he finds it difficult to justify that the information returned by the RDAP protocol qualifies as a WHOIS record returned by the WHOIS protocol. Martijn stated that WHOIS is a defined term in the BRs which incorporates RDAP. Wayne agrees with Martijn but believes this is an even stronger case for putting this into a cleanup ballot for clarification.
- In conclusion, yes it is allowed based on the definition of WHOIS in the BRs and is therefore incorporated into the EVGs but it would be helpful to include this in a cleanup ballot to remove ambiguity.