Voting Period Begins - Ballot SC-90: "Gradually sunset all remaining email-based, phone-based, and ‘crossover’ validation methods from Sections 3.2.2.4 and 3.2.2.5"
Ryan Dickson
Purpose of Ballot SC-90:
This ballot proposes updates to the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (TLS BRs) to gradually sunset (1) all remaining email and phone-based domain and IP address validation methods from Sections 3.2.2.4 and 3.2.2.5 and (2) a validation method that enables “crossover” attacks as described by Henry Birge-Lee during the 24 July 2025 Validation Subcommittee Meeting.
Background:
Scope:
The following validation methods are proposed for a gradual sunset:
Methods relying on email and phone:
3.2.2.4.4 ("Constructed Email to Domain Contact")
3.2.2.4.13 ("Email to DNS CAA Contact")
3.2.2.4.14 ("Email to DNS TXT Contact")
3.2.2.4.16 ("Phone Contact with DNS TXT Record Phone Contact")
3.2.2.4.17 ("Phone Contact with DNS CAA Phone Contact")
3.2.2.5.2 ("Email, Fax, SMS, or Postal Mail to IP Address Contact")
3.2.2.5.5 ("Phone Contact with IP Address Contact")
Method that enable crossover attacks:
3.2.2.4.8 (“IP Address”)
Justification:
For sunsetting email and phone-based methods:
The in-scope methods do not offer the stronger security assurances provided by the existing alternative methods currently detailed in the TLS BRs.
For example, while MPIC (Ballot SC-067) can be applied to DNS lookups for email addresses sourced from DNS (e.g., Methods 3.2.2.4.13, 3.2.2.4.14), it does not prevent fraudulent issuance if the MX server's IP or its DNS resolution is hijacked, as the MX server address itself is not part of the MPIC lookup for the domain contact.
An attacker could perform a BGP hijack of the victim's MX server IP or its DNS resolution, serve the legitimate victim email address (which passes MPIC for the contact lookup), and still intercept the validation email.
Similar attacks can target constructed email methods by hijacking the MX server.
Though applying MPIC to MX record lookups would be an improvement to help protect against DNS-based attacks affecting email routing, but it would not protect against in-transit hijacks (e.g., vulnerabilities in SMTP traffic itself like opportunistic TLS downgrades) or post-mail-server delivery compromises (e.g., an attacker gaining unauthorized access to the recipient's mailbox via POP3/IMAP).
Requiring multiple challenges to be sent from multiple addresses could also be considered a security improvement, but would likely work against agility goals and is expected to be undesirable due to subscriber inconvenience.
The ability for email-based DCV methods to reliably satisfy DNSSEC checking expectations introduced by SC-085 is unclear, further emphasizing these methods as a “weak link.” Because of this concern, this ballot discourages use of email-based methods beginning the effective date of SC-085 (March 15, 2026).
The in-scope methods represent an expanded attack surface to publicly-trusted TLS certificate issuance when compared to existing alternatives.
These methods broaden the attack surface compared to “direct” validation methods like DNS TXT records or HTTP file challenges.
Email validation involves a more complex chain of operations, including MX record lookups and resolution of mail server addresses, potentially involving third-party mail providers and their DNS infrastructure. Additional participants in the validation process should be seen as added risk.
Using DNS TXT or CAA records to find a contact email address can introduce further DNS queries, each an additional vector for attack.
Compromise at any point in this extended chain can lead to fraudulent certificate issuance. Direct DNS or HTTP challenges confine the attack surface primarily to the validated domain.
Audits don’t meaningfully or completely evaluate the security of these services, even considering elements hosted directly by the CA subject to the audit’s scope, further calling into question their reliability.
The in-scope methods inherit vulnerabilities from the underlying communication channels and associated service providers.
The compromise of an email service provider (private or public), could potentially grant attackers access to any number of fraudulently issued certificates due to no fault of a CA Owner or subscriber.
There are numerous examples of large-scale attacks on such services and providers. These attacks should be considered as becoming more prevalent, not less.
It is also broadly understood by security professionals that many successful attacks are never publicly disclosed or may go undetected for considerable periods. This established pattern of attacks, combined with the strong and persistent motivations for adversaries to target email systems, makes the continued use of email-based DCV a concern for maintaining the security and integrity of the ecosystem.
Email relies on opportunistic TLS and is susceptible to downgrade. Phone systems share similar inherent vulnerabilities like SIM Swapping and SS7 attacks (example).
As evidenced in the WatchTowr report that motivated the sunset of methods relying on domain contact information via SC-080, vulnerabilities in these communication channels or associated service providers represent significant and convenient collateral impact.
The in-scope methods represent a weaker binding to domain/IP control than existing alternatives.
Email and phone-based DCV methods exhibit a "weak binding" as they only demonstrate that an applicant can interact with a communication medium associated with the domain, not necessarily direct administrative control over the domain's core infrastructure.
Read access to an email inbox (e.g., ad...@example.com) or a phone number does not inherently equate to comprehensive control over DNS configuration, web server content, or policy authority for the domain.
Email accounts are susceptible to compromise, unauthorized and unintended delegation, or mismanagement independently of the domain's core operational control.
We presently have DCV methods (e.g., ACME-based DNS or HTTP challenges) that offer greater automation, scalability, security, and better align with subscriber agility needs, especially when considering decreasing certificate lifetimes. Similarly, the SCWG continues to develop new DCV methods that promote automation, agility, and subscriber convenience (e.g., SC-088).
For sunsetting methods that could be used in “crossover” attacks:
The in-scope methods allow attackers to obtain fraudulent certificates that contain a domain name(s) they do not possess authoritative control.
While the original scope of this ballot included a sunset for 3.2.2.5.3 (“Reverse Address Lookup”), it is instead planned for sunset in SC-091.
Benefits of adoption:
Elevate overall security posture by directly addressing the "Weakest Link Principle" in our domain validation security chain, ensuring attackers cannot leverage less secure methods to compromise certificate issuance. So long as these inherently less secure and more susceptible methods remain available, they present a persistent, exploitable target for adversaries.
Reduce risk of improper certificate issuance by sunsetting a method that enables "crossover" attacks, which are often made possible by IP reassignment, host header vulnerabilities, and reverse DNS vulnerabilities.
Promote stronger validation integrity by ensuring that DCV relies on methods with a stronger binding to actual administrative control over a domain or IP address, increasing the consistency of trustworthiness of issued certificates.
Simplify the threat space by removing phone and email-based DCV, which eliminates unnecessary dependencies on large and complex ecosystems with inherent challenges, risks and vulnerabilities.
Increase agility by encouraging site owners to transition to modern DCV methods, creating opportunities for faster and more efficient certificate lifecycle management through automation.
Create opportunities for innovation by promoting the development of new and improved DCV methods, fostering advancements that may further enhance the overall security and agility of the ecosystem.
Promote simplicity by streamlining the list of approved DCV methods in the TLS BRs, reducing complexity for CAs, developers, auditors, and subscribers.
Proposed Key Dates:
The effective dates considered in this update are intended to allow subscribers and CA Owners relying on existing implementations of these methods to transition to alternatives.
Effective March 15, 2026:
Sunset method 3.2.2.4.8 (“IP Address”)
Discourage use of email and phone-based methods.
Effective March 15, 2027:
Sunset method 3.2.2.4.16 ("Phone Contact with DNS TXT Record Phone Contact")
Sunset method 3.2.2.4.17 ("Phone Contact with DNS CAA Phone Contact")
Sunset method 3.2.2.5.2 ("Email, Fax, SMS, or Postal Mail to IP Address Contact")
Sunset method 3.2.2.5.5 ("Phone Contact with IP Address Contact")
Effective March 15, 2028:
Sunset method 3.2.2.4.4 ("Constructed Email to Domain Contact")
Sunset method 3.2.2.4.13 ("Email to DNS CAA Contact")
Sunset method 3.2.2.4.14 ("Email to DNS TXT Contact")
Proposal Revision History:
Version #1 (this version)
The following motion has been proposed by Ryan Dickson and Chris Clements of Google (Chrome Root Program) and endorsed by Ben Wilson (Mozilla) and Tim Callan (Sectigo).
— Motion Begins —
This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.1.5.
MODIFY the Baseline Requirements as specified in the following Redline:
— Motion Ends —
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (no less than 14 days)
Start: 2025-10-24 11:15:00 ET
End: 2025-11-12 16:14:59 ET
Vote for approval (7 days)
Start: 2025-11-12 16:15:00 ET
End: 2025-11-19 16:15:00 ET
Ben Wilson
--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CADEW5O97dHokb783ZaFVVh-CVbydrw_tjJ0Hf3KD2%2BU745Omfg%40mail.gmail.com.
Romain DELVAL
Certigna votes Yes to SC90
Romain DELVAL
De : 'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Envoyé : mercredi 12 novembre 2025 22:15
À : server...@groups.cabforum.org
Objet : [Servercert-wg] Voting Period Begins - Ballot SC-90: "Gradually sunset all remaining email-based, phone-based, and ‘crossover’ validation methods from Sections 3.2.2.4 and 3.2.2.5"
⚠ FR : Ce message provient de l'extérieur de l'organisation. N'ouvrez pas de liens ou de pièces jointes à moins que vous ne sachiez que le contenu est fiable. ⚠
Purpose of Ballot SC-90:
This ballot proposes updates to the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (TLS BRs) to gradually sunset (1) all remaining email and phone-based domain and IP address validation methods from Sections 3.2.2.4 and 3.2.2.5 and (2) a validation method that enables “crossover” attacks as described by Henry Birge-Lee during the 24 July 2025 Validation Subcommittee Meeting.
Background:
Scope:
The following validation methods are proposed for a gradual sunset:
Methods relying on email and phone:
· 3.2.2.4.4 ("Constructed Email to Domain Contact")
· 3.2.2.4.13 ("Email to DNS CAA Contact")
· 3.2.2.4.14 ("Email to DNS TXT Contact")
· 3.2.2.4.16 ("Phone Contact with DNS TXT Record Phone Contact")
· 3.2.2.4.17 ("Phone Contact with DNS CAA Phone Contact")
· 3.2.2.5.2 ("Email, Fax, SMS, or Postal Mail to IP Address Contact")
· 3.2.2.5.5 ("Phone Contact with IP Address Contact")
Method that enable crossover attacks:
· 3.2.2.4.8 (“IP Address”)
Justification:
For sunsetting email and phone-based methods:
· The in-scope methods do not offer the stronger security assurances provided by the existing alternative methods currently detailed in the TLS BRs.
o For example, while MPIC (Ballot SC-067) can be applied to DNS lookups for email addresses sourced from DNS (e.g., Methods 3.2.2.4.13, 3.2.2.4.14), it does not prevent fraudulent issuance if the MX server's IP or its DNS resolution is hijacked, as the MX server address itself is not part of the MPIC lookup for the domain contact.
· An attacker could perform a BGP hijack of the victim's MX server IP or its DNS resolution, serve the legitimate victim email address (which passes MPIC for the contact lookup), and still intercept the validation email.
· Similar attacks can target constructed email methods by hijacking the MX server.
o Though applying MPIC to MX record lookups would be an improvement to help protect against DNS-based attacks affecting email routing, but it would not protect against in-transit hijacks (e.g., vulnerabilities in SMTP traffic itself like opportunistic TLS downgrades) or post-mail-server delivery compromises (e.g., an attacker gaining unauthorized access to the recipient's mailbox via POP3/IMAP).
o Requiring multiple challenges to be sent from multiple addresses could also be considered a security improvement, but would likely work against agility goals and is expected to be undesirable due to subscriber inconvenience.
o The ability for email-based DCV methods to reliably satisfy DNSSEC checking expectations introduced by SC-085 is unclear, further emphasizing these methods as a “weak link.” Because of this concern, this ballot discourages use of email-based methods beginning the effective date of SC-085 (March 15, 2026).
· The in-scope methods represent an expanded attack surface to publicly-trusted TLS certificate issuance when compared to existing alternatives.
o These methods broaden the attack surface compared to “direct” validation methods like DNS TXT records or HTTP file challenges.
o Email validation involves a more complex chain of operations, including MX record lookups and resolution of mail server addresses, potentially involving third-party mail providers and their DNS infrastructure. Additional participants in the validation process should be seen as added risk.
o Using DNS TXT or CAA records to find a contact email address can introduce further DNS queries, each an additional vector for attack.
o Compromise at any point in this extended chain can lead to fraudulent certificate issuance. Direct DNS or HTTP challenges confine the attack surface primarily to the validated domain.
o Audits don’t meaningfully or completely evaluate the security of these services, even considering elements hosted directly by the CA subject to the audit’s scope, further calling into question their reliability.
· The in-scope methods inherit vulnerabilities from the underlying communication channels and associated service providers.
o The compromise of an email service provider (private or public), could potentially grant attackers access to any number of fraudulently issued certificates due to no fault of a CA Owner or subscriber.
o There are numerous examples of large-scale attacks on such services and providers. These attacks should be considered as becoming more prevalent, not less.
o It is also broadly understood by security professionals that many successful attacks are never publicly disclosed or may go undetected for considerable periods. This established pattern of attacks, combined with the strong and persistent motivations for adversaries to target email systems, makes the continued use of email-based DCV a concern for maintaining the security and integrity of the ecosystem.
o Email relies on opportunistic TLS and is susceptible to downgrade. Phone systems share similar inherent vulnerabilities like SIM Swapping and SS7 attacks (example).
o As evidenced in the WatchTowr report that motivated the sunset of methods relying on domain contact information via SC-080, vulnerabilities in these communication channels or associated service providers represent significant and convenient collateral impact.
· The in-scope methods represent a weaker binding to domain/IP control than existing alternatives.
o Email and phone-based DCV methods exhibit a "weak binding" as they only demonstrate that an applicant can interact with a communication medium associated with the domain, not necessarily direct administrative control over the domain's core infrastructure.
o Read access to an email inbox (e.g., ad...@example.com) or a phone number does not inherently equate to comprehensive control over DNS configuration, web server content, or policy authority for the domain.
o Email accounts are susceptible to compromise, unauthorized and unintended delegation, or mismanagement independently of the domain's core operational control.
· We presently have DCV methods (e.g., ACME-based DNS or HTTP challenges) that offer greater automation, scalability, security, and better align with subscriber agility needs, especially when considering decreasing certificate lifetimes. Similarly, the SCWG continues to develop new DCV methods that promote automation, agility, and subscriber convenience (e.g., SC-088).
For sunsetting methods that could be used in “crossover” attacks:
· The in-scope methods allow attackers to obtain fraudulent certificates that contain a domain name(s) they do not possess authoritative control.
· While the original scope of this ballot included a sunset for 3.2.2.5.3 (“Reverse Address Lookup”), it is instead planned for sunset in SC-091.
Benefits of adoption:
· Elevate overall security posture by directly addressing the "Weakest Link Principle" in our domain validation security chain, ensuring attackers cannot leverage less secure methods to compromise certificate issuance. So long as these inherently less secure and more susceptible methods remain available, they present a persistent, exploitable target for adversaries.
· Reduce risk of improper certificate issuance by sunsetting a method that enables "crossover" attacks, which are often made possible by IP reassignment, host header vulnerabilities, and reverse DNS vulnerabilities.
· Promote stronger validation integrity by ensuring that DCV relies on methods with a stronger binding to actual administrative control over a domain or IP address, increasing the consistency of trustworthiness of issued certificates.
· Simplify the threat space by removing phone and email-based DCV, which eliminates unnecessary dependencies on large and complex ecosystems with inherent challenges, risks and vulnerabilities.
· Increase agility by encouraging site owners to transition to modern DCV methods, creating opportunities for faster and more efficient certificate lifecycle management through automation.
· Create opportunities for innovation by promoting the development of new and improved DCV methods, fostering advancements that may further enhance the overall security and agility of the ecosystem.
· Promote simplicity by streamlining the list of approved DCV methods in the TLS BRs, reducing complexity for CAs, developers, auditors, and subscribers.
Proposed Key Dates:
The effective dates considered in this update are intended to allow subscribers and CA Owners relying on existing implementations of these methods to transition to alternatives.
· Effective March 15, 2026:
o Sunset method 3.2.2.4.8 (“IP Address”)
o Discourage use of email and phone-based methods.
· Effective March 15, 2027:
o Sunset method 3.2.2.4.16 ("Phone Contact with DNS TXT Record Phone Contact")
o Sunset method 3.2.2.4.17 ("Phone Contact with DNS CAA Phone Contact")
o Sunset method 3.2.2.5.2 ("Email, Fax, SMS, or Postal Mail to IP Address Contact")
o Sunset method 3.2.2.5.5 ("Phone Contact with IP Address Contact")
· Effective March 15, 2028:
o Sunset method 3.2.2.4.4 ("Constructed Email to Domain Contact")
o Sunset method 3.2.2.4.13 ("Email to DNS CAA Contact")
o Sunset method 3.2.2.4.14 ("Email to DNS TXT Contact")
Proposal Revision History:
· Version #1 (this version)
The following motion has been proposed by Ryan Dickson and Chris Clements of Google (Chrome Root Program) and endorsed by Ben Wilson (Mozilla) and Tim Callan (Sectigo).
— Motion Begins —
This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.1.5.
MODIFY the Baseline Requirements as specified in the following Redline:
— Motion Ends —
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (no less than 14 days)
· Start: 2025-10-24 11:15:00 ET
· End: 2025-11-12 16:14:59 ET
Vote for approval (7 days)
· Start: 2025-11-12 16:15:00 ET
· End: 2025-11-19 16:15:00 ET
--
Marco Schambach
IdenTrust votes “Yes” on ballot SC-90
Marco S.
TrustID Program Manager
From: 'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Wednesday, November 12, 2025 4:15 PM
To: server...@groups.cabforum.org
Subject: [External][Servercert-wg] Voting Period Begins - Ballot SC-90: "Gradually sunset all remaining email-based, phone-based, and ‘crossover’ validation methods from Sections 3.2.2.4 and 3.2.2.5"
Purpose of Ballot SC-90:
This ballot proposes updates to the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (TLS BRs) to gradually sunset (1) all remaining email and phone-based domain and IP address validation methods from Sections 3.2.2.4 and 3.2.2.5 and (2) a validation method that enables “crossover” attacks as described by Henry Birge-Lee during the 24 July 2025 Validation Subcommittee Meeting.
Background:
Scope:
The following validation methods are proposed for a gradual sunset:
Methods relying on email and phone:
· 3.2.2.4.4 ("Constructed Email to Domain Contact")
· 3.2.2.4.13 ("Email to DNS CAA Contact")
· 3.2.2.4.14 ("Email to DNS TXT Contact")
· 3.2.2.4.16 ("Phone Contact with DNS TXT Record Phone Contact")
· 3.2.2.4.17 ("Phone Contact with DNS CAA Phone Contact")
· 3.2.2.5.2 ("Email, Fax, SMS, or Postal Mail to IP Address Contact")
· 3.2.2.5.5 ("Phone Contact with IP Address Contact")
Method that enable crossover attacks:
· 3.2.2.4.8 (“IP Address”)
Justification:
For sunsetting email and phone-based methods:
· The in-scope methods do not offer the stronger security assurances provided by the existing alternative methods currently detailed in the TLS BRs.
o For example, while MPIC (Ballot SC-067) can be applied to DNS lookups for email addresses sourced from DNS (e.g., Methods 3.2.2.4.13, 3.2.2.4.14), it does not prevent fraudulent issuance if the MX server's IP or its DNS resolution is hijacked, as the MX server address itself is not part of the MPIC lookup for the domain contact.
· An attacker could perform a BGP hijack of the victim's MX server IP or its DNS resolution, serve the legitimate victim email address (which passes MPIC for the contact lookup), and still intercept the validation email.
· Similar attacks can target constructed email methods by hijacking the MX server.
o Though applying MPIC to MX record lookups would be an improvement to help protect against DNS-based attacks affecting email routing, but it would not protect against in-transit hijacks (e.g., vulnerabilities in SMTP traffic itself like opportunistic TLS downgrades) or post-mail-server delivery compromises (e.g., an attacker gaining unauthorized access to the recipient's mailbox via POP3/IMAP).
o Requiring multiple challenges to be sent from multiple addresses could also be considered a security improvement, but would likely work against agility goals and is expected to be undesirable due to subscriber inconvenience.
o The ability for email-based DCV methods to reliably satisfy DNSSEC checking expectations introduced by SC-085 is unclear, further emphasizing these methods as a “weak link.” Because of this concern, this ballot discourages use of email-based methods beginning the effective date of SC-085 (March 15, 2026).
· The in-scope methods represent an expanded attack surface to publicly-trusted TLS certificate issuance when compared to existing alternatives.
o These methods broaden the attack surface compared to “direct” validation methods like DNS TXT records or HTTP file challenges.
o Email validation involves a more complex chain of operations, including MX record lookups and resolution of mail server addresses, potentially involving third-party mail providers and their DNS infrastructure. Additional participants in the validation process should be seen as added risk.
o Using DNS TXT or CAA records to find a contact email address can introduce further DNS queries, each an additional vector for attack.
o Compromise at any point in this extended chain can lead to fraudulent certificate issuance. Direct DNS or HTTP challenges confine the attack surface primarily to the validated domain.
o Audits don’t meaningfully or completely evaluate the security of these services, even considering elements hosted directly by the CA subject to the audit’s scope, further calling into question their reliability.
· The in-scope methods inherit vulnerabilities from the underlying communication channels and associated service providers.
o The compromise of an email service provider (private or public), could potentially grant attackers access to any number of fraudulently issued certificates due to no fault of a CA Owner or subscriber.
o There are numerous examples of large-scale attacks on such services and providers. These attacks should be considered as becoming more prevalent, not less.
o It is also broadly understood by security professionals that many successful attacks are never publicly disclosed or may go undetected for considerable periods. This established pattern of attacks, combined with the strong and persistent motivations for adversaries to target email systems, makes the continued use of email-based DCV a concern for maintaining the security and integrity of the ecosystem.
o Email relies on opportunistic TLS and is susceptible to downgrade. Phone systems share similar inherent vulnerabilities like SIM Swapping and SS7 attacks (example).
o As evidenced in the WatchTowr report that motivated the sunset of methods relying on domain contact information via SC-080, vulnerabilities in these communication channels or associated service providers represent significant and convenient collateral impact.
· The in-scope methods represent a weaker binding to domain/IP control than existing alternatives.
o Email and phone-based DCV methods exhibit a "weak binding" as they only demonstrate that an applicant can interact with a communication medium associated with the domain, not necessarily direct administrative control over the domain's core infrastructure.
o Read access to an email inbox (e.g., ad...@example.com) or a phone number does not inherently equate to comprehensive control over DNS configuration, web server content, or policy authority for the domain.
o Email accounts are susceptible to compromise, unauthorized and unintended delegation, or mismanagement independently of the domain's core operational control.
· We presently have DCV methods (e.g., ACME-based DNS or HTTP challenges) that offer greater automation, scalability, security, and better align with subscriber agility needs, especially when considering decreasing certificate lifetimes. Similarly, the SCWG continues to develop new DCV methods that promote automation, agility, and subscriber convenience (e.g., SC-088).
For sunsetting methods that could be used in “crossover” attacks:
· The in-scope methods allow attackers to obtain fraudulent certificates that contain a domain name(s) they do not possess authoritative control.
· While the original scope of this ballot included a sunset for 3.2.2.5.3 (“Reverse Address Lookup”), it is instead planned for sunset in SC-091.
Benefits of adoption:
· Elevate overall security posture by directly addressing the "Weakest Link Principle" in our domain validation security chain, ensuring attackers cannot leverage less secure methods to compromise certificate issuance. So long as these inherently less secure and more susceptible methods remain available, they present a persistent, exploitable target for adversaries.
· Reduce risk of improper certificate issuance by sunsetting a method that enables "crossover" attacks, which are often made possible by IP reassignment, host header vulnerabilities, and reverse DNS vulnerabilities.
· Promote stronger validation integrity by ensuring that DCV relies on methods with a stronger binding to actual administrative control over a domain or IP address, increasing the consistency of trustworthiness of issued certificates.
· Simplify the threat space by removing phone and email-based DCV, which eliminates unnecessary dependencies on large and complex ecosystems with inherent challenges, risks and vulnerabilities.
· Increase agility by encouraging site owners to transition to modern DCV methods, creating opportunities for faster and more efficient certificate lifecycle management through automation.
· Create opportunities for innovation by promoting the development of new and improved DCV methods, fostering advancements that may further enhance the overall security and agility of the ecosystem.
· Promote simplicity by streamlining the list of approved DCV methods in the TLS BRs, reducing complexity for CAs, developers, auditors, and subscribers.
Proposed Key Dates:
The effective dates considered in this update are intended to allow subscribers and CA Owners relying on existing implementations of these methods to transition to alternatives.
· Effective March 15, 2026:
o Sunset method 3.2.2.4.8 (“IP Address”)
o Discourage use of email and phone-based methods.
· Effective March 15, 2027:
o Sunset method 3.2.2.4.16 ("Phone Contact with DNS TXT Record Phone Contact")
o Sunset method 3.2.2.4.17 ("Phone Contact with DNS CAA Phone Contact")
o Sunset method 3.2.2.5.2 ("Email, Fax, SMS, or Postal Mail to IP Address Contact")
o Sunset method 3.2.2.5.5 ("Phone Contact with IP Address Contact")
· Effective March 15, 2028:
o Sunset method 3.2.2.4.4 ("Constructed Email to Domain Contact")
o Sunset method 3.2.2.4.13 ("Email to DNS CAA Contact")
o Sunset method 3.2.2.4.14 ("Email to DNS TXT Contact")
Proposal Revision History:
· Version #1 (this version)
The following motion has been proposed by Ryan Dickson and Chris Clements of Google (Chrome Root Program) and endorsed by Ben Wilson (Mozilla) and Tim Callan (Sectigo).
— Motion Begins —
This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.1.5.
MODIFY the Baseline Requirements as specified in the following Redline:
— Motion Ends —
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (no less than 14 days)
· Start: 2025-10-24 11:15:00 ET
· End: 2025-11-12 16:14:59 ET
Vote for approval (7 days)
· Start: 2025-11-12 16:15:00 ET
· End: 2025-11-19 16:15:00 ET
--
黃晟(orca)
TWCA votes “Yes” on ballot SC-90.
Regards,
Sean Huang
Senior R&D Engineer
TEL：02-2370-8886#728
FAX：02-2388-6720
Email：or...@twca.com.tw
10F., No. 85, Yanping South Road,
Taipei, Taiwan (R.O.C.)
From: 'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Thursday, November 13, 2025 5:15 AM
To: server...@groups.cabforum.org
Subject: [Servercert-wg] Voting Period Begins - Ballot SC-90: "Gradually sunset all remaining email-based, phone-based, and ‘crossover’ validation methods from Sections 3.2.2.4 and 3.2.2.5"
Purpose of Ballot SC-90:
This ballot proposes updates to the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (TLS BRs) to gradually sunset (1) all remaining email and phone-based domain and IP address validation methods from Sections 3.2.2.4 and 3.2.2.5 and (2) a validation method that enables “crossover” attacks as described by Henry Birge-Lee during the 24 July 2025 Validation Subcommittee Meeting.
Background:
Scope:
The following validation methods are proposed for a gradual sunset:
Methods relying on email and phone:
· 3.2.2.4.4 ("Constructed Email to Domain Contact")
· 3.2.2.4.13 ("Email to DNS CAA Contact")
· 3.2.2.4.14 ("Email to DNS TXT Contact")
· 3.2.2.4.16 ("Phone Contact with DNS TXT Record Phone Contact")
· 3.2.2.4.17 ("Phone Contact with DNS CAA Phone Contact")
· 3.2.2.5.2 ("Email, Fax, SMS, or Postal Mail to IP Address Contact")
· 3.2.2.5.5 ("Phone Contact with IP Address Contact")
Method that enable crossover attacks:
· 3.2.2.4.8 (“IP Address”)
Justification:
For sunsetting email and phone-based methods:
· The in-scope methods do not offer the stronger security assurances provided by the existing alternative methods currently detailed in the TLS BRs.
o For example, while MPIC (Ballot SC-067) can be applied to DNS lookups for email addresses sourced from DNS (e.g., Methods 3.2.2.4.13, 3.2.2.4.14), it does not prevent fraudulent issuance if the MX server's IP or its DNS resolution is hijacked, as the MX server address itself is not part of the MPIC lookup for the domain contact.
· An attacker could perform a BGP hijack of the victim's MX server IP or its DNS resolution, serve the legitimate victim email address (which passes MPIC for the contact lookup), and still intercept the validation email.
· Similar attacks can target constructed email methods by hijacking the MX server.
o Though applying MPIC to MX record lookups would be an improvement to help protect against DNS-based attacks affecting email routing, but it would not protect against in-transit hijacks (e.g., vulnerabilities in SMTP traffic itself like opportunistic TLS downgrades) or post-mail-server delivery compromises (e.g., an attacker gaining unauthorized access to the recipient's mailbox via POP3/IMAP).
o Requiring multiple challenges to be sent from multiple addresses could also be considered a security improvement, but would likely work against agility goals and is expected to be undesirable due to subscriber inconvenience.
o The ability for email-based DCV methods to reliably satisfy DNSSEC checking expectations introduced by SC-085 is unclear, further emphasizing these methods as a “weak link.” Because of this concern, this ballot discourages use of email-based methods beginning the effective date of SC-085 (March 15, 2026).
· The in-scope methods represent an expanded attack surface to publicly-trusted TLS certificate issuance when compared to existing alternatives.
o These methods broaden the attack surface compared to “direct” validation methods like DNS TXT records or HTTP file challenges.
o Email validation involves a more complex chain of operations, including MX record lookups and resolution of mail server addresses, potentially involving third-party mail providers and their DNS infrastructure. Additional participants in the validation process should be seen as added risk.
o Using DNS TXT or CAA records to find a contact email address can introduce further DNS queries, each an additional vector for attack.
o Compromise at any point in this extended chain can lead to fraudulent certificate issuance. Direct DNS or HTTP challenges confine the attack surface primarily to the validated domain.
o Audits don’t meaningfully or completely evaluate the security of these services, even considering elements hosted directly by the CA subject to the audit’s scope, further calling into question their reliability.
· The in-scope methods inherit vulnerabilities from the underlying communication channels and associated service providers.
o The compromise of an email service provider (private or public), could potentially grant attackers access to any number of fraudulently issued certificates due to no fault of a CA Owner or subscriber.
o There are numerous examples of large-scale attacks on such services and providers. These attacks should be considered as becoming more prevalent, not less.
o It is also broadly understood by security professionals that many successful attacks are never publicly disclosed or may go undetected for considerable periods. This established pattern of attacks, combined with the strong and persistent motivations for adversaries to target email systems, makes the continued use of email-based DCV a concern for maintaining the security and integrity of the ecosystem.
o Email relies on opportunistic TLS and is susceptible to downgrade. Phone systems share similar inherent vulnerabilities like SIM Swapping and SS7 attacks (example).
o As evidenced in the WatchTowr report that motivated the sunset of methods relying on domain contact information via SC-080, vulnerabilities in these communication channels or associated service providers represent significant and convenient collateral impact.
· The in-scope methods represent a weaker binding to domain/IP control than existing alternatives.
o Email and phone-based DCV methods exhibit a "weak binding" as they only demonstrate that an applicant can interact with a communication medium associated with the domain, not necessarily direct administrative control over the domain's core infrastructure.
o Read access to an email inbox (e.g., ad...@example.com) or a phone number does not inherently equate to comprehensive control over DNS configuration, web server content, or policy authority for the domain.
o Email accounts are susceptible to compromise, unauthorized and unintended delegation, or mismanagement independently of the domain's core operational control.
· We presently have DCV methods (e.g., ACME-based DNS or HTTP challenges) that offer greater automation, scalability, security, and better align with subscriber agility needs, especially when considering decreasing certificate lifetimes. Similarly, the SCWG continues to develop new DCV methods that promote automation, agility, and subscriber convenience (e.g., SC-088).
For sunsetting methods that could be used in “crossover” attacks:
· The in-scope methods allow attackers to obtain fraudulent certificates that contain a domain name(s) they do not possess authoritative control.
· While the original scope of this ballot included a sunset for 3.2.2.5.3 (“Reverse Address Lookup”), it is instead planned for sunset in SC-091.
Benefits of adoption:
· Elevate overall security posture by directly addressing the "Weakest Link Principle" in our domain validation security chain, ensuring attackers cannot leverage less secure methods to compromise certificate issuance. So long as these inherently less secure and more susceptible methods remain available, they present a persistent, exploitable target for adversaries.
· Reduce risk of improper certificate issuance by sunsetting a method that enables "crossover" attacks, which are often made possible by IP reassignment, host header vulnerabilities, and reverse DNS vulnerabilities.
· Promote stronger validation integrity by ensuring that DCV relies on methods with a stronger binding to actual administrative control over a domain or IP address, increasing the consistency of trustworthiness of issued certificates.
· Simplify the threat space by removing phone and email-based DCV, which eliminates unnecessary dependencies on large and complex ecosystems with inherent challenges, risks and vulnerabilities.
· Increase agility by encouraging site owners to transition to modern DCV methods, creating opportunities for faster and more efficient certificate lifecycle management through automation.
· Create opportunities for innovation by promoting the development of new and improved DCV methods, fostering advancements that may further enhance the overall security and agility of the ecosystem.
· Promote simplicity by streamlining the list of approved DCV methods in the TLS BRs, reducing complexity for CAs, developers, auditors, and subscribers.
Proposed Key Dates:
The effective dates considered in this update are intended to allow subscribers and CA Owners relying on existing implementations of these methods to transition to alternatives.
· Effective March 15, 2026:
o Sunset method 3.2.2.4.8 (“IP Address”)
o Discourage use of email and phone-based methods.
· Effective March 15, 2027:
o Sunset method 3.2.2.4.16 ("Phone Contact with DNS TXT Record Phone Contact")
o Sunset method 3.2.2.4.17 ("Phone Contact with DNS CAA Phone Contact")
o Sunset method 3.2.2.5.2 ("Email, Fax, SMS, or Postal Mail to IP Address Contact")
o Sunset method 3.2.2.5.5 ("Phone Contact with IP Address Contact")
· Effective March 15, 2028:
o Sunset method 3.2.2.4.4 ("Constructed Email to Domain Contact")
o Sunset method 3.2.2.4.13 ("Email to DNS CAA Contact")
o Sunset method 3.2.2.4.14 ("Email to DNS TXT Contact")
Proposal Revision History:
· Version #1 (this version)
The following motion has been proposed by Ryan Dickson and Chris Clements of Google (Chrome Root Program) and endorsed by Ben Wilson (Mozilla) and Tim Callan (Sectigo).
— Motion Begins —
This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.1.5.
MODIFY the Baseline Requirements as specified in the following Redline:
— Motion Ends —
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (no less than 14 days)
· Start: 2025-10-24 11:15:00 ET
· End: 2025-11-12 16:14:59 ET
Vote for approval (7 days)
· Start: 2025-11-12 16:15:00 ET
· End: 2025-11-19 16:15:00 ET
--
Tom Zermeno
Dustin Hollenback
Wayne Thayer
--
Alvin Wang
Hogeun Yoo
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CADEW5O97dHokb783ZaFVVh-CVbydrw_tjJ0Hf3KD2%2BU745Omfg%40mail.gmail.com.
Nome Huang
Tom Zermeno
SSL.com votes “Yes” on SC-90.
From: 'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Wednesday, November 12, 2025 3:15 PM
To: server...@groups.cabforum.org
Subject: [Servercert-wg] Voting Period Begins - Ballot SC-90: "Gradually sunset all remaining email-based, phone-based, and ‘crossover’ validation methods from Sections 3.2.2.4 and 3.2.2.5"
Purpose of Ballot SC-90:
This ballot proposes updates to the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (TLS BRs) to gradually sunset (1) all remaining email and phone-based domain and IP address validation methods from Sections 3.2.2.4 and 3.2.2.5 and (2) a validation method that enables “crossover” attacks as described by Henry Birge-Lee during the 24 July 2025 Validation Subcommittee Meeting.
Background:
Scope:
The following validation methods are proposed for a gradual sunset:
Methods relying on email and phone:
· 3.2.2.4.4 ("Constructed Email to Domain Contact")
· 3.2.2.4.13 ("Email to DNS CAA Contact")
· 3.2.2.4.14 ("Email to DNS TXT Contact")
· 3.2.2.4.16 ("Phone Contact with DNS TXT Record Phone Contact")
· 3.2.2.4.17 ("Phone Contact with DNS CAA Phone Contact")
· 3.2.2.5.2 ("Email, Fax, SMS, or Postal Mail to IP Address Contact")
· 3.2.2.5.5 ("Phone Contact with IP Address Contact")
Method that enable crossover attacks:
· 3.2.2.4.8 (“IP Address”)
Justification:
For sunsetting email and phone-based methods:
· The in-scope methods do not offer the stronger security assurances provided by the existing alternative methods currently detailed in the TLS BRs.
o For example, while MPIC (Ballot SC-067) can be applied to DNS lookups for email addresses sourced from DNS (e.g., Methods 3.2.2.4.13, 3.2.2.4.14), it does not prevent fraudulent issuance if the MX server's IP or its DNS resolution is hijacked, as the MX server address itself is not part of the MPIC lookup for the domain contact.
· An attacker could perform a BGP hijack of the victim's MX server IP or its DNS resolution, serve the legitimate victim email address (which passes MPIC for the contact lookup), and still intercept the validation email.
· Similar attacks can target constructed email methods by hijacking the MX server.
o Though applying MPIC to MX record lookups would be an improvement to help protect against DNS-based attacks affecting email routing, but it would not protect against in-transit hijacks (e.g., vulnerabilities in SMTP traffic itself like opportunistic TLS downgrades) or post-mail-server delivery compromises (e.g., an attacker gaining unauthorized access to the recipient's mailbox via POP3/IMAP).
o Requiring multiple challenges to be sent from multiple addresses could also be considered a security improvement, but would likely work against agility goals and is expected to be undesirable due to subscriber inconvenience.
o The ability for email-based DCV methods to reliably satisfy DNSSEC checking expectations introduced by SC-085 is unclear, further emphasizing these methods as a “weak link.” Because of this concern, this ballot discourages use of email-based methods beginning the effective date of SC-085 (March 15, 2026).
· The in-scope methods represent an expanded attack surface to publicly-trusted TLS certificate issuance when compared to existing alternatives.
o These methods broaden the attack surface compared to “direct” validation methods like DNS TXT records or HTTP file challenges.
o Email validation involves a more complex chain of operations, including MX record lookups and resolution of mail server addresses, potentially involving third-party mail providers and their DNS infrastructure. Additional participants in the validation process should be seen as added risk.
o Using DNS TXT or CAA records to find a contact email address can introduce further DNS queries, each an additional vector for attack.
o Compromise at any point in this extended chain can lead to fraudulent certificate issuance. Direct DNS or HTTP challenges confine the attack surface primarily to the validated domain.
o Audits don’t meaningfully or completely evaluate the security of these services, even considering elements hosted directly by the CA subject to the audit’s scope, further calling into question their reliability.
· The in-scope methods inherit vulnerabilities from the underlying communication channels and associated service providers.
o The compromise of an email service provider (private or public), could potentially grant attackers access to any number of fraudulently issued certificates due to no fault of a CA Owner or subscriber.
o There are numerous examples of large-scale attacks on such services and providers. These attacks should be considered as becoming more prevalent, not less.
o It is also broadly understood by security professionals that many successful attacks are never publicly disclosed or may go undetected for considerable periods. This established pattern of attacks, combined with the strong and persistent motivations for adversaries to target email systems, makes the continued use of email-based DCV a concern for maintaining the security and integrity of the ecosystem.
o Email relies on opportunistic TLS and is susceptible to downgrade. Phone systems share similar inherent vulnerabilities like SIM Swapping and SS7 attacks (example).
o As evidenced in the WatchTowr report that motivated the sunset of methods relying on domain contact information via SC-080, vulnerabilities in these communication channels or associated service providers represent significant and convenient collateral impact.
· The in-scope methods represent a weaker binding to domain/IP control than existing alternatives.
o Email and phone-based DCV methods exhibit a "weak binding" as they only demonstrate that an applicant can interact with a communication medium associated with the domain, not necessarily direct administrative control over the domain's core infrastructure.
o Read access to an email inbox (e.g., ad...@example.com) or a phone number does not inherently equate to comprehensive control over DNS configuration, web server content, or policy authority for the domain.
o Email accounts are susceptible to compromise, unauthorized and unintended delegation, or mismanagement independently of the domain's core operational control.
· We presently have DCV methods (e.g., ACME-based DNS or HTTP challenges) that offer greater automation, scalability, security, and better align with subscriber agility needs, especially when considering decreasing certificate lifetimes. Similarly, the SCWG continues to develop new DCV methods that promote automation, agility, and subscriber convenience (e.g., SC-088).
For sunsetting methods that could be used in “crossover” attacks:
· The in-scope methods allow attackers to obtain fraudulent certificates that contain a domain name(s) they do not possess authoritative control.
· While the original scope of this ballot included a sunset for 3.2.2.5.3 (“Reverse Address Lookup”), it is instead planned for sunset in SC-091.
Benefits of adoption:
· Elevate overall security posture by directly addressing the "Weakest Link Principle" in our domain validation security chain, ensuring attackers cannot leverage less secure methods to compromise certificate issuance. So long as these inherently less secure and more susceptible methods remain available, they present a persistent, exploitable target for adversaries.
· Reduce risk of improper certificate issuance by sunsetting a method that enables "crossover" attacks, which are often made possible by IP reassignment, host header vulnerabilities, and reverse DNS vulnerabilities.
· Promote stronger validation integrity by ensuring that DCV relies on methods with a stronger binding to actual administrative control over a domain or IP address, increasing the consistency of trustworthiness of issued certificates.
· Simplify the threat space by removing phone and email-based DCV, which eliminates unnecessary dependencies on large and complex ecosystems with inherent challenges, risks and vulnerabilities.
· Increase agility by encouraging site owners to transition to modern DCV methods, creating opportunities for faster and more efficient certificate lifecycle management through automation.
· Create opportunities for innovation by promoting the development of new and improved DCV methods, fostering advancements that may further enhance the overall security and agility of the ecosystem.
· Promote simplicity by streamlining the list of approved DCV methods in the TLS BRs, reducing complexity for CAs, developers, auditors, and subscribers.
Proposed Key Dates:
The effective dates considered in this update are intended to allow subscribers and CA Owners relying on existing implementations of these methods to transition to alternatives.
· Effective March 15, 2026:
o Sunset method 3.2.2.4.8 (“IP Address”)
o Discourage use of email and phone-based methods.
· Effective March 15, 2027:
o Sunset method 3.2.2.4.16 ("Phone Contact with DNS TXT Record Phone Contact")
o Sunset method 3.2.2.4.17 ("Phone Contact with DNS CAA Phone Contact")
o Sunset method 3.2.2.5.2 ("Email, Fax, SMS, or Postal Mail to IP Address Contact")
o Sunset method 3.2.2.5.5 ("Phone Contact with IP Address Contact")
· Effective March 15, 2028:
o Sunset method 3.2.2.4.4 ("Constructed Email to Domain Contact")
o Sunset method 3.2.2.4.13 ("Email to DNS CAA Contact")
o Sunset method 3.2.2.4.14 ("Email to DNS TXT Contact")
Proposal Revision History:
· Version #1 (this version)
The following motion has been proposed by Ryan Dickson and Chris Clements of Google (Chrome Root Program) and endorsed by Ben Wilson (Mozilla) and Tim Callan (Sectigo).
— Motion Begins —
This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.1.5.
MODIFY the Baseline Requirements as specified in the following Redline:
— Motion Ends —
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (no less than 14 days)
· Start: 2025-10-24 11:15:00 ET
· End: 2025-11-12 16:14:59 ET
Vote for approval (7 days)
· Start: 2025-11-12 16:15:00 ET
· End: 2025-11-19 16:15:00 ET
--
Adrian Mueller
SwissSign votes Yes on ballot SC-90.
Best regards
Adrian
From: 'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Wednesday, November 12, 2025 10:15 PM
To: server...@groups.cabforum.org
Subject: [Servercert-wg] Voting Period Begins - Ballot SC-90: "Gradually sunset all remaining email-based, phone-based, and ‘crossover’ validation methods from Sections 3.2.2.4 and 3.2.2.5"
Purpose of Ballot SC-90:
This ballot proposes updates to the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (TLS BRs) to gradually sunset (1) all remaining email and phone-based domain and IP address validation methods from Sections 3.2.2.4 and 3.2.2.5 and (2) a validation method that enables “crossover” attacks as described by Henry Birge-Lee during the 24 July 2025 Validation Subcommittee Meeting.
Background:
Scope:
The following validation methods are proposed for a gradual sunset:
Methods relying on email and phone:
· 3.2.2.4.4 ("Constructed Email to Domain Contact")
· 3.2.2.4.13 ("Email to DNS CAA Contact")
· 3.2.2.4.14 ("Email to DNS TXT Contact")
· 3.2.2.4.16 ("Phone Contact with DNS TXT Record Phone Contact")
· 3.2.2.4.17 ("Phone Contact with DNS CAA Phone Contact")
· 3.2.2.5.2 ("Email, Fax, SMS, or Postal Mail to IP Address Contact")
· 3.2.2.5.5 ("Phone Contact with IP Address Contact")
Method that enable crossover attacks:
· 3.2.2.4.8 (“IP Address”)
Justification:
For sunsetting email and phone-based methods:
· The in-scope methods do not offer the stronger security assurances provided by the existing alternative methods currently detailed in the TLS BRs.
o For example, while MPIC (Ballot SC-067) can be applied to DNS lookups for email addresses sourced from DNS (e.g., Methods 3.2.2.4.13, 3.2.2.4.14), it does not prevent fraudulent issuance if the MX server's IP or its DNS resolution is hijacked, as the MX server address itself is not part of the MPIC lookup for the domain contact.
· An attacker could perform a BGP hijack of the victim's MX server IP or its DNS resolution, serve the legitimate victim email address (which passes MPIC for the contact lookup), and still intercept the validation email.
· Similar attacks can target constructed email methods by hijacking the MX server.
o Though applying MPIC to MX record lookups would be an improvement to help protect against DNS-based attacks affecting email routing, but it would not protect against in-transit hijacks (e.g., vulnerabilities in SMTP traffic itself like opportunistic TLS downgrades) or post-mail-server delivery compromises (e.g., an attacker gaining unauthorized access to the recipient's mailbox via POP3/IMAP).
o Requiring multiple challenges to be sent from multiple addresses could also be considered a security improvement, but would likely work against agility goals and is expected to be undesirable due to subscriber inconvenience.
o The ability for email-based DCV methods to reliably satisfy DNSSEC checking expectations introduced by SC-085 is unclear, further emphasizing these methods as a “weak link.” Because of this concern, this ballot discourages use of email-based methods beginning the effective date of SC-085 (March 15, 2026).
· The in-scope methods represent an expanded attack surface to publicly-trusted TLS certificate issuance when compared to existing alternatives.
o These methods broaden the attack surface compared to “direct” validation methods like DNS TXT records or HTTP file challenges.
o Email validation involves a more complex chain of operations, including MX record lookups and resolution of mail server addresses, potentially involving third-party mail providers and their DNS infrastructure. Additional participants in the validation process should be seen as added risk.
o Using DNS TXT or CAA records to find a contact email address can introduce further DNS queries, each an additional vector for attack.
o Compromise at any point in this extended chain can lead to fraudulent certificate issuance. Direct DNS or HTTP challenges confine the attack surface primarily to the validated domain.
o Audits don’t meaningfully or completely evaluate the security of these services, even considering elements hosted directly by the CA subject to the audit’s scope, further calling into question their reliability.
· The in-scope methods inherit vulnerabilities from the underlying communication channels and associated service providers.
o The compromise of an email service provider (private or public), could potentially grant attackers access to any number of fraudulently issued certificates due to no fault of a CA Owner or subscriber.
o There are numerous examples of large-scale attacks on such services and providers. These attacks should be considered as becoming more prevalent, not less.
o It is also broadly understood by security professionals that many successful attacks are never publicly disclosed or may go undetected for considerable periods. This established pattern of attacks, combined with the strong and persistent motivations for adversaries to target email systems, makes the continued use of email-based DCV a concern for maintaining the security and integrity of the ecosystem.
o Email relies on opportunistic TLS and is susceptible to downgrade. Phone systems share similar inherent vulnerabilities like SIM Swapping and SS7 attacks (example).
o As evidenced in the WatchTowr report that motivated the sunset of methods relying on domain contact information via SC-080, vulnerabilities in these communication channels or associated service providers represent significant and convenient collateral impact.
· The in-scope methods represent a weaker binding to domain/IP control than existing alternatives.
o Email and phone-based DCV methods exhibit a "weak binding" as they only demonstrate that an applicant can interact with a communication medium associated with the domain, not necessarily direct administrative control over the domain's core infrastructure.
o Read access to an email inbox (e.g., ad...@example.com) or a phone number does not inherently equate to comprehensive control over DNS configuration, web server content, or policy authority for the domain.
o Email accounts are susceptible to compromise, unauthorized and unintended delegation, or mismanagement independently of the domain's core operational control.
· We presently have DCV methods (e.g., ACME-based DNS or HTTP challenges) that offer greater automation, scalability, security, and better align with subscriber agility needs, especially when considering decreasing certificate lifetimes. Similarly, the SCWG continues to develop new DCV methods that promote automation, agility, and subscriber convenience (e.g., SC-088).
For sunsetting methods that could be used in “crossover” attacks:
· The in-scope methods allow attackers to obtain fraudulent certificates that contain a domain name(s) they do not possess authoritative control.
· While the original scope of this ballot included a sunset for 3.2.2.5.3 (“Reverse Address Lookup”), it is instead planned for sunset in SC-091.
Benefits of adoption:
· Elevate overall security posture by directly addressing the "Weakest Link Principle" in our domain validation security chain, ensuring attackers cannot leverage less secure methods to compromise certificate issuance. So long as these inherently less secure and more susceptible methods remain available, they present a persistent, exploitable target for adversaries.
· Reduce risk of improper certificate issuance by sunsetting a method that enables "crossover" attacks, which are often made possible by IP reassignment, host header vulnerabilities, and reverse DNS vulnerabilities.
· Promote stronger validation integrity by ensuring that DCV relies on methods with a stronger binding to actual administrative control over a domain or IP address, increasing the consistency of trustworthiness of issued certificates.
· Simplify the threat space by removing phone and email-based DCV, which eliminates unnecessary dependencies on large and complex ecosystems with inherent challenges, risks and vulnerabilities.
· Increase agility by encouraging site owners to transition to modern DCV methods, creating opportunities for faster and more efficient certificate lifecycle management through automation.
· Create opportunities for innovation by promoting the development of new and improved DCV methods, fostering advancements that may further enhance the overall security and agility of the ecosystem.
· Promote simplicity by streamlining the list of approved DCV methods in the TLS BRs, reducing complexity for CAs, developers, auditors, and subscribers.
Proposed Key Dates:
The effective dates considered in this update are intended to allow subscribers and CA Owners relying on existing implementations of these methods to transition to alternatives.
· Effective March 15, 2026:
o Sunset method 3.2.2.4.8 (“IP Address”)
o Discourage use of email and phone-based methods.
· Effective March 15, 2027:
o Sunset method 3.2.2.4.16 ("Phone Contact with DNS TXT Record Phone Contact")
o Sunset method 3.2.2.4.17 ("Phone Contact with DNS CAA Phone Contact")
o Sunset method 3.2.2.5.2 ("Email, Fax, SMS, or Postal Mail to IP Address Contact")
o Sunset method 3.2.2.5.5 ("Phone Contact with IP Address Contact")
· Effective March 15, 2028:
o Sunset method 3.2.2.4.4 ("Constructed Email to Domain Contact")
o Sunset method 3.2.2.4.13 ("Email to DNS CAA Contact")
o Sunset method 3.2.2.4.14 ("Email to DNS TXT Contact")
Proposal Revision History:
· Version #1 (this version)
The following motion has been proposed by Ryan Dickson and Chris Clements of Google (Chrome Root Program) and endorsed by Ben Wilson (Mozilla) and Tim Callan (Sectigo).
— Motion Begins —
This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.1.5.
MODIFY the Baseline Requirements as specified in the following Redline:
— Motion Ends —
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (no less than 14 days)
· Start: 2025-10-24 11:15:00 ET
· End: 2025-11-12 16:14:59 ET
Vote for approval (7 days)
· Start: 2025-11-12 16:15:00 ET
· End: 2025-11-19 16:15:00 ET
--
Chris Clements
Martijn Katerbarg
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Subject: [Servercert-wg] Voting Period Begins - Ballot SC-90: "Gradually sunset all remaining email-based, phone-based, and ‘crossover’ validation methods from Sections 3.2.2.4 and 3.2.2.5"
sde...@godaddy.com
GoDaddy votes Yes on Ballot SC-90.
Cheers,
Steven Deitte
From:
'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Date: Wednesday, November 12, 2025 at 4:19
PM
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Subject: [Servercert-wg] Voting Period Begins - Ballot SC-90: "Gradually sunset all remaining email-based, phone-based, and ‘crossover’ validation methods from Sections 3.2.2.4 and 3.2.2.5"
Purpose of Ballot SC-90: This ballot proposes updates to the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (TLS BRs) to gradually sunset (1) all remaining email and phone-based domain and IP
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
Purpose of Ballot SC-90:
This ballot proposes updates to the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (TLS BRs) to gradually sunset (1) all remaining email and phone-based domain and IP address validation methods from Sections 3.2.2.4 and 3.2.2.5 and (2) a validation method that enables “crossover” attacks as described by Henry Birge-Lee during the 24 July 2025 Validation Subcommittee Meeting.
Background:
Scope:
The following validation methods are proposed for a gradual sunset:
Methods relying on email and phone:
· 3.2.2.4.4 ("Constructed Email to Domain Contact")
· 3.2.2.4.13 ("Email to DNS CAA Contact")
· 3.2.2.4.14 ("Email to DNS TXT Contact")
· 3.2.2.4.16 ("Phone Contact with DNS TXT Record Phone Contact")
· 3.2.2.4.17 ("Phone Contact with DNS CAA Phone Contact")
· 3.2.2.5.2 ("Email, Fax, SMS, or Postal Mail to IP Address Contact")
· 3.2.2.5.5 ("Phone Contact with IP Address Contact")
Method that enable crossover attacks:
· 3.2.2.4.8 (“IP Address”)
Justification:
For sunsetting email and phone-based methods:
· The in-scope methods do not offer the stronger security assurances provided by the existing alternative methods currently detailed in the TLS BRs.
o For example, while MPIC (Ballot SC-067) can be applied to DNS lookups for email addresses sourced from DNS (e.g., Methods 3.2.2.4.13, 3.2.2.4.14), it does not prevent fraudulent issuance if the MX server's IP or its DNS resolution is hijacked, as the MX server address itself is not part of the MPIC lookup for the domain contact.
· An attacker could perform a BGP hijack of the victim's MX server IP or its DNS resolution, serve the legitimate victim email address (which passes MPIC for the contact lookup), and still intercept the validation email.
· Similar attacks can target constructed email methods by hijacking the MX server.
o Though applying MPIC to MX record lookups would be an improvement to help protect against DNS-based attacks affecting email routing, but it would not protect against in-transit hijacks (e.g., vulnerabilities in SMTP traffic itself like opportunistic TLS downgrades) or post-mail-server delivery compromises (e.g., an attacker gaining unauthorized access to the recipient's mailbox via POP3/IMAP).
o Requiring multiple challenges to be sent from multiple addresses could also be considered a security improvement, but would likely work against agility goals and is expected to be undesirable due to subscriber inconvenience.
o The ability for email-based DCV methods to reliably satisfy DNSSEC checking expectations introduced by SC-085 is unclear, further emphasizing these methods as a “weak link.” Because of this concern, this ballot discourages use of email-based methods beginning the effective date of SC-085 (March 15, 2026).
· The in-scope methods represent an expanded attack surface to publicly-trusted TLS certificate issuance when compared to existing alternatives.
o These methods broaden the attack surface compared to “direct” validation methods like DNS TXT records or HTTP file challenges.
o Email validation involves a more complex chain of operations, including MX record lookups and resolution of mail server addresses, potentially involving third-party mail providers and their DNS infrastructure. Additional participants in the validation process should be seen as added risk.
o Using DNS TXT or CAA records to find a contact email address can introduce further DNS queries, each an additional vector for attack.
o Compromise at any point in this extended chain can lead to fraudulent certificate issuance. Direct DNS or HTTP challenges confine the attack surface primarily to the validated domain.
o Audits don’t meaningfully or completely evaluate the security of these services, even considering elements hosted directly by the CA subject to the audit’s scope, further calling into question their reliability.
· The in-scope methods inherit vulnerabilities from the underlying communication channels and associated service providers.
o The compromise of an email service provider (private or public), could potentially grant attackers access to any number of fraudulently issued certificates due to no fault of a CA Owner or subscriber.
o There are numerous examples of large-scale attacks on such services and providers. These attacks should be considered as becoming more prevalent, not less.
o It is also broadly understood by security professionals that many successful attacks are never publicly disclosed or may go undetected for considerable periods. This established pattern of attacks, combined with the strong and persistent motivations for adversaries to target email systems, makes the continued use of email-based DCV a concern for maintaining the security and integrity of the ecosystem.
o Email relies on opportunistic TLS and is susceptible to downgrade. Phone systems share similar inherent vulnerabilities like SIM Swapping and SS7 attacks (example).
o As evidenced in the WatchTowr report that motivated the sunset of methods relying on domain contact information via SC-080, vulnerabilities in these communication channels or associated service providers represent significant and convenient collateral impact.
· The in-scope methods represent a weaker binding to domain/IP control than existing alternatives.
o Email and phone-based DCV methods exhibit a "weak binding" as they only demonstrate that an applicant can interact with a communication medium associated with the domain, not necessarily direct administrative control over the domain's core infrastructure.
o Read access to an email inbox (e.g., ad...@example.com) or a phone number does not inherently equate to comprehensive control over DNS configuration, web server content, or policy authority for the domain.
o Email accounts are susceptible to compromise, unauthorized and unintended delegation, or mismanagement independently of the domain's core operational control.
· We presently have DCV methods (e.g., ACME-based DNS or HTTP challenges) that offer greater automation, scalability, security, and better align with subscriber agility needs, especially when considering decreasing certificate lifetimes. Similarly, the SCWG continues to develop new DCV methods that promote automation, agility, and subscriber convenience (e.g., SC-088).
For sunsetting methods that could be used in “crossover” attacks:
· The in-scope methods allow attackers to obtain fraudulent certificates that contain a domain name(s) they do not possess authoritative control.
· While the original scope of this ballot included a sunset for 3.2.2.5.3 (“Reverse Address Lookup”), it is instead planned for sunset in SC-091.
Benefits of adoption:
· Elevate overall security posture by directly addressing the "Weakest Link Principle" in our domain validation security chain, ensuring attackers cannot leverage less secure methods to compromise certificate issuance. So long as these inherently less secure and more susceptible methods remain available, they present a persistent, exploitable target for adversaries.
· Reduce risk of improper certificate issuance by sunsetting a method that enables "crossover" attacks, which are often made possible by IP reassignment, host header vulnerabilities, and reverse DNS vulnerabilities.
· Promote stronger validation integrity by ensuring that DCV relies on methods with a stronger binding to actual administrative control over a domain or IP address, increasing the consistency of trustworthiness of issued certificates.
· Simplify the threat space by removing phone and email-based DCV, which eliminates unnecessary dependencies on large and complex ecosystems with inherent challenges, risks and vulnerabilities.
· Increase agility by encouraging site owners to transition to modern DCV methods, creating opportunities for faster and more efficient certificate lifecycle management through automation.
· Create opportunities for innovation by promoting the development of new and improved DCV methods, fostering advancements that may further enhance the overall security and agility of the ecosystem.
· Promote simplicity by streamlining the list of approved DCV methods in the TLS BRs, reducing complexity for CAs, developers, auditors, and subscribers.
Proposed Key Dates:
The effective dates considered in this update are intended to allow subscribers and CA Owners relying on existing implementations of these methods to transition to alternatives.
· Effective March 15, 2026:
o Sunset method 3.2.2.4.8 (“IP Address”)
o Discourage use of email and phone-based methods.
· Effective March 15, 2027:
o Sunset method 3.2.2.4.16 ("Phone Contact with DNS TXT Record Phone Contact")
o Sunset method 3.2.2.4.17 ("Phone Contact with DNS CAA Phone Contact")
o Sunset method 3.2.2.5.2 ("Email, Fax, SMS, or Postal Mail to IP Address Contact")
o Sunset method 3.2.2.5.5 ("Phone Contact with IP Address Contact")
· Effective March 15, 2028:
o Sunset method 3.2.2.4.4 ("Constructed Email to Domain Contact")
o Sunset method 3.2.2.4.13 ("Email to DNS CAA Contact")
o Sunset method 3.2.2.4.14 ("Email to DNS TXT Contact")
Proposal Revision History:
· Version #1 (this version)
The following motion has been proposed by Ryan Dickson and Chris Clements of Google (Chrome Root Program) and endorsed by Ben Wilson (Mozilla) and Tim Callan (Sectigo).
— Motion Begins —
This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.1.5.
MODIFY the Baseline Requirements as specified in the following Redline:
— Motion Ends —
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (no less than 14 days)
· Start: 2025-10-24 11:15:00 ET
· End: 2025-11-12 16:14:59 ET
Vote for approval (7 days)
· Start: 2025-11-12 16:15:00 ET
· End: 2025-11-19 16:15:00 ET
--
qi_ji...@itrus.com.cn
发送时间： 2025-11-13 05:14收件人： servercert-wg主题： [Servercert-wg] Voting Period Begins - Ballot SC-90: "Gradually sunset all remaining email-based, phone-based, and ‘crossover’ validation methods from Sections 3.2.2.4 and 3.2.2.5"
--
Scott Rea
eMudhra votes YES on Ballot SC-90
From:
'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Date: Wednesday, 12 November 2025 at 2:18
PM
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Subject: [Servercert-wg] Voting Period Begins - Ballot SC-90: "Gradually sunset all remaining email-based, phone-based, and ‘crossover’ validation methods from Sections 3.2.2.4 and 3.2.2.5"
|
CAUTION: This email is originated from outside of the organization. Do not open the links or the attachments unless you recognize the sender and know the content is safe. |
Purpose of Ballot SC-90:
This ballot proposes updates to the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (TLS BRs) to gradually sunset (1) all remaining email and phone-based domain and IP address validation methods from Sections 3.2.2.4 and 3.2.2.5 and (2) a validation method that enables “crossover” attacks as described by Henry Birge-Lee during the 24 July 2025 Validation Subcommittee Meeting.
Background:
Scope:
The following validation methods are proposed for a gradual sunset:
Methods relying on email and phone:
· 3.2.2.4.4 ("Constructed Email to Domain Contact")
· 3.2.2.4.13 ("Email to DNS CAA Contact")
· 3.2.2.4.14 ("Email to DNS TXT Contact")
· 3.2.2.4.16 ("Phone Contact with DNS TXT Record Phone Contact")
· 3.2.2.4.17 ("Phone Contact with DNS CAA Phone Contact")
· 3.2.2.5.2 ("Email, Fax, SMS, or Postal Mail to IP Address Contact")
· 3.2.2.5.5 ("Phone Contact with IP Address Contact")
Method that enable crossover attacks:
· 3.2.2.4.8 (“IP Address”)
Justification:
For sunsetting email and phone-based methods:
· The in-scope methods do not offer the stronger security assurances provided by the existing alternative methods currently detailed in the TLS BRs.
o For example, while MPIC (Ballot SC-067) can be applied to DNS lookups for email addresses sourced from DNS (e.g., Methods 3.2.2.4.13, 3.2.2.4.14), it does not prevent fraudulent issuance if the MX server's IP or its DNS resolution is hijacked, as the MX server address itself is not part of the MPIC lookup for the domain contact.
· An attacker could perform a BGP hijack of the victim's MX server IP or its DNS resolution, serve the legitimate victim email address (which passes MPIC for the contact lookup), and still intercept the validation email.
· Similar attacks can target constructed email methods by hijacking the MX server.
o Though applying MPIC to MX record lookups would be an improvement to help protect against DNS-based attacks affecting email routing, but it would not protect against in-transit hijacks (e.g., vulnerabilities in SMTP traffic itself like opportunistic TLS downgrades) or post-mail-server delivery compromises (e.g., an attacker gaining unauthorized access to the recipient's mailbox via POP3/IMAP).
o Requiring multiple challenges to be sent from multiple addresses could also be considered a security improvement, but would likely work against agility goals and is expected to be undesirable due to subscriber inconvenience.
o The ability for email-based DCV methods to reliably satisfy DNSSEC checking expectations introduced by SC-085 is unclear, further emphasizing these methods as a “weak link.” Because of this concern, this ballot discourages use of email-based methods beginning the effective date of SC-085 (March 15, 2026).
· The in-scope methods represent an expanded attack surface to publicly-trusted TLS certificate issuance when compared to existing alternatives.
o These methods broaden the attack surface compared to “direct” validation methods like DNS TXT records or HTTP file challenges.
o Email validation involves a more complex chain of operations, including MX record lookups and resolution of mail server addresses, potentially involving third-party mail providers and their DNS infrastructure. Additional participants in the validation process should be seen as added risk.
o Using DNS TXT or CAA records to find a contact email address can introduce further DNS queries, each an additional vector for attack.
o Compromise at any point in this extended chain can lead to fraudulent certificate issuance. Direct DNS or HTTP challenges confine the attack surface primarily to the validated domain.
o Audits don’t meaningfully or completely evaluate the security of these services, even considering elements hosted directly by the CA subject to the audit’s scope, further calling into question their reliability.
· The in-scope methods inherit vulnerabilities from the underlying communication channels and associated service providers.
o The compromise of an email service provider (private or public), could potentially grant attackers access to any number of fraudulently issued certificates due to no fault of a CA Owner or subscriber.
o There are numerous examples of large-scale attacks on such services and providers. These attacks should be considered as becoming more prevalent, not less.
o It is also broadly understood by security professionals that many successful attacks are never publicly disclosed or may go undetected for considerable periods. This established pattern of attacks, combined with the strong and persistent motivations for adversaries to target email systems, makes the continued use of email-based DCV a concern for maintaining the security and integrity of the ecosystem.
o Email relies on opportunistic TLS and is susceptible to downgrade. Phone systems share similar inherent vulnerabilities like SIM Swapping and SS7 attacks (example).
o As evidenced in the WatchTowr report that motivated the sunset of methods relying on domain contact information via SC-080, vulnerabilities in these communication channels or associated service providers represent significant and convenient collateral impact.
· The in-scope methods represent a weaker binding to domain/IP control than existing alternatives.
o Email and phone-based DCV methods exhibit a "weak binding" as they only demonstrate that an applicant can interact with a communication medium associated with the domain, not necessarily direct administrative control over the domain's core infrastructure.
o Read access to an email inbox (e.g., ad...@example.com) or a phone number does not inherently equate to comprehensive control over DNS configuration, web server content, or policy authority for the domain.
o Email accounts are susceptible to compromise, unauthorized and unintended delegation, or mismanagement independently of the domain's core operational control.
· We presently have DCV methods (e.g., ACME-based DNS or HTTP challenges) that offer greater automation, scalability, security, and better align with subscriber agility needs, especially when considering decreasing certificate lifetimes. Similarly, the SCWG continues to develop new DCV methods that promote automation, agility, and subscriber convenience (e.g., SC-088).
For sunsetting methods that could be used in “crossover” attacks:
· The in-scope methods allow attackers to obtain fraudulent certificates that contain a domain name(s) they do not possess authoritative control.
· While the original scope of this ballot included a sunset for 3.2.2.5.3 (“Reverse Address Lookup”), it is instead planned for sunset in SC-091.
Benefits of adoption:
· Elevate overall security posture by directly addressing the "Weakest Link Principle" in our domain validation security chain, ensuring attackers cannot leverage less secure methods to compromise certificate issuance. So long as these inherently less secure and more susceptible methods remain available, they present a persistent, exploitable target for adversaries.
· Reduce risk of improper certificate issuance by sunsetting a method that enables "crossover" attacks, which are often made possible by IP reassignment, host header vulnerabilities, and reverse DNS vulnerabilities.
· Promote stronger validation integrity by ensuring that DCV relies on methods with a stronger binding to actual administrative control over a domain or IP address, increasing the consistency of trustworthiness of issued certificates.
· Simplify the threat space by removing phone and email-based DCV, which eliminates unnecessary dependencies on large and complex ecosystems with inherent challenges, risks and vulnerabilities.
· Increase agility by encouraging site owners to transition to modern DCV methods, creating opportunities for faster and more efficient certificate lifecycle management through automation.
· Create opportunities for innovation by promoting the development of new and improved DCV methods, fostering advancements that may further enhance the overall security and agility of the ecosystem.
· Promote simplicity by streamlining the list of approved DCV methods in the TLS BRs, reducing complexity for CAs, developers, auditors, and subscribers.
Proposed Key Dates:
The effective dates considered in this update are intended to allow subscribers and CA Owners relying on existing implementations of these methods to transition to alternatives.
· Effective March 15, 2026:
o Sunset method 3.2.2.4.8 (“IP Address”)
o Discourage use of email and phone-based methods.
· Effective March 15, 2027:
o Sunset method 3.2.2.4.16 ("Phone Contact with DNS TXT Record Phone Contact")
o Sunset method 3.2.2.4.17 ("Phone Contact with DNS CAA Phone Contact")
o Sunset method 3.2.2.5.2 ("Email, Fax, SMS, or Postal Mail to IP Address Contact")
o Sunset method 3.2.2.5.5 ("Phone Contact with IP Address Contact")
· Effective March 15, 2028:
o Sunset method 3.2.2.4.4 ("Constructed Email to Domain Contact")
o Sunset method 3.2.2.4.13 ("Email to DNS CAA Contact")
o Sunset method 3.2.2.4.14 ("Email to DNS TXT Contact")
Proposal Revision History:
· Version #1 (this version)
The following motion has been proposed by Ryan Dickson and Chris Clements of Google (Chrome Root Program) and endorsed by Ben Wilson (Mozilla) and Tim Callan (Sectigo).
— Motion Begins —
This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.1.5.
MODIFY the Baseline Requirements as specified in the following Redline:
— Motion Ends —
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (no less than 14 days)
· Start: 2025-10-24 11:15:00 ET
· End: 2025-11-12 16:14:59 ET
Vote for approval (7 days)
· Start: 2025-11-12 16:15:00 ET
· End: 2025-11-19 16:15:00 ET
--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
servercert-w...@groups.cabforum.org.
To view this discussion visit
https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CADEW5O97dHokb783ZaFVVh-CVbydrw_tjJ0Hf3KD2%2BU745Omfg%40mail.gmail.com.
Adriano Santoni
Actalis votes "Yes" on Ballot SC-90.
--
Backman, Antti
//Antti
Date: Wednesday, 12. November 2025 at 23.15
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Kateryna Aleksieieva
Certum votes YES on Ballot SC-90
Kind regards,
Kateryna Aleksieieva
From: 'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Wednesday, November 12, 2025 10:15 PM
To: server...@groups.cabforum.org
Subject: [Servercert-wg] Voting Period Begins - Ballot SC-90: "Gradually sunset all remaining email-based, phone-based, and ‘crossover’ validation methods from Sections 3.2.2.4 and 3.2.2.5"
Purpose of Ballot SC-90:
This ballot proposes updates to the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (TLS BRs) to gradually sunset (1) all remaining email and phone-based domain and IP address validation methods from Sections 3.2.2.4 and 3.2.2.5 and (2) a validation method that enables “crossover” attacks as described by Henry Birge-Lee during the 24 July 2025 Validation Subcommittee Meeting.
Background:
Scope:
The following validation methods are proposed for a gradual sunset:
Methods relying on email and phone:
· 3.2.2.4.4 ("Constructed Email to Domain Contact")
· 3.2.2.4.13 ("Email to DNS CAA Contact")
· 3.2.2.4.14 ("Email to DNS TXT Contact")
· 3.2.2.4.16 ("Phone Contact with DNS TXT Record Phone Contact")
· 3.2.2.4.17 ("Phone Contact with DNS CAA Phone Contact")
· 3.2.2.5.2 ("Email, Fax, SMS, or Postal Mail to IP Address Contact")
· 3.2.2.5.5 ("Phone Contact with IP Address Contact")
Method that enable crossover attacks:
· 3.2.2.4.8 (“IP Address”)
Justification:
For sunsetting email and phone-based methods:
· The in-scope methods do not offer the stronger security assurances provided by the existing alternative methods currently detailed in the TLS BRs.
o For example, while MPIC (Ballot SC-067) can be applied to DNS lookups for email addresses sourced from DNS (e.g., Methods 3.2.2.4.13, 3.2.2.4.14), it does not prevent fraudulent issuance if the MX server's IP or its DNS resolution is hijacked, as the MX server address itself is not part of the MPIC lookup for the domain contact.
· An attacker could perform a BGP hijack of the victim's MX server IP or its DNS resolution, serve the legitimate victim email address (which passes MPIC for the contact lookup), and still intercept the validation email.
· Similar attacks can target constructed email methods by hijacking the MX server.
o Though applying MPIC to MX record lookups would be an improvement to help protect against DNS-based attacks affecting email routing, but it would not protect against in-transit hijacks (e.g., vulnerabilities in SMTP traffic itself like opportunistic TLS downgrades) or post-mail-server delivery compromises (e.g., an attacker gaining unauthorized access to the recipient's mailbox via POP3/IMAP).
o Requiring multiple challenges to be sent from multiple addresses could also be considered a security improvement, but would likely work against agility goals and is expected to be undesirable due to subscriber inconvenience.
o The ability for email-based DCV methods to reliably satisfy DNSSEC checking expectations introduced by SC-085 is unclear, further emphasizing these methods as a “weak link.” Because of this concern, this ballot discourages use of email-based methods beginning the effective date of SC-085 (March 15, 2026).
· The in-scope methods represent an expanded attack surface to publicly-trusted TLS certificate issuance when compared to existing alternatives.
o These methods broaden the attack surface compared to “direct” validation methods like DNS TXT records or HTTP file challenges.
o Email validation involves a more complex chain of operations, including MX record lookups and resolution of mail server addresses, potentially involving third-party mail providers and their DNS infrastructure. Additional participants in the validation process should be seen as added risk.
o Using DNS TXT or CAA records to find a contact email address can introduce further DNS queries, each an additional vector for attack.
o Compromise at any point in this extended chain can lead to fraudulent certificate issuance. Direct DNS or HTTP challenges confine the attack surface primarily to the validated domain.
o Audits don’t meaningfully or completely evaluate the security of these services, even considering elements hosted directly by the CA subject to the audit’s scope, further calling into question their reliability.
· The in-scope methods inherit vulnerabilities from the underlying communication channels and associated service providers.
o The compromise of an email service provider (private or public), could potentially grant attackers access to any number of fraudulently issued certificates due to no fault of a CA Owner or subscriber.
o There are numerous examples of large-scale attacks on such services and providers. These attacks should be considered as becoming more prevalent, not less.
o It is also broadly understood by security professionals that many successful attacks are never publicly disclosed or may go undetected for considerable periods. This established pattern of attacks, combined with the strong and persistent motivations for adversaries to target email systems, makes the continued use of email-based DCV a concern for maintaining the security and integrity of the ecosystem.
o Email relies on opportunistic TLS and is susceptible to downgrade. Phone systems share similar inherent vulnerabilities like SIM Swapping and SS7 attacks (example).
o As evidenced in the WatchTowr report that motivated the sunset of methods relying on domain contact information via SC-080, vulnerabilities in these communication channels or associated service providers represent significant and convenient collateral impact.
· The in-scope methods represent a weaker binding to domain/IP control than existing alternatives.
o Email and phone-based DCV methods exhibit a "weak binding" as they only demonstrate that an applicant can interact with a communication medium associated with the domain, not necessarily direct administrative control over the domain's core infrastructure.
o Read access to an email inbox (e.g., ad...@example.com) or a phone number does not inherently equate to comprehensive control over DNS configuration, web server content, or policy authority for the domain.
o Email accounts are susceptible to compromise, unauthorized and unintended delegation, or mismanagement independently of the domain's core operational control.
· We presently have DCV methods (e.g., ACME-based DNS or HTTP challenges) that offer greater automation, scalability, security, and better align with subscriber agility needs, especially when considering decreasing certificate lifetimes. Similarly, the SCWG continues to develop new DCV methods that promote automation, agility, and subscriber convenience (e.g., SC-088).
For sunsetting methods that could be used in “crossover” attacks:
· The in-scope methods allow attackers to obtain fraudulent certificates that contain a domain name(s) they do not possess authoritative control.
· While the original scope of this ballot included a sunset for 3.2.2.5.3 (“Reverse Address Lookup”), it is instead planned for sunset in SC-091.
Benefits of adoption:
· Elevate overall security posture by directly addressing the "Weakest Link Principle" in our domain validation security chain, ensuring attackers cannot leverage less secure methods to compromise certificate issuance. So long as these inherently less secure and more susceptible methods remain available, they present a persistent, exploitable target for adversaries.
· Reduce risk of improper certificate issuance by sunsetting a method that enables "crossover" attacks, which are often made possible by IP reassignment, host header vulnerabilities, and reverse DNS vulnerabilities.
· Promote stronger validation integrity by ensuring that DCV relies on methods with a stronger binding to actual administrative control over a domain or IP address, increasing the consistency of trustworthiness of issued certificates.
· Simplify the threat space by removing phone and email-based DCV, which eliminates unnecessary dependencies on large and complex ecosystems with inherent challenges, risks and vulnerabilities.
· Increase agility by encouraging site owners to transition to modern DCV methods, creating opportunities for faster and more efficient certificate lifecycle management through automation.
· Create opportunities for innovation by promoting the development of new and improved DCV methods, fostering advancements that may further enhance the overall security and agility of the ecosystem.
· Promote simplicity by streamlining the list of approved DCV methods in the TLS BRs, reducing complexity for CAs, developers, auditors, and subscribers.
Proposed Key Dates:
The effective dates considered in this update are intended to allow subscribers and CA Owners relying on existing implementations of these methods to transition to alternatives.
· Effective March 15, 2026:
o Sunset method 3.2.2.4.8 (“IP Address”)
o Discourage use of email and phone-based methods.
· Effective March 15, 2027:
o Sunset method 3.2.2.4.16 ("Phone Contact with DNS TXT Record Phone Contact")
o Sunset method 3.2.2.4.17 ("Phone Contact with DNS CAA Phone Contact")
o Sunset method 3.2.2.5.2 ("Email, Fax, SMS, or Postal Mail to IP Address Contact")
o Sunset method 3.2.2.5.5 ("Phone Contact with IP Address Contact")
· Effective March 15, 2028:
o Sunset method 3.2.2.4.4 ("Constructed Email to Domain Contact")
o Sunset method 3.2.2.4.13 ("Email to DNS CAA Contact")
o Sunset method 3.2.2.4.14 ("Email to DNS TXT Contact")
Proposal Revision History:
· Version #1 (this version)
The following motion has been proposed by Ryan Dickson and Chris Clements of Google (Chrome Root Program) and endorsed by Ben Wilson (Mozilla) and Tim Callan (Sectigo).
— Motion Begins —
This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.1.5.
MODIFY the Baseline Requirements as specified in the following Redline:
— Motion Ends —
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (no less than 14 days)
· Start: 2025-10-24 11:15:00 ET
· End: 2025-11-12 16:14:59 ET
Vote for approval (7 days)
· Start: 2025-11-12 16:15:00 ET
· End: 2025-11-19 16:15:00 ET
--
大野 文彰
SECOM Trust Systems votes YES on Ballot SC-90.
Best regards,
ONO Fumiaki / 大野 文彰
(Japanese name order: family name first, in uppercase)
SECOM Trust Systems CO., LTD.
From: 'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Thursday, November 13, 2025 6:15 AM
To: server...@groups.cabforum.org
Subject: [Servercert-wg] Voting Period Begins - Ballot SC-90: "Gradually sunset all remaining email-based, phone-based, and ‘crossover’ validation methods from Sections 3.2.2.4 and 3.2.2.5"
Purpose of Ballot SC-90:
This ballot proposes updates to the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (TLS BRs) to gradually sunset (1) all remaining email and phone-based domain and IP address validation methods from Sections 3.2.2.4 and 3.2.2.5 and (2) a validation method that enables “crossover” attacks as described by Henry Birge-Lee during the 24 July 2025 Validation Subcommittee Meeting.
Background:
Scope:
The following validation methods are proposed for a gradual sunset:
Methods relying on email and phone:
· 3.2.2.4.4 ("Constructed Email to Domain Contact")
· 3.2.2.4.13 ("Email to DNS CAA Contact")
· 3.2.2.4.14 ("Email to DNS TXT Contact")
· 3.2.2.4.16 ("Phone Contact with DNS TXT Record Phone Contact")
· 3.2.2.4.17 ("Phone Contact with DNS CAA Phone Contact")
· 3.2.2.5.2 ("Email, Fax, SMS, or Postal Mail to IP Address Contact")
· 3.2.2.5.5 ("Phone Contact with IP Address Contact")
Method that enable crossover attacks:
· 3.2.2.4.8 (“IP Address”)
Justification:
For sunsetting email and phone-based methods:
· The in-scope methods do not offer the stronger security assurances provided by the existing alternative methods currently detailed in the TLS BRs.
o For example, while MPIC (Ballot SC-067) can be applied to DNS lookups for email addresses sourced from DNS (e.g., Methods 3.2.2.4.13, 3.2.2.4.14), it does not prevent fraudulent issuance if the MX server's IP or its DNS resolution is hijacked, as the MX server address itself is not part of the MPIC lookup for the domain contact.
· An attacker could perform a BGP hijack of the victim's MX server IP or its DNS resolution, serve the legitimate victim email address (which passes MPIC for the contact lookup), and still intercept the validation email.
· Similar attacks can target constructed email methods by hijacking the MX server.
o Though applying MPIC to MX record lookups would be an improvement to help protect against DNS-based attacks affecting email routing, but it would not protect against in-transit hijacks (e.g., vulnerabilities in SMTP traffic itself like opportunistic TLS downgrades) or post-mail-server delivery compromises (e.g., an attacker gaining unauthorized access to the recipient's mailbox via POP3/IMAP).
o Requiring multiple challenges to be sent from multiple addresses could also be considered a security improvement, but would likely work against agility goals and is expected to be undesirable due to subscriber inconvenience.
o The ability for email-based DCV methods to reliably satisfy DNSSEC checking expectations introduced by SC-085 is unclear, further emphasizing these methods as a “weak link.” Because of this concern, this ballot discourages use of email-based methods beginning the effective date of SC-085 (March 15, 2026).
· The in-scope methods represent an expanded attack surface to publicly-trusted TLS certificate issuance when compared to existing alternatives.
o These methods broaden the attack surface compared to “direct” validation methods like DNS TXT records or HTTP file challenges.
o Email validation involves a more complex chain of operations, including MX record lookups and resolution of mail server addresses, potentially involving third-party mail providers and their DNS infrastructure. Additional participants in the validation process should be seen as added risk.
o Using DNS TXT or CAA records to find a contact email address can introduce further DNS queries, each an additional vector for attack.
o Compromise at any point in this extended chain can lead to fraudulent certificate issuance. Direct DNS or HTTP challenges confine the attack surface primarily to the validated domain.
o Audits don’t meaningfully or completely evaluate the security of these services, even considering elements hosted directly by the CA subject to the audit’s scope, further calling into question their reliability.
· The in-scope methods inherit vulnerabilities from the underlying communication channels and associated service providers.
o The compromise of an email service provider (private or public), could potentially grant attackers access to any number of fraudulently issued certificates due to no fault of a CA Owner or subscriber.
o There are numerous examples of large-scale attacks on such services and providers. These attacks should be considered as becoming more prevalent, not less.
o It is also broadly understood by security professionals that many successful attacks are never publicly disclosed or may go undetected for considerable periods. This established pattern of attacks, combined with the strong and persistent motivations for adversaries to target email systems, makes the continued use of email-based DCV a concern for maintaining the security and integrity of the ecosystem.
o Email relies on opportunistic TLS and is susceptible to downgrade. Phone systems share similar inherent vulnerabilities like SIM Swapping and SS7 attacks (example).
o As evidenced in the WatchTowr report that motivated the sunset of methods relying on domain contact information via SC-080, vulnerabilities in these communication channels or associated service providers represent significant and convenient collateral impact.
· The in-scope methods represent a weaker binding to domain/IP control than existing alternatives.
o Email and phone-based DCV methods exhibit a "weak binding" as they only demonstrate that an applicant can interact with a communication medium associated with the domain, not necessarily direct administrative control over the domain's core infrastructure.
o Read access to an email inbox (e.g., ad...@example.com) or a phone number does not inherently equate to comprehensive control over DNS configuration, web server content, or policy authority for the domain.
o Email accounts are susceptible to compromise, unauthorized and unintended delegation, or mismanagement independently of the domain's core operational control.
· We presently have DCV methods (e.g., ACME-based DNS or HTTP challenges) that offer greater automation, scalability, security, and better align with subscriber agility needs, especially when considering decreasing certificate lifetimes. Similarly, the SCWG continues to develop new DCV methods that promote automation, agility, and subscriber convenience (e.g., SC-088).
For sunsetting methods that could be used in “crossover” attacks:
· The in-scope methods allow attackers to obtain fraudulent certificates that contain a domain name(s) they do not possess authoritative control.
· While the original scope of this ballot included a sunset for 3.2.2.5.3 (“Reverse Address Lookup”), it is instead planned for sunset in SC-091.
Benefits of adoption:
· Elevate overall security posture by directly addressing the "Weakest Link Principle" in our domain validation security chain, ensuring attackers cannot leverage less secure methods to compromise certificate issuance. So long as these inherently less secure and more susceptible methods remain available, they present a persistent, exploitable target for adversaries.
· Reduce risk of improper certificate issuance by sunsetting a method that enables "crossover" attacks, which are often made possible by IP reassignment, host header vulnerabilities, and reverse DNS vulnerabilities.
· Promote stronger validation integrity by ensuring that DCV relies on methods with a stronger binding to actual administrative control over a domain or IP address, increasing the consistency of trustworthiness of issued certificates.
· Simplify the threat space by removing phone and email-based DCV, which eliminates unnecessary dependencies on large and complex ecosystems with inherent challenges, risks and vulnerabilities.
· Increase agility by encouraging site owners to transition to modern DCV methods, creating opportunities for faster and more efficient certificate lifecycle management through automation.
· Create opportunities for innovation by promoting the development of new and improved DCV methods, fostering advancements that may further enhance the overall security and agility of the ecosystem.
· Promote simplicity by streamlining the list of approved DCV methods in the TLS BRs, reducing complexity for CAs, developers, auditors, and subscribers.
Proposed Key Dates:
The effective dates considered in this update are intended to allow subscribers and CA Owners relying on existing implementations of these methods to transition to alternatives.
· Effective March 15, 2026:
o Sunset method 3.2.2.4.8 (“IP Address”)
o Discourage use of email and phone-based methods.
· Effective March 15, 2027:
o Sunset method 3.2.2.4.16 ("Phone Contact with DNS TXT Record Phone Contact")
o Sunset method 3.2.2.4.17 ("Phone Contact with DNS CAA Phone Contact")
o Sunset method 3.2.2.5.2 ("Email, Fax, SMS, or Postal Mail to IP Address Contact")
o Sunset method 3.2.2.5.5 ("Phone Contact with IP Address Contact")
· Effective March 15, 2028:
o Sunset method 3.2.2.4.4 ("Constructed Email to Domain Contact")
o Sunset method 3.2.2.4.13 ("Email to DNS CAA Contact")
o Sunset method 3.2.2.4.14 ("Email to DNS TXT Contact")
Proposal Revision History:
· Version #1 (this version)
The following motion has been proposed by Ryan Dickson and Chris Clements of Google (Chrome Root Program) and endorsed by Ben Wilson (Mozilla) and Tim Callan (Sectigo).
— Motion Begins —
This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.1.5.
MODIFY the Baseline Requirements as specified in the following Redline:
— Motion Ends —
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (no less than 14 days)
· Start: 2025-10-24 11:15:00 ET
· End: 2025-11-12 16:14:59 ET
Vote for approval (7 days)
· Start: 2025-11-12 16:15:00 ET
· End: 2025-11-19 16:15:00 ET
--
郭宗閔
Chunghwa Telecom votes YES on Ballot SC-90.
Regards,
Tsung-Min Kuo
Chunghwa Telecom Co., Ltd.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/TYCP286MB33639A1001329881A602196BAED6A%40TYCP286MB3363.JPNP286.PROD.OUTLOOK.COM.
本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件. 如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任.
Please be advised that this email message (including any attachments) contains confidential information and may be legally privileged. If you are not the intended recipient, please destroy this message and all attachments from your system and do not further collect, process, or use them. Chunghwa Telecom and all its subsidiaries and associated companies shall not be liable for the improper or incomplete transmission of the information contained in this email nor for any delay in its receipt or damage to your system. If you are the intended recipient, please protect the confidential and/or personal information contained in this email with due care. Any unauthorized use, disclosure or distribution of this message in whole or in part is strictly prohibited. Also, please self-inspect attachments and hyperlinks contained in this email to ensure the information security and to protect personal information.
Peter Miškovič
Disig votes „YES“ on Ballot SC-90: "Gradually sunset all remaining email-based, phone-based, and ‘crossover’ validation methods from Sections 3.2.2.4 and 3.2.2.5".
Rergards
Peter Miskovic
From: 'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: streda 12. novembra 2025 22:15
To: server...@groups.cabforum.org
Subject: [Servercert-wg] Voting Period Begins - Ballot SC-90: "Gradually sunset all remaining email-based, phone-based, and ‘crossover’ validation methods from Sections 3.2.2.4 and 3.2.2.5"
Purpose of Ballot SC-90:
This ballot proposes updates to the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (TLS BRs) to gradually sunset (1) all remaining email and phone-based domain and IP address validation methods from Sections 3.2.2.4 and 3.2.2.5 and (2) a validation method that enables “crossover” attacks as described by Henry Birge-Lee during the 24 July 2025 Validation Subcommittee Meeting.
Background:
Scope:
The following validation methods are proposed for a gradual sunset:
Methods relying on email and phone:
· 3.2.2.4.4 ("Constructed Email to Domain Contact")
· 3.2.2.4.13 ("Email to DNS CAA Contact")
· 3.2.2.4.14 ("Email to DNS TXT Contact")
· 3.2.2.4.16 ("Phone Contact with DNS TXT Record Phone Contact")
· 3.2.2.4.17 ("Phone Contact with DNS CAA Phone Contact")
· 3.2.2.5.2 ("Email, Fax, SMS, or Postal Mail to IP Address Contact")
· 3.2.2.5.5 ("Phone Contact with IP Address Contact")
Method that enable crossover attacks:
· 3.2.2.4.8 (“IP Address”)
Justification:
For sunsetting email and phone-based methods:
· The in-scope methods do not offer the stronger security assurances provided by the existing alternative methods currently detailed in the TLS BRs.
o For example, while MPIC (Ballot SC-067) can be applied to DNS lookups for email addresses sourced from DNS (e.g., Methods 3.2.2.4.13, 3.2.2.4.14), it does not prevent fraudulent issuance if the MX server's IP or its DNS resolution is hijacked, as the MX server address itself is not part of the MPIC lookup for the domain contact.
· An attacker could perform a BGP hijack of the victim's MX server IP or its DNS resolution, serve the legitimate victim email address (which passes MPIC for the contact lookup), and still intercept the validation email.
· Similar attacks can target constructed email methods by hijacking the MX server.
o Though applying MPIC to MX record lookups would be an improvement to help protect against DNS-based attacks affecting email routing, but it would not protect against in-transit hijacks (e.g., vulnerabilities in SMTP traffic itself like opportunistic TLS downgrades) or post-mail-server delivery compromises (e.g., an attacker gaining unauthorized access to the recipient's mailbox via POP3/IMAP).
o Requiring multiple challenges to be sent from multiple addresses could also be considered a security improvement, but would likely work against agility goals and is expected to be undesirable due to subscriber inconvenience.
o The ability for email-based DCV methods to reliably satisfy DNSSEC checking expectations introduced by SC-085 is unclear, further emphasizing these methods as a “weak link.” Because of this concern, this ballot discourages use of email-based methods beginning the effective date of SC-085 (March 15, 2026).
· The in-scope methods represent an expanded attack surface to publicly-trusted TLS certificate issuance when compared to existing alternatives.
o These methods broaden the attack surface compared to “direct” validation methods like DNS TXT records or HTTP file challenges.
o Email validation involves a more complex chain of operations, including MX record lookups and resolution of mail server addresses, potentially involving third-party mail providers and their DNS infrastructure. Additional participants in the validation process should be seen as added risk.
o Using DNS TXT or CAA records to find a contact email address can introduce further DNS queries, each an additional vector for attack.
o Compromise at any point in this extended chain can lead to fraudulent certificate issuance. Direct DNS or HTTP challenges confine the attack surface primarily to the validated domain.
o Audits don’t meaningfully or completely evaluate the security of these services, even considering elements hosted directly by the CA subject to the audit’s scope, further calling into question their reliability.
· The in-scope methods inherit vulnerabilities from the underlying communication channels and associated service providers.
o The compromise of an email service provider (private or public), could potentially grant attackers access to any number of fraudulently issued certificates due to no fault of a CA Owner or subscriber.
o There are numerous examples of large-scale attacks on such services and providers. These attacks should be considered as becoming more prevalent, not less.
o It is also broadly understood by security professionals that many successful attacks are never publicly disclosed or may go undetected for considerable periods. This established pattern of attacks, combined with the strong and persistent motivations for adversaries to target email systems, makes the continued use of email-based DCV a concern for maintaining the security and integrity of the ecosystem.
o Email relies on opportunistic TLS and is susceptible to downgrade. Phone systems share similar inherent vulnerabilities like SIM Swapping and SS7 attacks (example).
o As evidenced in the WatchTowr report that motivated the sunset of methods relying on domain contact information via SC-080, vulnerabilities in these communication channels or associated service providers represent significant and convenient collateral impact.
· The in-scope methods represent a weaker binding to domain/IP control than existing alternatives.
o Email and phone-based DCV methods exhibit a "weak binding" as they only demonstrate that an applicant can interact with a communication medium associated with the domain, not necessarily direct administrative control over the domain's core infrastructure.
o Read access to an email inbox (e.g., ad...@example.com) or a phone number does not inherently equate to comprehensive control over DNS configuration, web server content, or policy authority for the domain.
o Email accounts are susceptible to compromise, unauthorized and unintended delegation, or mismanagement independently of the domain's core operational control.
· We presently have DCV methods (e.g., ACME-based DNS or HTTP challenges) that offer greater automation, scalability, security, and better align with subscriber agility needs, especially when considering decreasing certificate lifetimes. Similarly, the SCWG continues to develop new DCV methods that promote automation, agility, and subscriber convenience (e.g., SC-088).
For sunsetting methods that could be used in “crossover” attacks:
· The in-scope methods allow attackers to obtain fraudulent certificates that contain a domain name(s) they do not possess authoritative control.
· While the original scope of this ballot included a sunset for 3.2.2.5.3 (“Reverse Address Lookup”), it is instead planned for sunset in SC-091.
Benefits of adoption:
· Elevate overall security posture by directly addressing the "Weakest Link Principle" in our domain validation security chain, ensuring attackers cannot leverage less secure methods to compromise certificate issuance. So long as these inherently less secure and more susceptible methods remain available, they present a persistent, exploitable target for adversaries.
· Reduce risk of improper certificate issuance by sunsetting a method that enables "crossover" attacks, which are often made possible by IP reassignment, host header vulnerabilities, and reverse DNS vulnerabilities.
· Promote stronger validation integrity by ensuring that DCV relies on methods with a stronger binding to actual administrative control over a domain or IP address, increasing the consistency of trustworthiness of issued certificates.
· Simplify the threat space by removing phone and email-based DCV, which eliminates unnecessary dependencies on large and complex ecosystems with inherent challenges, risks and vulnerabilities.
· Increase agility by encouraging site owners to transition to modern DCV methods, creating opportunities for faster and more efficient certificate lifecycle management through automation.
· Create opportunities for innovation by promoting the development of new and improved DCV methods, fostering advancements that may further enhance the overall security and agility of the ecosystem.
· Promote simplicity by streamlining the list of approved DCV methods in the TLS BRs, reducing complexity for CAs, developers, auditors, and subscribers.
Proposed Key Dates:
The effective dates considered in this update are intended to allow subscribers and CA Owners relying on existing implementations of these methods to transition to alternatives.
· Effective March 15, 2026:
o Sunset method 3.2.2.4.8 (“IP Address”)
o Discourage use of email and phone-based methods.
· Effective March 15, 2027:
o Sunset method 3.2.2.4.16 ("Phone Contact with DNS TXT Record Phone Contact")
o Sunset method 3.2.2.4.17 ("Phone Contact with DNS CAA Phone Contact")
o Sunset method 3.2.2.5.2 ("Email, Fax, SMS, or Postal Mail to IP Address Contact")
o Sunset method 3.2.2.5.5 ("Phone Contact with IP Address Contact")
· Effective March 15, 2028:
o Sunset method 3.2.2.4.4 ("Constructed Email to Domain Contact")
o Sunset method 3.2.2.4.13 ("Email to DNS CAA Contact")
o Sunset method 3.2.2.4.14 ("Email to DNS TXT Contact")
Proposal Revision History:
· Version #1 (this version)
The following motion has been proposed by Ryan Dickson and Chris Clements of Google (Chrome Root Program) and endorsed by Ben Wilson (Mozilla) and Tim Callan (Sectigo).
— Motion Begins —
This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.1.5.
MODIFY the Baseline Requirements as specified in the following Redline:
— Motion Ends —
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (no less than 14 days)
· Start: 2025-10-24 11:15:00 ET
· End: 2025-11-12 16:14:59 ET
Vote for approval (7 days)
· Start: 2025-11-12 16:15:00 ET
· End: 2025-11-19 16:15:00 ET
--
Doug Beattie
GlobalSign votes yes on Ballot SC-90.
Doug
From: 'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Wednesday, November 12, 2025 4:15 PM
To: server...@groups.cabforum.org
Subject: [Servercert-wg] Voting Period Begins - Ballot SC-90: "Gradually sunset all remaining email-based, phone-based, and ‘crossover’ validation methods from Sections 3.2.2.4 and 3.2.2.5"
Purpose of Ballot SC-90:
This ballot proposes updates to the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (TLS BRs) to gradually sunset (1) all remaining email and phone-based domain and IP address validation methods from Sections 3.2.2.4 and 3.2.2.5 and (2) a validation method that enables “crossover” attacks as described by Henry Birge-Lee during the 24 July 2025 Validation Subcommittee Meeting.
Background:
Scope:
The following validation methods are proposed for a gradual sunset:
Methods relying on email and phone:
· 3.2.2.4.4 ("Constructed Email to Domain Contact")
· 3.2.2.4.13 ("Email to DNS CAA Contact")
· 3.2.2.4.14 ("Email to DNS TXT Contact")
· 3.2.2.4.16 ("Phone Contact with DNS TXT Record Phone Contact")
· 3.2.2.4.17 ("Phone Contact with DNS CAA Phone Contact")
· 3.2.2.5.2 ("Email, Fax, SMS, or Postal Mail to IP Address Contact")
· 3.2.2.5.5 ("Phone Contact with IP Address Contact")
Method that enable crossover attacks:
· 3.2.2.4.8 (“IP Address”)
Justification:
For sunsetting email and phone-based methods:
· The in-scope methods do not offer the stronger security assurances provided by the existing alternative methods currently detailed in the TLS BRs.
o For example, while MPIC (Ballot SC-067) can be applied to DNS lookups for email addresses sourced from DNS (e.g., Methods 3.2.2.4.13, 3.2.2.4.14), it does not prevent fraudulent issuance if the MX server's IP or its DNS resolution is hijacked, as the MX server address itself is not part of the MPIC lookup for the domain contact.
· An attacker could perform a BGP hijack of the victim's MX server IP or its DNS resolution, serve the legitimate victim email address (which passes MPIC for the contact lookup), and still intercept the validation email.
· Similar attacks can target constructed email methods by hijacking the MX server.
o Though applying MPIC to MX record lookups would be an improvement to help protect against DNS-based attacks affecting email routing, but it would not protect against in-transit hijacks (e.g., vulnerabilities in SMTP traffic itself like opportunistic TLS downgrades) or post-mail-server delivery compromises (e.g., an attacker gaining unauthorized access to the recipient's mailbox via POP3/IMAP).
o Requiring multiple challenges to be sent from multiple addresses could also be considered a security improvement, but would likely work against agility goals and is expected to be undesirable due to subscriber inconvenience.
o The ability for email-based DCV methods to reliably satisfy DNSSEC checking expectations introduced by SC-085 is unclear, further emphasizing these methods as a “weak link.” Because of this concern, this ballot discourages use of email-based methods beginning the effective date of SC-085 (March 15, 2026).
· The in-scope methods represent an expanded attack surface to publicly-trusted TLS certificate issuance when compared to existing alternatives.
o These methods broaden the attack surface compared to “direct” validation methods like DNS TXT records or HTTP file challenges.
o Email validation involves a more complex chain of operations, including MX record lookups and resolution of mail server addresses, potentially involving third-party mail providers and their DNS infrastructure. Additional participants in the validation process should be seen as added risk.
o Using DNS TXT or CAA records to find a contact email address can introduce further DNS queries, each an additional vector for attack.
o Compromise at any point in this extended chain can lead to fraudulent certificate issuance. Direct DNS or HTTP challenges confine the attack surface primarily to the validated domain.
o Audits don’t meaningfully or completely evaluate the security of these services, even considering elements hosted directly by the CA subject to the audit’s scope, further calling into question their reliability.
· The in-scope methods inherit vulnerabilities from the underlying communication channels and associated service providers.
o The compromise of an email service provider (private or public), could potentially grant attackers access to any number of fraudulently issued certificates due to no fault of a CA Owner or subscriber.
o There are numerous examples of large-scale attacks on such services and providers. These attacks should be considered as becoming more prevalent, not less.
o It is also broadly understood by security professionals that many successful attacks are never publicly disclosed or may go undetected for considerable periods. This established pattern of attacks, combined with the strong and persistent motivations for adversaries to target email systems, makes the continued use of email-based DCV a concern for maintaining the security and integrity of the ecosystem.
o Email relies on opportunistic TLS and is susceptible to downgrade. Phone systems share similar inherent vulnerabilities like SIM Swapping and SS7 attacks (example).
o As evidenced in the WatchTowr report that motivated the sunset of methods relying on domain contact information via SC-080, vulnerabilities in these communication channels or associated service providers represent significant and convenient collateral impact.
· The in-scope methods represent a weaker binding to domain/IP control than existing alternatives.
o Email and phone-based DCV methods exhibit a "weak binding" as they only demonstrate that an applicant can interact with a communication medium associated with the domain, not necessarily direct administrative control over the domain's core infrastructure.
o Read access to an email inbox (e.g., ad...@example.com) or a phone number does not inherently equate to comprehensive control over DNS configuration, web server content, or policy authority for the domain.
o Email accounts are susceptible to compromise, unauthorized and unintended delegation, or mismanagement independently of the domain's core operational control.
· We presently have DCV methods (e.g., ACME-based DNS or HTTP challenges) that offer greater automation, scalability, security, and better align with subscriber agility needs, especially when considering decreasing certificate lifetimes. Similarly, the SCWG continues to develop new DCV methods that promote automation, agility, and subscriber convenience (e.g., SC-088).
For sunsetting methods that could be used in “crossover” attacks:
· The in-scope methods allow attackers to obtain fraudulent certificates that contain a domain name(s) they do not possess authoritative control.
· While the original scope of this ballot included a sunset for 3.2.2.5.3 (“Reverse Address Lookup”), it is instead planned for sunset in SC-091.
Benefits of adoption:
· Elevate overall security posture by directly addressing the "Weakest Link Principle" in our domain validation security chain, ensuring attackers cannot leverage less secure methods to compromise certificate issuance. So long as these inherently less secure and more susceptible methods remain available, they present a persistent, exploitable target for adversaries.
· Reduce risk of improper certificate issuance by sunsetting a method that enables "crossover" attacks, which are often made possible by IP reassignment, host header vulnerabilities, and reverse DNS vulnerabilities.
· Promote stronger validation integrity by ensuring that DCV relies on methods with a stronger binding to actual administrative control over a domain or IP address, increasing the consistency of trustworthiness of issued certificates.
· Simplify the threat space by removing phone and email-based DCV, which eliminates unnecessary dependencies on large and complex ecosystems with inherent challenges, risks and vulnerabilities.
· Increase agility by encouraging site owners to transition to modern DCV methods, creating opportunities for faster and more efficient certificate lifecycle management through automation.
· Create opportunities for innovation by promoting the development of new and improved DCV methods, fostering advancements that may further enhance the overall security and agility of the ecosystem.
· Promote simplicity by streamlining the list of approved DCV methods in the TLS BRs, reducing complexity for CAs, developers, auditors, and subscribers.
Proposed Key Dates:
The effective dates considered in this update are intended to allow subscribers and CA Owners relying on existing implementations of these methods to transition to alternatives.
· Effective March 15, 2026:
o Sunset method 3.2.2.4.8 (“IP Address”)
o Discourage use of email and phone-based methods.
· Effective March 15, 2027:
o Sunset method 3.2.2.4.16 ("Phone Contact with DNS TXT Record Phone Contact")
o Sunset method 3.2.2.4.17 ("Phone Contact with DNS CAA Phone Contact")
o Sunset method 3.2.2.5.2 ("Email, Fax, SMS, or Postal Mail to IP Address Contact")
o Sunset method 3.2.2.5.5 ("Phone Contact with IP Address Contact")
· Effective March 15, 2028:
o Sunset method 3.2.2.4.4 ("Constructed Email to Domain Contact")
o Sunset method 3.2.2.4.13 ("Email to DNS CAA Contact")
o Sunset method 3.2.2.4.14 ("Email to DNS TXT Contact")
Proposal Revision History:
· Version #1 (this version)
The following motion has been proposed by Ryan Dickson and Chris Clements of Google (Chrome Root Program) and endorsed by Ben Wilson (Mozilla) and Tim Callan (Sectigo).
— Motion Begins —
This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.1.5.
MODIFY the Baseline Requirements as specified in the following Redline:
— Motion Ends —
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (no less than 14 days)
· Start: 2025-10-24 11:15:00 ET
· End: 2025-11-12 16:14:59 ET
Vote for approval (7 days)
· Start: 2025-11-12 16:15:00 ET
· End: 2025-11-19 16:15:00 ET
--
Tim Hollebeek
DigiCert votes YES on SC-90.
-Tim
From: 'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Wednesday, November 12, 2025 4:15 PM
To: server...@groups.cabforum.org
Subject: [Servercert-wg] Voting Period Begins - Ballot SC-90: "Gradually sunset all remaining email-based, phone-based, and ‘crossover’ validation methods from Sections 3.2.2.4 and 3.2.2.5"
Purpose of Ballot SC-90:
This ballot proposes updates to the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (TLS BRs) to gradually sunset (1) all remaining email and phone-based domain and IP address validation methods from Sections 3.2.2.4 and 3.2.2.5 and (2) a validation method that enables “crossover” attacks as described by Henry Birge-Lee during the 24 July 2025 Validation Subcommittee Meeting.
Background:
Scope:
The following validation methods are proposed for a gradual sunset:
Methods relying on email and phone:
· 3.2.2.4.4 ("Constructed Email to Domain Contact")
· 3.2.2.4.13 ("Email to DNS CAA Contact")
· 3.2.2.4.14 ("Email to DNS TXT Contact")
· 3.2.2.4.16 ("Phone Contact with DNS TXT Record Phone Contact")
· 3.2.2.4.17 ("Phone Contact with DNS CAA Phone Contact")
· 3.2.2.5.2 ("Email, Fax, SMS, or Postal Mail to IP Address Contact")
· 3.2.2.5.5 ("Phone Contact with IP Address Contact")
Method that enable crossover attacks:
· 3.2.2.4.8 (“IP Address”)
Justification:
For sunsetting email and phone-based methods:
· The in-scope methods do not offer the stronger security assurances provided by the existing alternative methods currently detailed in the TLS BRs.
o For example, while MPIC (Ballot SC-067) can be applied to DNS lookups for email addresses sourced from DNS (e.g., Methods 3.2.2.4.13, 3.2.2.4.14), it does not prevent fraudulent issuance if the MX server's IP or its DNS resolution is hijacked, as the MX server address itself is not part of the MPIC lookup for the domain contact.
· An attacker could perform a BGP hijack of the victim's MX server IP or its DNS resolution, serve the legitimate victim email address (which passes MPIC for the contact lookup), and still intercept the validation email.
· Similar attacks can target constructed email methods by hijacking the MX server.
o Though applying MPIC to MX record lookups would be an improvement to help protect against DNS-based attacks affecting email routing, but it would not protect against in-transit hijacks (e.g., vulnerabilities in SMTP traffic itself like opportunistic TLS downgrades) or post-mail-server delivery compromises (e.g., an attacker gaining unauthorized access to the recipient's mailbox via POP3/IMAP).
o Requiring multiple challenges to be sent from multiple addresses could also be considered a security improvement, but would likely work against agility goals and is expected to be undesirable due to subscriber inconvenience.
o The ability for email-based DCV methods to reliably satisfy DNSSEC checking expectations introduced by SC-085 is unclear, further emphasizing these methods as a “weak link.” Because of this concern, this ballot discourages use of email-based methods beginning the effective date of SC-085 (March 15, 2026).
· The in-scope methods represent an expanded attack surface to publicly-trusted TLS certificate issuance when compared to existing alternatives.
o These methods broaden the attack surface compared to “direct” validation methods like DNS TXT records or HTTP file challenges.
o Email validation involves a more complex chain of operations, including MX record lookups and resolution of mail server addresses, potentially involving third-party mail providers and their DNS infrastructure. Additional participants in the validation process should be seen as added risk.
o Using DNS TXT or CAA records to find a contact email address can introduce further DNS queries, each an additional vector for attack.
o Compromise at any point in this extended chain can lead to fraudulent certificate issuance. Direct DNS or HTTP challenges confine the attack surface primarily to the validated domain.
o Audits don’t meaningfully or completely evaluate the security of these services, even considering elements hosted directly by the CA subject to the audit’s scope, further calling into question their reliability.
· The in-scope methods inherit vulnerabilities from the underlying communication channels and associated service providers.
o The compromise of an email service provider (private or public), could potentially grant attackers access to any number of fraudulently issued certificates due to no fault of a CA Owner or subscriber.
o There are numerous examples of large-scale attacks on such services and providers. These attacks should be considered as becoming more prevalent, not less.
o It is also broadly understood by security professionals that many successful attacks are never publicly disclosed or may go undetected for considerable periods. This established pattern of attacks, combined with the strong and persistent motivations for adversaries to target email systems, makes the continued use of email-based DCV a concern for maintaining the security and integrity of the ecosystem.
o Email relies on opportunistic TLS and is susceptible to downgrade. Phone systems share similar inherent vulnerabilities like SIM Swapping and SS7 attacks (example).
o As evidenced in the WatchTowr report that motivated the sunset of methods relying on domain contact information via SC-080, vulnerabilities in these communication channels or associated service providers represent significant and convenient collateral impact.
· The in-scope methods represent a weaker binding to domain/IP control than existing alternatives.
o Email and phone-based DCV methods exhibit a "weak binding" as they only demonstrate that an applicant can interact with a communication medium associated with the domain, not necessarily direct administrative control over the domain's core infrastructure.
o Read access to an email inbox (e.g., ad...@example.com) or a phone number does not inherently equate to comprehensive control over DNS configuration, web server content, or policy authority for the domain.
o Email accounts are susceptible to compromise, unauthorized and unintended delegation, or mismanagement independently of the domain's core operational control.
· We presently have DCV methods (e.g., ACME-based DNS or HTTP challenges) that offer greater automation, scalability, security, and better align with subscriber agility needs, especially when considering decreasing certificate lifetimes. Similarly, the SCWG continues to develop new DCV methods that promote automation, agility, and subscriber convenience (e.g., SC-088).
For sunsetting methods that could be used in “crossover” attacks:
· The in-scope methods allow attackers to obtain fraudulent certificates that contain a domain name(s) they do not possess authoritative control.
· While the original scope of this ballot included a sunset for 3.2.2.5.3 (“Reverse Address Lookup”), it is instead planned for sunset in SC-091.
Benefits of adoption:
· Elevate overall security posture by directly addressing the "Weakest Link Principle" in our domain validation security chain, ensuring attackers cannot leverage less secure methods to compromise certificate issuance. So long as these inherently less secure and more susceptible methods remain available, they present a persistent, exploitable target for adversaries.
· Reduce risk of improper certificate issuance by sunsetting a method that enables "crossover" attacks, which are often made possible by IP reassignment, host header vulnerabilities, and reverse DNS vulnerabilities.
· Promote stronger validation integrity by ensuring that DCV relies on methods with a stronger binding to actual administrative control over a domain or IP address, increasing the consistency of trustworthiness of issued certificates.
· Simplify the threat space by removing phone and email-based DCV, which eliminates unnecessary dependencies on large and complex ecosystems with inherent challenges, risks and vulnerabilities.
· Increase agility by encouraging site owners to transition to modern DCV methods, creating opportunities for faster and more efficient certificate lifecycle management through automation.
· Create opportunities for innovation by promoting the development of new and improved DCV methods, fostering advancements that may further enhance the overall security and agility of the ecosystem.
· Promote simplicity by streamlining the list of approved DCV methods in the TLS BRs, reducing complexity for CAs, developers, auditors, and subscribers.
Proposed Key Dates:
The effective dates considered in this update are intended to allow subscribers and CA Owners relying on existing implementations of these methods to transition to alternatives.
· Effective March 15, 2026:
o Sunset method 3.2.2.4.8 (“IP Address”)
o Discourage use of email and phone-based methods.
· Effective March 15, 2027:
o Sunset method 3.2.2.4.16 ("Phone Contact with DNS TXT Record Phone Contact")
o Sunset method 3.2.2.4.17 ("Phone Contact with DNS CAA Phone Contact")
o Sunset method 3.2.2.5.2 ("Email, Fax, SMS, or Postal Mail to IP Address Contact")
o Sunset method 3.2.2.5.5 ("Phone Contact with IP Address Contact")
· Effective March 15, 2028:
o Sunset method 3.2.2.4.4 ("Constructed Email to Domain Contact")
o Sunset method 3.2.2.4.13 ("Email to DNS CAA Contact")
o Sunset method 3.2.2.4.14 ("Email to DNS TXT Contact")
Proposal Revision History:
· Version #1 (this version)
The following motion has been proposed by Ryan Dickson and Chris Clements of Google (Chrome Root Program) and endorsed by Ben Wilson (Mozilla) and Tim Callan (Sectigo).
— Motion Begins —
This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.1.5.
MODIFY the Baseline Requirements as specified in the following Redline:
— Motion Ends —
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (no less than 14 days)
· Start: 2025-10-24 11:15:00 ET
· End: 2025-11-12 16:14:59 ET
Vote for approval (7 days)
· Start: 2025-11-12 16:15:00 ET
· End: 2025-11-19 16:15:00 ET
--
Aaron Poulsen
Purpose of Ballot SC-90:
This ballot proposes updates to the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (TLS BRs) to gradually sunset (1) all remaining email and phone-based domain and IP address validation methods from Sections 3.2.2.4 and 3.2.2.5 and (2) a validation method that enables “crossover” attacks as described by Henry Birge-Lee during the 24 July 2025 Validation Subcommittee Meeting.
Background:
Scope:
The following validation methods are proposed for a gradual sunset:
Methods relying on email and phone:
3.2.2.4.4 ("Constructed Email to Domain Contact")
3.2.2.4.13 ("Email to DNS CAA Contact")
3.2.2.4.14 ("Email to DNS TXT Contact")
3.2.2.4.16 ("Phone Contact with DNS TXT Record Phone Contact")
3.2.2.4.17 ("Phone Contact with DNS CAA Phone Contact")
3.2.2.5.2 ("Email, Fax, SMS, or Postal Mail to IP Address Contact")
3.2.2.5.5 ("Phone Contact with IP Address Contact")
Method that enable crossover attacks:
3.2.2.4.8 (“IP Address”)
Justification:
For sunsetting email and phone-based methods:
The in-scope methods do not offer the stronger security assurances provided by the existing alternative methods currently detailed in the TLS BRs.
For example, while MPIC (Ballot SC-067) can be applied to DNS lookups for email addresses sourced from DNS (e.g., Methods 3.2.2.4.13, 3.2.2.4.14), it does not prevent fraudulent issuance if the MX server's IP or its DNS resolution is hijacked, as the MX server address itself is not part of the MPIC lookup for the domain contact.
An attacker could perform a BGP hijack of the victim's MX server IP or its DNS resolution, serve the legitimate victim email address (which passes MPIC for the contact lookup), and still intercept the validation email.
Similar attacks can target constructed email methods by hijacking the MX server.
Though applying MPIC to MX record lookups would be an improvement to help protect against DNS-based attacks affecting email routing, but it would not protect against in-transit hijacks (e.g., vulnerabilities in SMTP traffic itself like opportunistic TLS downgrades) or post-mail-server delivery compromises (e.g., an attacker gaining unauthorized access to the recipient's mailbox via POP3/IMAP).
Requiring multiple challenges to be sent from multiple addresses could also be considered a security improvement, but would likely work against agility goals and is expected to be undesirable due to subscriber inconvenience.
The ability for email-based DCV methods to reliably satisfy DNSSEC checking expectations introduced by SC-085 is unclear, further emphasizing these methods as a “weak link.” Because of this concern, this ballot discourages use of email-based methods beginning the effective date of SC-085 (March 15, 2026).
The in-scope methods represent an expanded attack surface to publicly-trusted TLS certificate issuance when compared to existing alternatives.
These methods broaden the attack surface compared to “direct” validation methods like DNS TXT records or HTTP file challenges.
Email validation involves a more complex chain of operations, including MX record lookups and resolution of mail server addresses, potentially involving third-party mail providers and their DNS infrastructure. Additional participants in the validation process should be seen as added risk.
Using DNS TXT or CAA records to find a contact email address can introduce further DNS queries, each an additional vector for attack.
Compromise at any point in this extended chain can lead to fraudulent certificate issuance. Direct DNS or HTTP challenges confine the attack surface primarily to the validated domain.
Audits don’t meaningfully or completely evaluate the security of these services, even considering elements hosted directly by the CA subject to the audit’s scope, further calling into question their reliability.
The in-scope methods inherit vulnerabilities from the underlying communication channels and associated service providers.
The compromise of an email service provider (private or public), could potentially grant attackers access to any number of fraudulently issued certificates due to no fault of a CA Owner or subscriber.
There are numerous examples of large-scale attacks on such services and providers. These attacks should be considered as becoming more prevalent, not less.
It is also broadly understood by security professionals that many successful attacks are never publicly disclosed or may go undetected for considerable periods. This established pattern of attacks, combined with the strong and persistent motivations for adversaries to target email systems, makes the continued use of email-based DCV a concern for maintaining the security and integrity of the ecosystem.
Email relies on opportunistic TLS and is susceptible to downgrade. Phone systems share similar inherent vulnerabilities like SIM Swapping and SS7 attacks (example).
As evidenced in the WatchTowr report that motivated the sunset of methods relying on domain contact information via SC-080, vulnerabilities in these communication channels or associated service providers represent significant and convenient collateral impact.
The in-scope methods represent a weaker binding to domain/IP control than existing alternatives.
Email and phone-based DCV methods exhibit a "weak binding" as they only demonstrate that an applicant can interact with a communication medium associated with the domain, not necessarily direct administrative control over the domain's core infrastructure.
Read access to an email inbox (e.g., ad...@example.com) or a phone number does not inherently equate to comprehensive control over DNS configuration, web server content, or policy authority for the domain.
Email accounts are susceptible to compromise, unauthorized and unintended delegation, or mismanagement independently of the domain's core operational control.
We presently have DCV methods (e.g., ACME-based DNS or HTTP challenges) that offer greater automation, scalability, security, and better align with subscriber agility needs, especially when considering decreasing certificate lifetimes. Similarly, the SCWG continues to develop new DCV methods that promote automation, agility, and subscriber convenience (e.g., SC-088).
For sunsetting methods that could be used in “crossover” attacks:
The in-scope methods allow attackers to obtain fraudulent certificates that contain a domain name(s) they do not possess authoritative control.
While the original scope of this ballot included a sunset for 3.2.2.5.3 (“Reverse Address Lookup”), it is instead planned for sunset in SC-091.
Benefits of adoption:
Elevate overall security posture by directly addressing the "Weakest Link Principle" in our domain validation security chain, ensuring attackers cannot leverage less secure methods to compromise certificate issuance. So long as these inherently less secure and more susceptible methods remain available, they present a persistent, exploitable target for adversaries.
Reduce risk of improper certificate issuance by sunsetting a method that enables "crossover" attacks, which are often made possible by IP reassignment, host header vulnerabilities, and reverse DNS vulnerabilities.
Promote stronger validation integrity by ensuring that DCV relies on methods with a stronger binding to actual administrative control over a domain or IP address, increasing the consistency of trustworthiness of issued certificates.
Simplify the threat space by removing phone and email-based DCV, which eliminates unnecessary dependencies on large and complex ecosystems with inherent challenges, risks and vulnerabilities.
Increase agility by encouraging site owners to transition to modern DCV methods, creating opportunities for faster and more efficient certificate lifecycle management through automation.
Create opportunities for innovation by promoting the development of new and improved DCV methods, fostering advancements that may further enhance the overall security and agility of the ecosystem.
Promote simplicity by streamlining the list of approved DCV methods in the TLS BRs, reducing complexity for CAs, developers, auditors, and subscribers.
Proposed Key Dates:
The effective dates considered in this update are intended to allow subscribers and CA Owners relying on existing implementations of these methods to transition to alternatives.
Effective March 15, 2026:
Sunset method 3.2.2.4.8 (“IP Address”)
Discourage use of email and phone-based methods.
Effective March 15, 2027:
Sunset method 3.2.2.4.16 ("Phone Contact with DNS TXT Record Phone Contact")
Sunset method 3.2.2.4.17 ("Phone Contact with DNS CAA Phone Contact")
Sunset method 3.2.2.5.2 ("Email, Fax, SMS, or Postal Mail to IP Address Contact")
Sunset method 3.2.2.5.5 ("Phone Contact with IP Address Contact")
Effective March 15, 2028:
Sunset method 3.2.2.4.4 ("Constructed Email to Domain Contact")
Sunset method 3.2.2.4.13 ("Email to DNS CAA Contact")
Sunset method 3.2.2.4.14 ("Email to DNS TXT Contact")
jun....@cybertrust.co.jp
-----Original Message-----
From: 'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Subject: [Servercert-wg] Voting Period Begins - Ballot SC-90: "Gradually sunset all remaining email-based, phone-based, and ‘crossover’ validation methods from Sections 3.2.2.4 and 3.2.2.5"
Purpose of Ballot SC-90:
Background:
Scope:
The following validation methods are proposed for a gradual sunset:
Methods relying on email and phone:
* 3.2.2.4.13 <https://cabforum.org/working-groups/server/baseline-requirements/requirements/#322413-email-to-dns-caa-contact> ("Email to DNS CAA Contact")
* 3.2.2.4.14 <https://cabforum.org/working-groups/server/baseline-requirements/requirements/#322414-email-to-dns-txt-contact> ("Email to DNS TXT Contact")
* 3.2.2.4.16 <https://cabforum.org/working-groups/server/baseline-requirements/requirements/#322416-phone-contact-with-dns-txt-record-phone-contact> ("Phone Contact with DNS TXT Record Phone Contact")
* 3.2.2.4.17 <https://cabforum.org/working-groups/server/baseline-requirements/requirements/#322417-phone-contact-with-dns-caa-phone-contact> ("Phone Contact with DNS CAA Phone Contact")
* 3.2.2.5.2 <https://cabforum.org/working-groups/server/baseline-requirements/requirements/#32252-email-fax-sms-or-postal-mail-to-ip-address-contact> ("Email, Fax, SMS, or Postal Mail to IP Address Contact")
* 3.2.2.5.5 <https://cabforum.org/working-groups/server/baseline-requirements/requirements/#32255-phone-contact-with-ip-address-contact> ("Phone Contact with IP Address Contact")
Method that enable crossover attacks:
Justification:
For sunsetting email and phone-based methods:
* For example, while MPIC (Ballot SC-067 <https://cabforum.org/2024/08/05/ballot-sc067v3-require-domain-validation-and-caa-checks-to-be-performed-from-multiple-network-perspectives-corroboration/> ) can be applied to DNS lookups for email addresses sourced from DNS (e.g., Methods 3.2.2.4.13, 3.2.2.4.14), it does not prevent fraudulent issuance if the MX server's IP or its DNS resolution is hijacked, as the MX server address itself is not part of the MPIC lookup for the domain contact.
* An attacker could perform a BGP hijack of the victim's MX server IP or its DNS resolution, serve the legitimate victim email address (which passes MPIC for the contact lookup), and still intercept the validation email.
* Similar attacks can target constructed email methods by hijacking the MX server.
* Though applying MPIC to MX record lookups would be an improvement to help protect against DNS-based attacks affecting email routing, but it would not protect against in-transit hijacks (e.g., vulnerabilities in SMTP traffic itself like opportunistic TLS downgrades <https://conferences2.sigcomm.org/imc/2015/papers/p27.pdf> ) or post-mail-server delivery compromises (e.g., an attacker gaining unauthorized access to the recipient's mailbox via POP3/IMAP).
* Requiring multiple challenges to be sent from multiple addresses could also be considered a security improvement, but would likely work against agility goals and is expected to be undesirable due to subscriber inconvenience.
* The ability for email-based DCV methods to reliably satisfy DNSSEC checking expectations introduced by SC-085 <https://cabforum.org/2025/06/18/ballot-sc-085v2-require-validation-of-dnssec-when-present-for-caa-and-dcv-lookups/> is unclear <https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/ZR0P278MB01708F040851FCAA255AFC2EFA30A%40ZR0P278MB0170.CHEP278.PROD.OUTLOOK.COM?utm_medium=email&utm_source=footer> , further emphasizing these methods as a “weak link.” Because of this concern, this ballot discourages use of email-based methods beginning the effective date of SC-085 (March 15, 2026).
* The in-scope methods represent an expanded attack surface to publicly-trusted TLS certificate issuance when compared to existing alternatives.
* These methods broaden the attack surface compared to “direct” validation methods like DNS TXT records or HTTP file challenges.
* Email validation involves a more complex chain of operations, including MX record lookups and resolution of mail server addresses, potentially involving third-party mail providers and their DNS infrastructure. Additional participants in the validation process should be seen as added risk.
* Using DNS TXT or CAA records to find a contact email address can introduce further DNS queries, each an additional vector for attack.
* Compromise at any point in this extended chain can lead to fraudulent certificate issuance. Direct DNS or HTTP challenges confine the attack surface primarily to the validated domain.
* Audits don’t meaningfully or completely evaluate the security of these services, even considering elements hosted directly by the CA subject to the audit’s scope, further calling into question their reliability.
* The in-scope methods inherit vulnerabilities from the underlying communication channels and associated service providers.
* The compromise of an email service provider (private or public), could potentially grant attackers access to any number of fraudulently issued certificates due to no fault of a CA Owner or subscriber.
* There are numerous <https://en.wikipedia.org/wiki/Yahoo_data_breaches> examples <https://www.justice.gov/archives/opa/pr/department-justice-statement-solarwinds-update> of <https://en.wikipedia.org/wiki/2021_Microsoft_Exchange_Server_data_breach> large-scale <https://msrc.microsoft.com/blog/2024/03/update-on-microsoft-actions-following-attack-by-nation-state-actor-midnight-blizzard/#:~:text=Update%20on%20Microsoft%20Actions%20Following,Blog%20%7C%20Microsoft%20Security%20Response%20Center> attacks <https://blog.google/threat-analysis-group/protecting-users-government-backed-hacking-and-disinformation/> on such services <https://mailchimp.com/newsroom/january-2023-security-incident/> and providers. These attacks should be considered as becoming more prevalent, not less.
* It is also broadly understood by security professionals that many successful attacks are never publicly disclosed or may go undetected for considerable periods. This established pattern of attacks, combined with the strong and persistent motivations for adversaries to target email systems, makes the continued use of email-based DCV a concern for maintaining the security and integrity of the ecosystem.
* Email relies on opportunistic TLS <https://en.wikipedia.org/wiki/Opportunistic_TLS> and is susceptible to downgrade <https://conferences2.sigcomm.org/imc/2015/papers/p27.pdf> . Phone systems share similar inherent vulnerabilities like SIM Swapping <https://www.enisa.europa.eu/news/enisa-news/beware-of-the-sim-swapping-fraud> and SS7 <https://en.wikipedia.org/wiki/Signalling_System_No._7> attacks (example <https://www.forbes.com/sites/parmyolson/2015/10/14/hackers-mobile-network-backbone-ss7/> ).
* As evidenced in the WatchTowr report <https://labs.watchtowr.com/we-spent-20-to-achieve-rce-and-accidentally-became-the-admins-of-mobi/> that motivated the sunset of methods relying on domain contact information via SC-080 <https://cabforum.org/2024/11/14/ballot-sc080v3-sunset-the-use-of-whois-to-identify-domain-contacts-and-relying-dcv-methods/> , vulnerabilities in these communication channels or associated service providers represent significant and convenient collateral impact.
* The in-scope methods represent a weaker binding to domain/IP control than existing alternatives.
* Email and phone-based DCV methods exhibit a "weak binding" as they only demonstrate that an applicant can interact with a communication medium associated with the domain, not necessarily direct administrative control over the domain's core infrastructure.
* Read access to an email inbox (e.g., ad...@example.com <mailto:ad...@example.com> ) or a phone number does not inherently equate to comprehensive control over DNS configuration, web server content, or policy authority for the domain.
* Email accounts are susceptible to compromise, unauthorized and unintended delegation, or mismanagement independently of the domain's core operational control.
* We presently have DCV methods (e.g., ACME-based DNS or HTTP challenges) that offer greater automation, scalability, security, and better align with subscriber agility needs, especially when considering decreasing certificate lifetimes. Similarly, the SCWG continues to develop new DCV methods that promote automation, agility, and subscriber convenience (e.g., SC-088 <https://cabforum.org/2025/10/09/ballot-sc-088v3-dns-txt-record-with-persistent-value-dcv-method/> ).
For sunsetting methods that could be used in “crossover” attacks:
* While the original scope of this ballot included a sunset for 3.2.2.5.3 (“Reverse Address Lookup”), it is instead planned for sunset in SC-091 <https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CAHidiLEVdLOcAkhzT%3Dz3-4-TnOjfLQSjeTf8ztuVw25pjrkGjg%40mail.gmail.com?utm_medium=email&utm_source=footer> .
Benefits of adoption:
* Elevate overall security posture by directly addressing the "Weakest Link Principle" in our domain validation security chain, ensuring attackers cannot leverage less secure methods to compromise certificate issuance. So long as these inherently less secure and more susceptible methods remain available, they present a persistent, exploitable target for adversaries.
* Reduce risk of improper certificate issuance by sunsetting a method that enables "crossover <https://groups.google.com/a/groups.cabforum.org/d/msgid/validation/cf60cd18-3f58-4d5f-818a-770cd6450514n%40groups.cabforum.org?utm_medium=email&utm_source=footer> " attacks, which are often made possible by IP reassignment, host header vulnerabilities, and reverse DNS vulnerabilities.
* Promote stronger validation integrity by ensuring that DCV relies on methods with a stronger binding to actual administrative control over a domain or IP address, increasing the consistency of trustworthiness of issued certificates.
* Simplify the threat space by removing phone and email-based DCV, which eliminates unnecessary dependencies on large and complex ecosystems with inherent challenges, risks and vulnerabilities.
* Increase agility by encouraging site owners to transition to modern DCV methods, creating opportunities for faster and more efficient certificate lifecycle management through automation.
* Create opportunities for innovation by promoting the development of new and improved DCV methods, fostering advancements that may further enhance the overall security and agility of the ecosystem.
* Promote simplicity by streamlining the list of approved DCV methods in the TLS BRs, reducing complexity for CAs, developers, auditors, and subscribers.
Proposed Key Dates:
The effective dates considered in this update are intended to allow subscribers and CA Owners relying on existing implementations of these methods to transition to alternatives.
* Sunset method 3.2.2.4.8 (“IP Address”)
* Discourage use of email and phone-based methods.
* Effective March 15, 2027:
* Sunset method 3.2.2.4.16 ("Phone Contact with DNS TXT Record Phone Contact")
* Sunset method 3.2.2.4.17 ("Phone Contact with DNS CAA Phone Contact")
* Sunset method 3.2.2.5.2 ("Email, Fax, SMS, or Postal Mail to IP Address Contact")
* Sunset method 3.2.2.5.5 ("Phone Contact with IP Address Contact")
* Effective March 15, 2028:
* Sunset method 3.2.2.4.4 ("Constructed Email to Domain Contact")
* Sunset method 3.2.2.4.13 ("Email to DNS CAA Contact")
* Sunset method 3.2.2.4.14 ("Email to DNS TXT Contact")
Proposal Revision History:
* Version #1 (this version)
The following motion has been proposed by Ryan Dickson and Chris Clements of Google (Chrome Root Program) and endorsed by Ben Wilson (Mozilla) and Tim Callan (Sectigo).
This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.1.5.
MODIFY the Baseline Requirements as specified in the following Redline:
? Motion Ends ?
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (no less than 14 days)
* End: 2025-11-12 16:14:59 ET
Vote for approval (7 days)
* End: 2025-11-19 16:15:00 ET
--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CADEW5O97dHokb783ZaFVVh-CVbydrw_tjJ0Hf3KD2%2BU745Omfg%40mail.gmail.com <https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CADEW5O97dHokb783ZaFVVh-CVbydrw_tjJ0Hf3KD2%2BU745Omfg%40mail.gmail.com?utm_medium=email&utm_source=footer> .
Yoshihiko Matsuo
Yoshihiko Matsuo(JPRS)
On Wed, 12 Nov 2025 16:14:57 -0500
"'Ryan Dickson' via Server Certificate WG (CA/B Forum)" <server...@groups.cabforum.org> wrote:
> Purpose of Ballot SC-90:
>
> Background:
>
>
> Scope:
>
>
> The following validation methods are proposed for a gradual sunset:
>
>
> Methods relying on email and phone:
> <https://cabforum.org/working-groups/server/baseline-requirements/requirements/#322413-email-to-dns-caa-contact>3.2.2.4.13 ("Email to DNS CAA Contact")
> <https://cabforum.org/working-groups/server/baseline-requirements/requirements/#322414-email-to-dns-txt-contact>3.2.2.4.14 ("Email to DNS TXT Contact")
> <https://cabforum.org/working-groups/server/baseline-requirements/requirements/#322416-phone-contact-with-dns-txt-record-phone-contact>3.2.2.4.16 ("Phone Contact with DNS TXT Record Phone Contact")
> <https://cabforum.org/working-groups/server/baseline-requirements/requirements/#322417-phone-contact-with-dns-caa-phone-contact>3.2.2.4.17 ("Phone Contact with DNS CAA Phone Contact")
> <https://cabforum.org/working-groups/server/baseline-requirements/requirements/#32252-email-fax-sms-or-postal-mail-to-ip-address-contact>3.2.2.5.2 ("Email, Fax, SMS, or Postal Mail to IP Address Contact")
> <https://cabforum.org/working-groups/server/baseline-requirements/requirements/#32255-phone-contact-with-ip-address-contact>3.2.2.5.5 ("Phone Contact with IP Address Contact")
>
> Method that enable crossover attacks:
>
> Justification:
>
>
> For sunsetting email and phone-based methods:
>
>
> For example, while MPIC (<https://cabforum.org/2024/08/05/ballot-sc067v3-require-domain-validation-and-caa-checks-to-be-performed-from-multiple-network-perspectives-corroboration/>Ballot SC-067) can be applied to DNS lookups for email addresses sourced from DNS (e.g., Methods 3.2.2.4.13, 3.2.2.4.14), it does not prevent fraudulent issuance if the MX server's IP or its DNS resolution is hijacked, as the MX server address itself is not part of the MPIC lookup for the domain contact.
>
> The in-scope methods represent an expanded attack surface to publicly-trusted TLS certificate issuance when compared to existing alternatives.
>
>
> There are <https://en.wikipedia.org/wiki/Yahoo_data_breaches>numerous <https://www.justice.gov/archives/opa/pr/department-justice-statement-solarwinds-update>examples <https://en.wikipedia.org/wiki/2021_Microsoft_Exchange_Server_data_breach>of <https://msrc.microsoft.com/blog/2024/03/update-on-microsoft-actions-following-attack-by-nation-state-actor-midnight-blizzard/#:~:text=Update%20on%20Microsoft%20Actions%20Following,Blog%20%7C%20Microsoft%20Security%20Response%20Center>large-scale <https://blog.google/threat-analysis-group/protecting-users-government-backed-hacking-and-disinformation/>attacks on such <https://mailchimp.com/newsroom/january-2023-security-incident/>services and providers. These attacks should be considered as becoming more prevalent, not less.?
> As evidenced in the WatchTowr <https://labs.watchtowr.com/we-spent-20-to-achieve-rce-and-accidentally-became-the-admins-of-mobi/>report that motivated the sunset of methods relying on domain contact information via <https://cabforum.org/2024/11/14/ballot-sc080v3-sunset-the-use-of-whois-to-identify-domain-contacts-and-relying-dcv-methods/>SC-080, vulnerabilities in these communication channels or associated service providers represent significant and convenient collateral impact.??
>
> The in-scope methods represent a weaker binding to domain/IP control than existing alternatives.
>
>
>
> For sunsetting methods that could be used in “crossover” attacks:
>
>
>
>
> Benefits of adoption:
>
> Elevate overall security posture by directly addressing the "Weakest Link Principle" in our domain validation security chain, ensuring attackers cannot leverage less secure methods to compromise certificate issuance. So long as these inherently less secure and more susceptible methods remain available, they present a persistent, exploitable target for adversaries.
>
>
> Proposed Key Dates:
>
>
> The effective dates considered in this update are intended to allow subscribers and CA Owners relying on existing implementations of these methods to transition to alternatives.
>
>
>
>
>
>
>
>
> Proposal Revision History:
>
>
> The following motion has been proposed by Ryan Dickson and Chris Clements of Google (Chrome Root Program) and endorsed by Ben Wilson (Mozilla) and Tim Callan (Sectigo).
>
>
> ? Motion Begins ?
>
>
> This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.1.5.
>
>
> MODIFY the Baseline Requirements as specified in the following Redline:
>
>
> <https://github.com/cabforum/servercert/compare/e9176e15805a2f7908411a22a40047b655fa24c4..321efb50c89a2dbe6533ba6c8df84d2d9184044a>https://github.com/cabforum/servercert/compare/e9176e15805a2f7908411a22a40047b655fa24c4..321efb50c89a2dbe6533ba6c8df84d2d9184044a?
>
>
> ? Motion Ends ?
>
>
> This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
>
>
> Discussion (no less than 14 days)
>
>
> Vote for approval (7 days)
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
> To view this discussion visit <https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CADEW5O97dHokb783ZaFVVh-CVbydrw_tjJ0Hf3KD2%2BU745Omfg%40mail.gmail.com?utm_medium=email&utm_source=footer>https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CADEW5O97dHokb783ZaFVVh-CVbydrw_tjJ0Hf3KD2%2BU745Omfg%40mail.gmail.com.
Dimitris Zacharopoulos (HARICA)
Purpose of Ballot SC-90:
This ballot proposes updates to the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (TLS BRs) to gradually sunset (1) all remaining email and phone-based domain and IP address validation methods from Sections 3.2.2.4 and 3.2.2.5 and (2) a validation method that enables “crossover” attacks as described by Henry Birge-Lee during the 24 July 2025 Validation Subcommittee Meeting.
Background:
Scope:
The following validation methods are proposed for a gradual sunset:
Methods relying on email and phone:
3.2.2.4.4 ("Constructed Email to Domain Contact")
3.2.2.4.13 ("Email to DNS CAA Contact")
3.2.2.4.14 ("Email to DNS TXT Contact")
3.2.2.4.16 ("Phone Contact with DNS TXT Record Phone Contact")
3.2.2.4.17 ("Phone Contact with DNS CAA Phone Contact")
3.2.2.5.2 ("Email, Fax, SMS, or Postal Mail to IP Address Contact")
3.2.2.5.5 ("Phone Contact with IP Address Contact")
Method that enable crossover attacks:
3.2.2.4.8 (“IP Address”)
Justification:
For sunsetting email and phone-based methods:
The in-scope methods do not offer the stronger security assurances provided by the existing alternative methods currently detailed in the TLS BRs.
For example, while MPIC (Ballot SC-067) can be applied to DNS lookups for email addresses sourced from DNS (e.g., Methods 3.2.2.4.13, 3.2.2.4.14), it does not prevent fraudulent issuance if the MX server's IP or its DNS resolution is hijacked, as the MX server address itself is not part of the MPIC lookup for the domain contact.
An attacker could perform a BGP hijack of the victim's MX server IP or its DNS resolution, serve the legitimate victim email address (which passes MPIC for the contact lookup), and still intercept the validation email.
Similar attacks can target constructed email methods by hijacking the MX server.
Though applying MPIC to MX record lookups would be an improvement to help protect against DNS-based attacks affecting email routing, but it would not protect against in-transit hijacks (e.g., vulnerabilities in SMTP traffic itself like opportunistic TLS downgrades) or post-mail-server delivery compromises (e.g., an attacker gaining unauthorized access to the recipient's mailbox via POP3/IMAP).
Requiring multiple challenges to be sent from multiple addresses could also be considered a security improvement, but would likely work against agility goals and is expected to be undesirable due to subscriber inconvenience.
The ability for email-based DCV methods to reliably satisfy DNSSEC checking expectations introduced by SC-085 is unclear, further emphasizing these methods as a “weak link.” Because of this concern, this ballot discourages use of email-based methods beginning the effective date of SC-085 (March 15, 2026).
The in-scope methods represent an expanded attack surface to publicly-trusted TLS certificate issuance when compared to existing alternatives.
These methods broaden the attack surface compared to “direct” validation methods like DNS TXT records or HTTP file challenges.
Email validation involves a more complex chain of operations, including MX record lookups and resolution of mail server addresses, potentially involving third-party mail providers and their DNS infrastructure. Additional participants in the validation process should be seen as added risk.
Using DNS TXT or CAA records to find a contact email address can introduce further DNS queries, each an additional vector for attack.
Compromise at any point in this extended chain can lead to fraudulent certificate issuance. Direct DNS or HTTP challenges confine the attack surface primarily to the validated domain.
Audits don’t meaningfully or completely evaluate the security of these services, even considering elements hosted directly by the CA subject to the audit’s scope, further calling into question their reliability.
The in-scope methods inherit vulnerabilities from the underlying communication channels and associated service providers.
The compromise of an email service provider (private or public), could potentially grant attackers access to any number of fraudulently issued certificates due to no fault of a CA Owner or subscriber.
There are numerous examples of large-scale attacks on such services and providers. These attacks should be considered as becoming more prevalent, not less.
It is also broadly understood by security professionals that many successful attacks are never publicly disclosed or may go undetected for considerable periods. This established pattern of attacks, combined with the strong and persistent motivations for adversaries to target email systems, makes the continued use of email-based DCV a concern for maintaining the security and integrity of the ecosystem.
Email relies on opportunistic TLS and is susceptible to downgrade. Phone systems share similar inherent vulnerabilities like SIM Swapping and SS7 attacks (example).
As evidenced in the WatchTowr report that motivated the sunset of methods relying on domain contact information via SC-080, vulnerabilities in these communication channels or associated service providers represent significant and convenient collateral impact.
The in-scope methods represent a weaker binding to domain/IP control than existing alternatives.
Email and phone-based DCV methods exhibit a "weak binding" as they only demonstrate that an applicant can interact with a communication medium associated with the domain, not necessarily direct administrative control over the domain's core infrastructure.
Read access to an email inbox (e.g., ad...@example.com) or a phone number does not inherently equate to comprehensive control over DNS configuration, web server content, or policy authority for the domain.
Email accounts are susceptible to compromise, unauthorized and unintended delegation, or mismanagement independently of the domain's core operational control.
We presently have DCV methods (e.g., ACME-based DNS or HTTP challenges) that offer greater automation, scalability, security, and better align with subscriber agility needs, especially when considering decreasing certificate lifetimes. Similarly, the SCWG continues to develop new DCV methods that promote automation, agility, and subscriber convenience (e.g., SC-088).
For sunsetting methods that could be used in “crossover” attacks:
The in-scope methods allow attackers to obtain fraudulent certificates that contain a domain name(s) they do not possess authoritative control.
While the original scope of this ballot included a sunset for 3.2.2.5.3 (“Reverse Address Lookup”), it is instead planned for sunset in SC-091.
Benefits of adoption:
Elevate overall security posture by directly addressing the "Weakest Link Principle" in our domain validation security chain, ensuring attackers cannot leverage less secure methods to compromise certificate issuance. So long as these inherently less secure and more susceptible methods remain available, they present a persistent, exploitable target for adversaries.
Reduce risk of improper certificate issuance by sunsetting a method that enables "crossover" attacks, which are often made possible by IP reassignment, host header vulnerabilities, and reverse DNS vulnerabilities.
Promote stronger validation integrity by ensuring that DCV relies on methods with a stronger binding to actual administrative control over a domain or IP address, increasing the consistency of trustworthiness of issued certificates.
Simplify the threat space by removing phone and email-based DCV, which eliminates unnecessary dependencies on large and complex ecosystems with inherent challenges, risks and vulnerabilities.
Increase agility by encouraging site owners to transition to modern DCV methods, creating opportunities for faster and more efficient certificate lifecycle management through automation.
Create opportunities for innovation by promoting the development of new and improved DCV methods, fostering advancements that may further enhance the overall security and agility of the ecosystem.
Promote simplicity by streamlining the list of approved DCV methods in the TLS BRs, reducing complexity for CAs, developers, auditors, and subscribers.
Proposed Key Dates:
The effective dates considered in this update are intended to allow subscribers and CA Owners relying on existing implementations of these methods to transition to alternatives.
Effective March 15, 2026:
Sunset method 3.2.2.4.8 (“IP Address”)
Discourage use of email and phone-based methods.
Effective March 15, 2027:
Sunset method 3.2.2.4.16 ("Phone Contact with DNS TXT Record Phone Contact")
Sunset method 3.2.2.4.17 ("Phone Contact with DNS CAA Phone Contact")
Sunset method 3.2.2.5.2 ("Email, Fax, SMS, or Postal Mail to IP Address Contact")
Sunset method 3.2.2.5.5 ("Phone Contact with IP Address Contact")
Effective March 15, 2028:
Sunset method 3.2.2.4.4 ("Constructed Email to Domain Contact")
Sunset method 3.2.2.4.13 ("Email to DNS CAA Contact")
Sunset method 3.2.2.4.14 ("Email to DNS TXT Contact")
Proposal Revision History:
Version #1 (this version)
The following motion has been proposed by Ryan Dickson and Chris Clements of Google (Chrome Root Program) and endorsed by Ben Wilson (Mozilla) and Tim Callan (Sectigo).
— Motion Begins —
This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.1.5.
MODIFY the Baseline Requirements as specified in the following Redline:
— Motion Ends —
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (no less than 14 days)
Start: 2025-10-24 11:15:00 ET
End: 2025-11-12 16:14:59 ET
Vote for approval (7 days)
Start: 2025-11-12 16:15:00 ET
End: 2025-11-19 16:15:00 ET
--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
Entschew, Enrico
D-Trust votes YES on Ballot SC-90.
Thanks,
Enrico
Von: 'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Gesendet: Mittwoch, 12. November 2025 22:15
An: server...@groups.cabforum.org
Betreff: [Servercert-wg] Voting Period Begins - Ballot SC-90: "Gradually sunset all remaining email-based, phone-based, and ‘crossover’ validation methods from Sections 3.2.2.4 and 3.2.2.5"
Purpose of Ballot SC-90:
This ballot proposes updates to the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (TLS BRs) to gradually sunset (1) all remaining email and phone-based domain and IP address validation methods from Sections 3.2.2.4 and 3.2.2.5 and (2) a validation method that enables “crossover” attacks as described by Henry Birge-Lee during the 24 July 2025 Validation Subcommittee Meeting.
Background:
Scope:
The following validation methods are proposed for a gradual sunset:
Methods relying on email and phone:
· 3.2.2.4.4 ("Constructed Email to Domain Contact")
· 3.2.2.4.13 ("Email to DNS CAA Contact")
· 3.2.2.4.14 ("Email to DNS TXT Contact")
· 3.2.2.4.16 ("Phone Contact with DNS TXT Record Phone Contact")
· 3.2.2.4.17 ("Phone Contact with DNS CAA Phone Contact")
· 3.2.2.5.2 ("Email, Fax, SMS, or Postal Mail to IP Address Contact")
· 3.2.2.5.5 ("Phone Contact with IP Address Contact")
Method that enable crossover attacks:
· 3.2.2.4.8 (“IP Address”)
Justification:
For sunsetting email and phone-based methods:
· The in-scope methods do not offer the stronger security assurances provided by the existing alternative methods currently detailed in the TLS BRs.
o For example, while MPIC (Ballot SC-067) can be applied to DNS lookups for email addresses sourced from DNS (e.g., Methods 3.2.2.4.13, 3.2.2.4.14), it does not prevent fraudulent issuance if the MX server's IP or its DNS resolution is hijacked, as the MX server address itself is not part of the MPIC lookup for the domain contact.
· An attacker could perform a BGP hijack of the victim's MX server IP or its DNS resolution, serve the legitimate victim email address (which passes MPIC for the contact lookup), and still intercept the validation email.
· Similar attacks can target constructed email methods by hijacking the MX server.
o Though applying MPIC to MX record lookups would be an improvement to help protect against DNS-based attacks affecting email routing, but it would not protect against in-transit hijacks (e.g., vulnerabilities in SMTP traffic itself like opportunistic TLS downgrades) or post-mail-server delivery compromises (e.g., an attacker gaining unauthorized access to the recipient's mailbox via POP3/IMAP).
o Requiring multiple challenges to be sent from multiple addresses could also be considered a security improvement, but would likely work against agility goals and is expected to be undesirable due to subscriber inconvenience.
o The ability for email-based DCV methods to reliably satisfy DNSSEC checking expectations introduced by SC-085 is unclear, further emphasizing these methods as a “weak link.” Because of this concern, this ballot discourages use of email-based methods beginning the effective date of SC-085 (March 15, 2026).
· The in-scope methods represent an expanded attack surface to publicly-trusted TLS certificate issuance when compared to existing alternatives.
o These methods broaden the attack surface compared to “direct” validation methods like DNS TXT records or HTTP file challenges.
o Email validation involves a more complex chain of operations, including MX record lookups and resolution of mail server addresses, potentially involving third-party mail providers and their DNS infrastructure. Additional participants in the validation process should be seen as added risk.
o Using DNS TXT or CAA records to find a contact email address can introduce further DNS queries, each an additional vector for attack.
o Compromise at any point in this extended chain can lead to fraudulent certificate issuance. Direct DNS or HTTP challenges confine the attack surface primarily to the validated domain.
o Audits don’t meaningfully or completely evaluate the security of these services, even considering elements hosted directly by the CA subject to the audit’s scope, further calling into question their reliability.
· The in-scope methods inherit vulnerabilities from the underlying communication channels and associated service providers.
o The compromise of an email service provider (private or public), could potentially grant attackers access to any number of fraudulently issued certificates due to no fault of a CA Owner or subscriber.
o There are numerous examples of large-scale attacks on such services and providers. These attacks should be considered as becoming more prevalent, not less.
o It is also broadly understood by security professionals that many successful attacks are never publicly disclosed or may go undetected for considerable periods. This established pattern of attacks, combined with the strong and persistent motivations for adversaries to target email systems, makes the continued use of email-based DCV a concern for maintaining the security and integrity of the ecosystem.
o Email relies on opportunistic TLS and is susceptible to downgrade. Phone systems share similar inherent vulnerabilities like SIM Swapping and SS7 attacks (example).
o As evidenced in the WatchTowr report that motivated the sunset of methods relying on domain contact information via SC-080, vulnerabilities in these communication channels or associated service providers represent significant and convenient collateral impact.
· The in-scope methods represent a weaker binding to domain/IP control than existing alternatives.
o Email and phone-based DCV methods exhibit a "weak binding" as they only demonstrate that an applicant can interact with a communication medium associated with the domain, not necessarily direct administrative control over the domain's core infrastructure.
o Read access to an email inbox (e.g., ad...@example.com) or a phone number does not inherently equate to comprehensive control over DNS configuration, web server content, or policy authority for the domain.
o Email accounts are susceptible to compromise, unauthorized and unintended delegation, or mismanagement independently of the domain's core operational control.
· We presently have DCV methods (e.g., ACME-based DNS or HTTP challenges) that offer greater automation, scalability, security, and better align with subscriber agility needs, especially when considering decreasing certificate lifetimes. Similarly, the SCWG continues to develop new DCV methods that promote automation, agility, and subscriber convenience (e.g., SC-088).
For sunsetting methods that could be used in “crossover” attacks:
· The in-scope methods allow attackers to obtain fraudulent certificates that contain a domain name(s) they do not possess authoritative control.
· While the original scope of this ballot included a sunset for 3.2.2.5.3 (“Reverse Address Lookup”), it is instead planned for sunset in SC-091.
Benefits of adoption:
· Elevate overall security posture by directly addressing the "Weakest Link Principle" in our domain validation security chain, ensuring attackers cannot leverage less secure methods to compromise certificate issuance. So long as these inherently less secure and more susceptible methods remain available, they present a persistent, exploitable target for adversaries.
· Reduce risk of improper certificate issuance by sunsetting a method that enables "crossover" attacks, which are often made possible by IP reassignment, host header vulnerabilities, and reverse DNS vulnerabilities.
· Promote stronger validation integrity by ensuring that DCV relies on methods with a stronger binding to actual administrative control over a domain or IP address, increasing the consistency of trustworthiness of issued certificates.
· Simplify the threat space by removing phone and email-based DCV, which eliminates unnecessary dependencies on large and complex ecosystems with inherent challenges, risks and vulnerabilities.
· Increase agility by encouraging site owners to transition to modern DCV methods, creating opportunities for faster and more efficient certificate lifecycle management through automation.
· Create opportunities for innovation by promoting the development of new and improved DCV methods, fostering advancements that may further enhance the overall security and agility of the ecosystem.
· Promote simplicity by streamlining the list of approved DCV methods in the TLS BRs, reducing complexity for CAs, developers, auditors, and subscribers.
Proposed Key Dates:
The effective dates considered in this update are intended to allow subscribers and CA Owners relying on existing implementations of these methods to transition to alternatives.
· Effective March 15, 2026:
o Sunset method 3.2.2.4.8 (“IP Address”)
o Discourage use of email and phone-based methods.
· Effective March 15, 2027:
o Sunset method 3.2.2.4.16 ("Phone Contact with DNS TXT Record Phone Contact")
o Sunset method 3.2.2.4.17 ("Phone Contact with DNS CAA Phone Contact")
o Sunset method 3.2.2.5.2 ("Email, Fax, SMS, or Postal Mail to IP Address Contact")
o Sunset method 3.2.2.5.5 ("Phone Contact with IP Address Contact")
· Effective March 15, 2028:
o Sunset method 3.2.2.4.4 ("Constructed Email to Domain Contact")
o Sunset method 3.2.2.4.13 ("Email to DNS CAA Contact")
o Sunset method 3.2.2.4.14 ("Email to DNS TXT Contact")
Proposal Revision History:
· Version #1 (this version)
The following motion has been proposed by Ryan Dickson and Chris Clements of Google (Chrome Root Program) and endorsed by Ben Wilson (Mozilla) and Tim Callan (Sectigo).
— Motion Begins —
This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.1.5.
MODIFY the Baseline Requirements as specified in the following Redline:
— Motion Ends —
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (no less than 14 days)
· Start: 2025-10-24 11:15:00 ET
· End: 2025-11-12 16:14:59 ET
Vote for approval (7 days)
· Start: 2025-11-12 16:15:00 ET
· End: 2025-11-19 16:15:00 ET