Final Minutes for Validation Subcommittee call February 5, 2026
Corey Bonnell
These are the final minutes of the teleconference described in the subject of this message as prepared by Janet Hines. These minutes were approved at the Validation Subcommittee call on February 19, 2026.
[Minutes] Validation Subcommittee call February 5, 2026
Notes by: Janet Hines (VikingCloud)
Attendees
Aaron Gable (Let's Encrypt), Adriano Santoni (Actalis S.p.A.), Ben Wilson (Mozilla), Chris Clements (Google), Corey Bonnell (DigiCert), Corey Rasmussen (OATI), Dimitris Zacharopoulos (HARICA), Enrico Entschew (D-TRUST), Eric Kramer (Sectigo), Grace Cimaszewski (Grace Cimaszewski (Private Person)), Gregory Tomko (GlobalSign), Gurleen Grewal (Google), Hisashi Kamo (SECOM Trust Systems), Iñigo Barreira (Sectigo), Janet Hines (VikingCloud), Johnny Reading (GoDaddy), Luis Cervantes (SSL.com), Mahua Chaudhuri (Microsoft), Michelle Coon (OATI), Nate Smith (GoDaddy), Nome Huang (TrustAsia), Ono Fumiaki (SECOM Trust Systems), Pekka Lahtiharju (Telia Company), Rich Smith (DigiCert), Rollin Yu (TrustAsia), Roman Fischer (SwissSign), Ryan Dickson (Google), Scott Rea (eMudhra), Sean Huang (TWCA), Steven Deitte (GoDaddy), 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))
Begin Recording - Roll Call
Read note-well
Note-well was read by Corey
Grace Cimaszewski was an invited Interested Party to present for the discussion today.
Review of Agenda
No changes in the agenda
Minutes approval
- Draft minutes will be available before the next call.
Topics:
- Regroup on https://github.com/cabforum/servercert/pull/567 (Wayne)
RFC 8657 - Defines two additional parameters for CAA that are specific to the account and validation methods.
Effective dates will need to be talked about.
Want to define consistency in validation methods.
Format of the account URI should be placed in the CP/CPS.
Grace’s amendment proposal:
Trying to cryptographically secure domain validation using CAA records - One way is to make use of RFC 8657 extensions in certain ways, but a flaw was found where if a CA doesn’t implement them, these records could be ignored without any indication. In the BRs today, there is a big aspect missing with existing CA tag parsing which is beyond the basic issue and issue wild tags. No current enforcements of other parameters today; RFC 8657 is an example of this.
Change # 1 (early safety): Don’t implement RFC 8657, not authorization. [September 15, 2026]
Change # 2 (full compliance later): CAs MUST process accounturi and validationmethods as specified in RFC 8657. [September 15, 2027]
Change # 3 (non-ACME CAs already implementing RFC 8657) require CP/CPS disclosure of accounturi format and validationmethods label mapping [September 15, 2026]
Roman - RFC 8657 Usage percentage was requested.
Aaron’s numbers: validationmethods in 1% of CAA records retrieved , accounturi in slightly less than that and overall about 17% of domains processed have CAA records. GTS (Gurleen): We don’t see RFC8657 parameters used much.
Dimitris - Support and timeline is aggressive. What about the criticality of the tag? (Grace - Additional parameters are not enforced by the criticality)
Aaron - Change # 1 - Enforce by policy. Change # 2 - Process it. Jump to Change # 2 and pull in the effective date sooner.
Trev - Combine Change # 1 and # 2 by using a SHOULD and a MUST with two different dates.
Wayne - Make March 2027 a requirement for Change # 2 may be where we are headed with this.
Dimitris - The PR needs to be rebased. Wayne will handle this.
Wayne - Make the effective date March 15, 2027, no-phase in. He will make the changes, get endorsers, and start the discussion period.
- Secure Domain Validation Methods Presentation Notes:
No existing validation method provides end-to-end authenticated challenge retrieval.
Residual Risk in Domain Validation Methods attack surface were presented.
http-01: Plaintext HTTP retrieval of token file
dns-01: Unauthenticated DNS resolution of challenge records may lack authenticated lookup (e.g., non-DNSSEC-signed zone, or CNAME delegation to a validation provided that is unsigned)
tls-alpn-01: Self-signed certificate presented during TLS handshake does not authenticate host identity
Bootstrapping challenge: Authenticated DNS as a trust anchor
Proposal: a new security CAA tag that specifies secure validation methods.
CAs should fail closed. It is backwards compatible with BRs and CAA spec. Enables domain owners to opt-in selectively.
Four Secure-by-design Validation methods are proposed.
Validation Method Secure Anchor
secure-dns-record-change Authenticated DNS resolution [Full authenticated lookup chain required]
http-validation-over-tls Existing Web PKI trust [Bootstrap by valid publicly-trusted certificate]
known-account-specifier Authorized CA account binding [Performed along with a BR approved method]
private-key-control Cryptographic key possession [Strong security properties, but more involved also requires a BR approved method to be completed as well]
Cryptographic Domain Validation Methods are Feasible with minor modifications of existing ACME methods.
1. secure-dns-record-change: Similar to dns-01 but all DNS records are retrieved securely.
2. http-validation-over-tls: Perform regular http-01 validation over port 443 instead and verify certificate validity.
3. known-account-specifier: ACME CAs supporting RFC 8657 accounturi only requires synchronization between CAA retrieval code and validation code.
4. private-key-control: Specify public key in DNS record and perform interactive challenge-response protocol to prove private key ownership.
Research plans next steps.
More through specification of methods, Exact DNS record types and subdomain prefixes and Extension to ACME (RFC 8555) methods.
Welcome any interested parties to collaborate on IETF draft or implementation of secure validation methods.
Toby: This is as vulnerable as what we are already doing.
Grace: Getting SC-85 DNSSEC in place all the security relies on the domain owner to put this in place.
Dimitris: http retrieves information from a known location. When evaluating, we didn’t see a benefit with this since a modification in the middle would fail the validation already.
Trust anchor for http is a challenge for which Root Store to use for this.
Grace: Less from packet changes more about malicious requests with traffic redirection, MPIC helped with this, but still a concern with a globally controlled attack.
Wayne: Thanks to Grace for presenting today. Interested in the methods that CAs could perform in addition to the currently approved BR methods.
More discussion on these topics in the near future.
- Continue discussion on ADN improvement ballot
Aaron: Sent an ADN email to the list to continue the conversation.
Topic will be addressed in the next call.
Next call: Feb 19, 2026
Adjourn