Final Minutes: Validation Subcommittee - 2026-04-16
Corey Bonnell
These are the final minutes of the teleconference described in the subject of this message as prepared by Greg Tomko. These minutes were approved at the Validation Subcommittee call on May 28th, 2026.
Meeting: 2026-04-16 CA/Browser Forum Validation Subcommittee
Facilitator: Corey Bonnell
Minute Taker: Greg Tomko
Attendees
Aaron Gable (Let's Encrypt), Aaron Poulsen (SSL.com), Adam Flock (SSL.com), Ben Wilson (Mozilla), Chris Clements (Google), Corey Bonnell (DigiCert), Corey Rasmussen (OATI), Dimitris Zacharopoulos (HARICA), Dustin Hollenback (Apple), Eric Kramer (Sectigo), Georgy Sebastian (Amazon), Gregory Tomko (GlobalSign), Henry Birge-Lee (Henry Birge-Lee (Private person)), Iñigo Barreira (Sectigo), Jaime Hablutzel (OISTE Foundation), Janet Hines (SSL.com), Johnny Reading (GoDaddy), Karolina Ruszczyńska (Asseco Data Systems SA (Certum)), Li-Chun Chen (Chunghwa Telecom), Mahua Chaudhuri (Microsoft), Martijn Katerbarg (Sectigo), Michael Slaughter (Amazon), Michelle Coon (OATI), Nate Smith (GoDaddy), Nome Huang (TrustAsia), Ono Fumiaki (SECOM Trust Systems), Pedro Fuentes (OISTE Foundation), Rebecca Kelly (SSL.com), Rich Smith (DigiCert), Rollin Yu (TrustAsia), Roman Fischer (SwissSign), Scott Rea (eMudhra), Sean Huang (TWCA), Shiloh Heurich (Fastly), 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))
Routine Items
Corey read the Note Well.
Minutes from April 2, 2026 were approved without objection.
Agenda:
1. Review of updated ballot language for ADN processing ballot (if any).
2. Discuss draft ballot from Dustin on Modernizing EVG Domain Ownership Reuse Requirements. (Added to Agenda at beginning of Call)
3. Discussion and review of verification of data sources ballot (if any).
4. Discussion of DNSSEC clarification ballot (if any).
5. Preliminary discussion on splitting DCV method #7 and dns-01 (and dns-account-01?).
Items Discussed on Call Not on Agenda:
1. CAA Parameters Ballot
2. Case Sensitivity of Validation Method Identifiers
ADM Processing Ballot
Aaron Gable addressed outstanding comments on Github Pull Request. Noted minor changes were made to the ballot primarily for clarity. Based on feedback, the effective date was updated to September 15, 2026.
A paragraph has been added to the top of 3.2.2.4 to specify application of the effective date. Aaron noted this method was used for NCSSRs.
Corey Bonnell recalls the same approach for effective dates was likely used on the profiles ballot.
Dimitris - Questioned if Wayne's ballot (CAA Parameters - SC98) has effective date of before Sept 2026. If that passes it wouldn't be effective due to language in ADM Proposal.
Aaron Gable - Confirmed SC98 has an effective date of March 2027 so no issue or conflict with the ADM proposal.
Have not asked for endorsers yet. Will do so via email in follow-up when ballot is in good shape for discussion period.
Validation of Data Sources
Scott Rea - No updates at the moment. Aims to share more on the list ahead of next call.
Modernizing EVG Domain Ownership Reuse Requirements
Dustin Hollenback presented a draft ballot to modernize the EV Guidelines' domain ownership reuse requirements, specifically to remove the current requirement to use WHOIS. The proposal replaces item 6 in section 3.2.2.14.1 with three options, intended to maintain a higher standard for EV than the TLS BRs:
1. Using an authoritative authenticated channel (feeds with registrars).
2. Reusing existing DCV only if performed less than 48 hours prior.
3. Performing a fresh domain control validation in accordance with 3.2.2.4.
Corey suggested that for item F (BR maximum reuse periods), it may be cleaner to simply reference the BRs rather than hardcoding to avoid needing future updates. Trevoli noted that we reference the BRs already in other places. Dustin concurred.
Martijn Katerbarg noted section 6.3.2 of the EVGs still states "The Validity Period for an EV Certificate SHALL NOT exceed 398 days" and suggested addressing this in the same ballot. Corey recalled this may have been addressed in the cleanup ballot (currently under IPR review for the EVGs). Martijn agreed to check and coordinate with Dustin if it was not already addressed.
Dustin stated they have one potential endorser and asked for additional endorsers. Scott Rea indicated they would likely endorse.
Discussion of DNSSEC clarification ballot
Rich not available this call, moved on to next agenda item.
Separating DNS-01 as Its Own BR Validation Method
Corey Bonnell introduced this topic, noting it arose from discussion on the prior week's Server Cert Working Group call regarding Wayne's CAA Parameters ballot (SC-098) which identified an interaction between the ACME DNS-01 validation method and BR DCV Method 7 (DNS-based validation). Proposal is to move DNS-01 into its own distinct validation method in the BRs, since Method 7 currently encompasses DNS-01 as a subset but also allows broader DNS-based validation.
Michael Slaughter asked whether carving DNS-01 out would break the superset language governing Method 7. Recommended a clean carve-out (similar to Methods 18/19 for ACME HTTP vs. non-ACME HTTP) rather than maintaining overlap. Noted the reason to keep them separate would be if distinct auditing of DNS-01 vs. general DNS change is desired.
Henry Birge-Lee raised two points:
1. If this sets a precedent, would the same pattern apply to DNS-Persist-01?
2. Making DNS-01 a formal BR validation method introduces a normative change. Currently, the RFC for DNS-01 is arguably not normative on CAs because it is not explicitly referenced as a validation method. CAs performing ACME DNS validation that does not strictly match every RFC stipulation could be affected.
Martijn Katerbarg noted that ACME requests can reuse DCV performed through other methods. Separating DNS-01 could complicate how CAs handle reuse across methods. Aaron Gable suggested that DNS-01 could be defined as a subsection of 3.2.2.4.7, making it a profile of Method 7. This would mean anything allowing Method 7 also allows DNS-01, but not vice versa. Michael Slaughter acknowledged this approach would be cleaner but noted it would reduce auditing granularity between DNS-01 and general DNS change.
Dimitris Zacharopoulos agreed the nesting approach is semantically sound but asked whether the same pattern would need to be applied to website-based methods for consistency. Aaron did not believe so, noting that Methods 18/19 differ more fundamentally.
Corey Bonnell suggested redefining Method 7 to specify an underscore-prefixed label that does not begin with _acme-challenge, with the new method specifying that it does. Corey also noted a complication with ACME Account-01, which also starts with _acme-challenge but uses two labels. Michael clarified that the two-label structure makes it distinct from Method 7.
Next Steps: Corey will file an issue and add it to the project tracker for future prioritization.
CAA Parameters Ballot (SC-098) (Additional Discussion
Martijn Katerbarg raised a concern regarding the CAA parameters ballot (SC-098), noting the RFC currently does not support using a CA's account URI (as opposed to the ACME account URI) for ACME accounts, and suggested the ballot should allow this, further noting the ACME Persist draft RFC already accounts for this. Henry Birge-Lee expressed support for this approach, noting that some CAs have ACME accounts nested under higher-level subscriber accounts.
Wayne Thayer asked whether language is needed to ensure the CA verifies that the ACME account is associated with the CA account. Martijn offered to work with Wayne on clarifying appropriate language. Henry Birge-Lee suggested coordinating with the ACME Persist draft co-authors to use the same account-referencing scheme across both techniques, to avoid CAs needing two separate processing systems. Martijn noted that ideally, RFC 8657 itself would be updated long-term.
Case Sensitivity of Validation Method Identifiers
Wayne Thayer raised a concern about case sensitivity in the validation method identifiers defined in SC-098. RFC 8657 says nothing about case. RFC 8555 appears to define ACME methods (DNS-01, HTTP-01) as lowercase. For non-ACME methods, the ballot specifies lowercase identifiers but does not explicitly state that CAs must or may treat them case insensitive. Seeking to add language specifying lowercase requirement.
Dimitris Zacharopoulos noted that subscribers add CAA records manually and may use mixed case. Questioned whether case sensitivity provides any security benefit. Wendy Brown noted that RFC 8555's grammar appears to define identifiers as case-insensitive, so explicitly requiring lowercase in the BRs would be a departure from the RFC. Aaron Gable stated CAs can accept any validation method string they wish, as long as it is documented. And the BRs could define lowercase strings as the canonical identifiers, and CAs that wish to accept case-insensitive versions could document that in their CP/CPS. Henry Birge-Lee expressed support for this approach, noting that ambiguity on this point could lead to future disputes. Wayne agreed to incorporate updated language into the ballot.
Adjournment
Corey Bonnell adjourned the meeting.