Final minutes for the 2025-09-04 Validation Subcommittee Teleconference
22 views
Skip to first unread message
Corey Bonnell
Sep 18, 2025, 1:05:46 PM (yesterday) Sep 18
to valid...@groups.cabforum.org
These are the Final Minutes of the Teleconference described in the subject of this message, prepared by Dimitris Zacharopoulos (HARICA) and approved at the 2025-09-18 meeting of the Validation Subcommittee.
Validation Subcommittee Teleconference 2025-09-04
# Attendees
Aaron Poulsen (Amazon), Adrian Mueller (SwissSign), Adriano Santoni (Actalis S.p.A.), Ben Wilson (Mozilla), Chris Clements (Google), Clint Wilson (Apple), Corey Bonnell (DigiCert), Corey Rasmussen (OATI), David Kluge (Google), Dimitris Zacharopoulos (HARICA), Doug Beattie (GlobalSign), Henry Birge-Lee (Henry Birge-Lee (Private person)), Iñigo Barreira (Sectigo), Jaime Hablutzel (OISTE Foundation), Janet Hines (VikingCloud), Johnny Reading (GoDaddy), Karina Sirota (Microsoft), Kateryna Aleksieieva (Asseco Data Systems SA (Certum)), 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), Rich Smith (DigiCert), Rollin Yu (TrustAsia), Ryan Dickson (Google), Scott Rea (eMudhra), Sean Huang (TWCA), Shiloh Heurich (Fastly), Steven Deitte (GoDaddy), Sven Rajala (Keyfactor), Tim Callan (Sectigo), Tobias Josefowitz (Opera Software AS), Wayne Thayer (Fastly), Wiktoria Więckowska (Asseco Data Systems SA (Certum)), Yamian Quintero (Microsoft).
# Corey read the note-well
# Agenda
- Walkthrough of ballot sunsetting various “manual” DCV methods
- Persistent IP address validation method
- Discussion of Base Domain Name definition, ADN definition, CNAME, and interplay with specific DCV methods
- DNSSEC checks for email-based DCV methods
# Approval of minutes
- 2025-08-07 Minutes were approved
# 1. Walkthrough of ballot sunsetting various “manual” DCV methods
The ballot draft is available in
https://docs.google.com/document/d/1B7ZwGa-lZRlSJFhzbb5PgXbHAnVFH4-7mKPcXAMmaCo
Ballot SC81 (WHOIS ballot) and some comments from the community drove the creation of this ballot. It was first introduced 8 weeks ago following Henry's report about cross-over attacks in phone and email validation methods. It aligns with Chrome's analysis that these methods are more vulnerable than others. The document describes the scope, justification, timeline and actual ballot text ready for discussion.
- Phone and email methods don't support MPIC
- Binding is not as strong as other methods demonstrating control of infrastructure
Promoting simplicity for CA owners in configurations, auditors having to evaluate and subscriber organizations to adopt.
Bugzilla incident where an MX could be used to issue for any domain. In the incident it was mentioned that method "was not used much". Having less methods would allow more scrutiny in the few acceptable methods.
Important impact but minimizes the overall risks.
The ballot is simple, in fact sunsetting methods.
- March 2026, sunset the IP address method which has cross-over issues identified by Henry.
- March 2027, sunset of phone methods along with fax, sms, postal mail not widely used and less agile methods.
- March 2028, sunset all email methods from less automatable methods in favor of more automation, one year before the 47-day certificates.
Looking for endorsers. In Ryan's view, endorsing does not automatically mean that the endorser will vote "yes", but it means that this ballot is worth to enter into an official discussion. Others may have different interpretations but in any case, endorsers are welcome.
Corey asked whether the static IP method should be a prerequisite before removing the cross-over IP address Domain Validation method.
Ryan responded that he could add the static IP method as part of this ballot. Deprecation of 3.2.2.4.8 could be pushed back in favor of adding a new method to validate based on a static IP address. The new method will land before the sunset of 3.2.2.4.8.
Pekka from Telia: He would like the new static IP method
(https://github.com/slghtr-says/servercert/pull/6/files) before sunset of 3.2.2.4.8.
Tim Callan: Agrees with Ryan that IP address methods should not be valid at the same time, causing additional complexity.
Corey: Prefer to have more but simple ballots so prefers an IP address ballot and then a deprecation/sunset ballot.
# 2. Persistent IP address validation method The language for this method is available in https://github.com/slghtr-says/servercert/pull/6/files along with language for ballot SC088. Eventually it will be separated. It's proposed as new method 3.2.2.5.8.
Uses the reverse zone. Take the IP address, convert it to a Domain Name and then validate as the 3.2.2.4.22.
Henry commented that this method as proposed addresses a lot of the concerns he raised in his previous presentation. It solves some infrastructure issues like the maintenance of reverse DNS zones.
He raised some concerns about not following CNAME/DNAME. These mechanisms "live" within the DNS machinery and would be very strange to configure differently (for example in "Unbound" DNS software). Not sure about the security benefits for this requirement. DNS already has a built-in mechanism for delegation of control which is the NS record.
Even with that language in, one could still delegate control doing _validation-persist IN NS name server that delegation should point to, and there is not way to tell no to follow NS records because that's how DNS works.
Corey also agrees and asked if anyone recalls why this restriction was added. No one answered.
Pekka asked if it is possible to authorize a block of IP addresses instead of a single IP.
Henry asked if tree climbing would do the trick like 2.3.4.in-addr.arpa.
Martijn mentioned that multiple /23 would not work very well.
Corey said that it would not work for classless networks but would be ok for those devisable by 8 like for /24.
Henry wondered if that capability exists with today's methods.
Henry mentioned that the most secure IP block authorization process would be signing an artifact using a RPKI key associated with a specific origin route advertisement.
Ryan: If people feel strongly for this ballot, please endorse by contacting Gurleen.
Slaughter mentioned that SC088 is already 7 days in the discussion period and he will leave it in discussion for a few more days. If people have comments and need more time for discussion, please contact him directly.
# 3. Discussion of Base Domain Name definition, ADN definition, CNAME, and interplay with specific DCV methods
Decided to push for next meeting.
# 4. DNSSEC checks for email-based DCV methods
Decided to push for next meeting.
Adjourn.
Validation Subcommittee Teleconference 2025-09-04
# Attendees
Aaron Poulsen (Amazon), Adrian Mueller (SwissSign), Adriano Santoni (Actalis S.p.A.), Ben Wilson (Mozilla), Chris Clements (Google), Clint Wilson (Apple), Corey Bonnell (DigiCert), Corey Rasmussen (OATI), David Kluge (Google), Dimitris Zacharopoulos (HARICA), Doug Beattie (GlobalSign), Henry Birge-Lee (Henry Birge-Lee (Private person)), Iñigo Barreira (Sectigo), Jaime Hablutzel (OISTE Foundation), Janet Hines (VikingCloud), Johnny Reading (GoDaddy), Karina Sirota (Microsoft), Kateryna Aleksieieva (Asseco Data Systems SA (Certum)), 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), Rich Smith (DigiCert), Rollin Yu (TrustAsia), Ryan Dickson (Google), Scott Rea (eMudhra), Sean Huang (TWCA), Shiloh Heurich (Fastly), Steven Deitte (GoDaddy), Sven Rajala (Keyfactor), Tim Callan (Sectigo), Tobias Josefowitz (Opera Software AS), Wayne Thayer (Fastly), Wiktoria Więckowska (Asseco Data Systems SA (Certum)), Yamian Quintero (Microsoft).
# Corey read the note-well
# Agenda
- Walkthrough of ballot sunsetting various “manual” DCV methods
- Persistent IP address validation method
- Discussion of Base Domain Name definition, ADN definition, CNAME, and interplay with specific DCV methods
- DNSSEC checks for email-based DCV methods
# Approval of minutes
- 2025-08-07 Minutes were approved
# 1. Walkthrough of ballot sunsetting various “manual” DCV methods
The ballot draft is available in
https://docs.google.com/document/d/1B7ZwGa-lZRlSJFhzbb5PgXbHAnVFH4-7mKPcXAMmaCo
Ballot SC81 (WHOIS ballot) and some comments from the community drove the creation of this ballot. It was first introduced 8 weeks ago following Henry's report about cross-over attacks in phone and email validation methods. It aligns with Chrome's analysis that these methods are more vulnerable than others. The document describes the scope, justification, timeline and actual ballot text ready for discussion.
- Phone and email methods don't support MPIC
- Binding is not as strong as other methods demonstrating control of infrastructure
Promoting simplicity for CA owners in configurations, auditors having to evaluate and subscriber organizations to adopt.
Bugzilla incident where an MX could be used to issue for any domain. In the incident it was mentioned that method "was not used much". Having less methods would allow more scrutiny in the few acceptable methods.
Important impact but minimizes the overall risks.
The ballot is simple, in fact sunsetting methods.
- March 2026, sunset the IP address method which has cross-over issues identified by Henry.
- March 2027, sunset of phone methods along with fax, sms, postal mail not widely used and less agile methods.
- March 2028, sunset all email methods from less automatable methods in favor of more automation, one year before the 47-day certificates.
Looking for endorsers. In Ryan's view, endorsing does not automatically mean that the endorser will vote "yes", but it means that this ballot is worth to enter into an official discussion. Others may have different interpretations but in any case, endorsers are welcome.
Corey asked whether the static IP method should be a prerequisite before removing the cross-over IP address Domain Validation method.
Ryan responded that he could add the static IP method as part of this ballot. Deprecation of 3.2.2.4.8 could be pushed back in favor of adding a new method to validate based on a static IP address. The new method will land before the sunset of 3.2.2.4.8.
Pekka from Telia: He would like the new static IP method
(https://github.com/slghtr-says/servercert/pull/6/files) before sunset of 3.2.2.4.8.
Tim Callan: Agrees with Ryan that IP address methods should not be valid at the same time, causing additional complexity.
Corey: Prefer to have more but simple ballots so prefers an IP address ballot and then a deprecation/sunset ballot.
# 2. Persistent IP address validation method The language for this method is available in https://github.com/slghtr-says/servercert/pull/6/files along with language for ballot SC088. Eventually it will be separated. It's proposed as new method 3.2.2.5.8.
Uses the reverse zone. Take the IP address, convert it to a Domain Name and then validate as the 3.2.2.4.22.
Henry commented that this method as proposed addresses a lot of the concerns he raised in his previous presentation. It solves some infrastructure issues like the maintenance of reverse DNS zones.
He raised some concerns about not following CNAME/DNAME. These mechanisms "live" within the DNS machinery and would be very strange to configure differently (for example in "Unbound" DNS software). Not sure about the security benefits for this requirement. DNS already has a built-in mechanism for delegation of control which is the NS record.
Even with that language in, one could still delegate control doing _validation-persist IN NS name server that delegation should point to, and there is not way to tell no to follow NS records because that's how DNS works.
Corey also agrees and asked if anyone recalls why this restriction was added. No one answered.
Pekka asked if it is possible to authorize a block of IP addresses instead of a single IP.
Henry asked if tree climbing would do the trick like 2.3.4.in-addr.arpa.
Martijn mentioned that multiple /23 would not work very well.
Corey said that it would not work for classless networks but would be ok for those devisable by 8 like for /24.
Henry wondered if that capability exists with today's methods.
Henry mentioned that the most secure IP block authorization process would be signing an artifact using a RPKI key associated with a specific origin route advertisement.
Ryan: If people feel strongly for this ballot, please endorse by contacting Gurleen.
Slaughter mentioned that SC088 is already 7 days in the discussion period and he will leave it in discussion for a few more days. If people have comments and need more time for discussion, please contact him directly.
# 3. Discussion of Base Domain Name definition, ADN definition, CNAME, and interplay with specific DCV methods
Decided to push for next meeting.
# 4. DNSSEC checks for email-based DCV methods
Decided to push for next meeting.
Adjourn.
Reply all
Reply to author
Forward
0 new messages