Skip to content

SC-090: "Gradually sunset all remaining email-based, phone-based, and ‘crossover’ validation methods from Sections 3.2.2.4 and 3.2.2.5" #616

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
dzacharo merged 9 commits into from
Jan 12, 2026
Merged

SC-090: "Gradually sunset all remaining email-based, phone-based, and ‘crossover’ validation methods from Sections 3.2.2.4 and 3.2.2.5" #616

Changes from all commits
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
a646f9e
Update BR.md
ryancdickson Jul 7, 2025
628a08a
Remove lingering sunset methods from SC-080
ryancdickson Jul 18, 2025
3e55c38
Update BR.md
ryancdickson Jul 24, 2025
eb04984
Update BR.md
ryancdickson Jul 24, 2025
587e973
Update BR.md
ryancdickson Aug 28, 2025
321efb5
Update BR.md
ryancdickson Oct 24, 2025
1186655
Merge branch 'main' into sunset-email-phone
dzacharo Nov 20, 2025
3680fd9
Merge branch 'main' into sunset-email-phone
dzacharo Jan 12, 2026
6b20e63
Prepare BRs 2.2.2
dzacharo Jan 12, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
118 changes: 63 additions & 55 deletions docs/BR.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,14 +1,14 @@
---
title: Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates

subtitle: Version 2.2.1
subtitle: Version 2.2.2
author:
- CA/Browser Forum

date: 16-December-2025
date: 12-January-2026

copyright: |
Copyright 2025 CA/Browser Forum
Copyright 2026 CA/Browser Forum

This work is licensed under the Creative Commons Attribution 4.0 International license.
---
Expand Down Expand Up @@ -153,9 +153,10 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse
| 2.1.7 | SC089 | Mass Revocation Planning | 23-Jul-2025 | 25-Aug-2025 |
| 2.1.8 | SC092 | Sunset Precertificate Signing CAs | 03-Oct-2025 | 04-Nov-2025 |
| 2.1.9 | SC088 | DNS TXT Record with Persistent Value DCV Method | 09-Oct-2025 | 10-Nov-2025 |
| 2.2.0 | SC086 | Sunset the Inclusion of Address and Routing Parameter Area Names | 2025-11-13 | 2026-12-15 |
| 2.2.1 | SC091 | Sunset 3.2.2.5.3 Reverse Address Lookup Validation, | 2025-11-13 | 2026-12-16 |
| 2.2.1 | SC091 | new DNS-based validation using Persistent DCV TXT Record for IP addresses | 2025-11-13 | 2026-12-16 |
| 2.2.0 | SC086 | Sunset the Inclusion of Address and Routing Parameter Area Names | 2025-11-13 | 2025-12-15 |
| 2.2.1 | SC091 | Sunset 3.2.2.5.3 Reverse Address Lookup Validation, | 2025-11-13 | 2025-12-16 |
| 2.2.1 | SC091 | new DNS-based validation using Persistent DCV TXT Record for IP addresses | 2025-11-13 | 2025-12-16 |
| 2.2.2 | SC090 | Gradually sunset remaining email-based, phone-based, and 'crossover' validation methods | 2025-11-20 | 2026-01-12 |

\* Effective Date and Additionally Relevant Compliance Date(s)

Expand Down Expand Up @@ -217,6 +218,7 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse
| 2025-12-01 | 5.7.1.2 | CAs SHALL assert in section 5.7.1 of their CPS or combined CP/CPS their mass revocation plan, testing, and continuous improvements. |
| 2026-03-15 | 3.2.2.4 | DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with the validation of domain authorization or control by the Primary Network |
| 2026-03-15 | 3.2.2.4 | CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated with the validation of domain authorization or control. |
| 2026-03-15 | 3.2.2.4 | CAs MUST NOT rely on Method 3.2.2.4.8 to issue Subscriber Certificates. |
| 2026-03-15 | 3.2.2.8.1 | DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with CAA record lookups performed by the Primary Network Perspective. |
| 2026-03-15 | 3.2.2.8.1 | CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated CAA record lookups. |
| 2026-03-15 | 3.2.2.8.1 | DNSSEC-validation errors observed by the Primary Network Perspective (e.g., SERVFAIL) MUST NOT be treated as permission to issue. |
Expand All @@ -225,9 +227,11 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse
| 2026-03-15 | 4.2.1 | Domain Name and IP Address validation maximum data reuse period is 200 days. |
| 2026-03-15 | 6.3.2 | Maximum validity period of Subscriber Certificates is 200 days. |
| 2026-03-15 | 7.1.2.4 | CAs MUST NOT use Precertificate Signing CAs to issue Precertificates. CAs MUST NOT issue certificates using the Technically Constrained Precertificate Signing CA Certificate Profile specified in Section 7.1.2.4. |
| 2027-03-15 | 3.2.2.4 and 3.2.2.5 | CAs MUST NOT rely on Methods 3.2.2.4.16, 3.2.2.4.17, 3.2.2.5.2, and 3.2.2.5.5 to issue Subscriber Certificates. |
| 2027-03-15 | 3.2.2.5.3 | CAs MUST NOT rely on Method 3.2.2.5.3 to issue Subscriber Certificates. |
| 2027-03-15 | 4.2.1 | Domain Name and IP Address validation maximum data reuse period is 100 days. |
| 2027-03-15 | 6.3.2 | Maximum validity period of Subscriber Certificates is 100 days. |
| 2028-03-15 | 3.2.2.4 and 3.2.2.5 | CAs MUST NOT rely on Methods 3.2.2.4.4, 3.2.2.4.13, and 3.2.2.4.14 to issue Subscriber Certificates. |
| 2029-03-15 | 4.2.1 | Domain Name and IP Address validation maximum data reuse period is 10 days. |
| 2029-03-15 | 6.3.2 | Maximum validity period of Subscriber Certificates is 47 days. |

Expand Down Expand Up @@ -794,30 +798,7 @@ This method has been retired and MUST NOT be used. Prior validations using this

##### 3.2.2.4.2 Email, Fax, SMS, or Postal Mail to Domain Contact

Confirming the Applicant's control over the FQDN by sending a Random Value via email, fax, SMS, or postal mail and then receiving a confirming response utilizing the Random Value. The Random Value MUST be sent to an email address, fax/SMS number, or postal mail address identified as a Domain Contact.

Each email, fax, SMS, or postal mail MAY confirm control of multiple Authorization Domain Names.

The CA MAY send the email, fax, SMS, or postal mail identified under this section to more than one recipient provided that every recipient is identified by the Domain Name Registrar as representing the Domain Name Registrant for every FQDN being verified using the email, fax, SMS, or postal mail.

The Random Value SHALL be unique in each email, fax, SMS, or postal mail.

The CA MAY resend the email, fax, SMS, or postal mail in its entirety, including re-use of the Random Value, provided that the communication's entire contents and recipient(s) remain unchanged.

The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values, in which case the CA MUST follow its CPS.

**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names.

Effective January 15, 2025:
- When issuing Subscriber Certificates, the CA MUST NOT rely on Domain Contact information obtained using an HTTPS website, regardless of whether previously obtained information is within the allowed reuse period.
- When obtaining Domain Contact information for a requested Domain Name the CA:
- if using the WHOIS protocol (RFC 3912), MUST query IANA's WHOIS server and follow referrals to the appropriate WHOIS server.
- if using the Registry Data Access Protocol (RFC 7482), MUST utilize IANA's bootstrap file to identify and query the correct RDAP server for the domain.
- MUST NOT rely on cached 1) WHOIS server information that is more than 48 hours old, or 2) RDAP bootstrap data from IANA that is more than 48 hours old, to ensure that it relies upon up-to-date and accurate information.

Effective July 15, 2025:
- The CA MUST NOT rely on this method.
- Prior validations using this method and validation data gathered according to this method MUST NOT be used to issue Subscriber Certificates.
This method has been retired and MUST NOT be used. Prior validations using this method and validation data gathered according to this method SHALL NOT be used to issue certificates.

##### 3.2.2.4.3 Phone Contact with Domain Contact

Expand All @@ -841,6 +822,12 @@ The Random Value SHALL remain valid for use in a confirming response for no more

**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names.

Effective March 15, 2026, this method SHOULD NOT be used to issue Subscriber Certificates.

Effective March 15, 2028:
- The CA MUST NOT rely on this method.
- Prior validations using this method and validation data gathered according to this method MUST NOT be used to issue Subscriber Certificates.

##### 3.2.2.4.5 Domain Authorization Document

This method has been retired and MUST NOT be used. Prior validations using this method and validation data gathered according to this method SHALL NOT be used to issue certificates.
Expand Down Expand Up @@ -874,6 +861,10 @@ CAs performing validations using this method MUST implement Multi-Perspective Is

**Note**: Once the FQDN has been validated using this method, the CA MUST NOT issue Certificates for other FQDNs that end with all the labels of the validated FQDN unless the CA performs separate validations for each of those other FQDNs using authorized methods. This method is NOT suitable for validating Wildcard Domain Names.

Effective March 15, 2026:
- The CA MUST NOT rely on this method.
- Prior validations using this method and validation data gathered according to this method MUST NOT be used to issue Subscriber Certificates.

##### 3.2.2.4.9 Test Certificate

This method has been retired and MUST NOT be used. Prior validations using this method and validation data gathered according to this method SHALL NOT be used to issue certificates.
Expand All @@ -892,12 +883,12 @@ Confirming the Applicant's control over the FQDN by validating the Applicant is

**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names.

Effective January 15, 2025:
- When issuing Subscriber Certificates, the CA MUST NOT rely on Domain Contact information obtained using an HTTPS website, regardless of whether previously obtained information is within the allowed reuse period.
- When obtaining Domain Contact information for a requested Domain Name the CA:
- if using the WHOIS protocol (RFC 3912), MUST query IANA's WHOIS server and follow referrals to the appropriate WHOIS server.
- if using the Registry Data Access Protocol (RFC 7482), MUST utilize IANA's bootstrap file to identify and query the correct RDAP server for the domain.
- MUST NOT rely on cached 1) WHOIS server information that is more than 48 hours old, or 2) RDAP bootstrap data from IANA that is more than 48 hours old, to ensure that it relies upon up-to-date and accurate information.
When issuing Subscriber Certificates, the CA MUST NOT rely on Domain Contact information obtained using an HTTPS website, regardless of whether previously obtained information is within the allowed reuse period.

When obtaining Domain Contact information for a requested Domain Name the CA:
- if using the WHOIS protocol (RFC 3912), MUST query IANA's WHOIS server and follow referrals to the appropriate WHOIS server.
- if using the Registry Data Access Protocol (RFC 7482), MUST utilize IANA's bootstrap file to identify and query the correct RDAP server for the domain.
- MUST NOT rely on cached 1) WHOIS server information that is more than 48 hours old, or 2) RDAP bootstrap data from IANA that is more than 48 hours old, to ensure that it relies upon up-to-date and accurate information.

##### 3.2.2.4.13 Email to DNS CAA Contact

Expand All @@ -911,6 +902,12 @@ CAs performing validations using this method MUST implement Multi-Perspective Is

**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names.

Effective March 15, 2026, this method SHOULD NOT be used to issue Subscriber Certificates.

Effective March 15, 2028:
- The CA MUST NOT rely on this method.
- Prior validations using this method and validation data gathered according to this method MUST NOT be used to issue Subscriber Certificates.

##### 3.2.2.4.14 Email to DNS TXT Contact

Confirming the Applicant's control over the FQDN by sending a Random Value via email and then receiving a confirming response utilizing the Random Value. The Random Value MUST be sent to a DNS TXT Record Email Contact for the Authorization Domain Name selected to validate the FQDN.
Expand All @@ -923,29 +920,16 @@ CAs performing validations using this method MUST implement Multi-Perspective Is

**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names.

##### 3.2.2.4.15 Phone Contact with Domain Contact

Confirm the Applicant's control over the FQDN by calling the Domain Contact’s phone number and obtain a confirming response to validate the ADN. Each phone call MAY confirm control of multiple ADNs provided that the same Domain Contact phone number is listed for each ADN being verified and they provide a confirming response for each ADN.

In the event that someone other than a Domain Contact is reached, the CA MAY request to be transferred to the Domain Contact.

In the event of reaching voicemail, the CA may leave the Random Value and the ADN(s) being validated. The Random Value MUST be returned to the CA to approve the request.

The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values.

**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names.

Effective January 15, 2025:
- When issuing Subscriber Certificates, the CA MUST NOT rely on Domain Contact information obtained using an HTTPS website, regardless of whether previously obtained information is within the allowed reuse period.
- When obtaining Domain Contact information for a requested Domain Name the CA:
- if using the WHOIS protocol (RFC 3912), MUST query IANA's WHOIS server and follow referrals to the appropriate WHOIS server.
- if using the Registry Data Access Protocol (RFC 7482), MUST utilize IANA's bootstrap file to identify and query the correct RDAP server for the domain.
- MUST NOT rely on cached 1) WHOIS server information that is more than 48 hours old, or 2) RDAP bootstrap data from IANA that is more than 48 hours old, to ensure that it relies upon up-to-date and accurate information.
Effective March 15, 2026, this method SHOULD NOT be used to issue Subscriber Certificates.

Effective July 15, 2025:
Effective March 15, 2028:
- The CA MUST NOT rely on this method.
- Prior validations using this method and validation data gathered according to this method MUST NOT be used to issue Subscriber Certificates.

##### 3.2.2.4.15 Phone Contact with Domain Contact

This method has been retired and MUST NOT be used. Prior validations using this method and validation data gathered according to this method SHALL NOT be used to issue certificates.

##### 3.2.2.4.16 Phone Contact with DNS TXT Record Phone Contact

Confirm the Applicant's control over the FQDN by calling the DNS TXT Record Phone Contact’s phone number and obtain a confirming response to validate the ADN. Each phone call MAY confirm control of multiple ADNs provided that the same DNS TXT Record Phone Contact phone number is listed for each ADN being verified and they provide a confirming response for each ADN.
Expand All @@ -960,6 +944,12 @@ CAs performing validations using this method MUST implement Multi-Perspective Is

**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names.

Effective March 15, 2026, this method SHOULD NOT be used to issue Subscriber Certificates.

Effective March 15, 2027:
- The CA MUST NOT rely on this method.
- Prior validations using this method and validation data gathered according to this method MUST NOT be used to issue Subscriber Certificates.

##### 3.2.2.4.17 Phone Contact with DNS CAA Phone Contact

Confirm the Applicant's control over the FQDN by calling the DNS CAA Phone Contact’s phone number and obtain a confirming response to validate the ADN. Each phone call MAY confirm control of multiple ADNs provided that the same DNS CAA Phone Contact phone number is listed for each ADN being verified and they provide a confirming response for each ADN. The relevant CAA Resource Record Set MUST be found using the search algorithm defined in RFC 8659 Section 3.
Expand All @@ -974,6 +964,12 @@ CAs performing validations using this method MUST implement Multi-Perspective Is

**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names.

Effective March 15, 2026, this method SHOULD NOT be used to issue Subscriber Certificates.

Effective March 15, 2027:
- The CA MUST NOT rely on this method.
- Prior validations using this method and validation data gathered according to this method MUST NOT be used to issue Subscriber Certificates.

##### 3.2.2.4.18 Agreed-Upon Change to Website v2

Confirming the Applicant's control over the FQDN by verifying that the Request Token or Random Value is contained in the contents of a file.
Expand Down Expand Up @@ -1115,6 +1111,12 @@ The CA MAY resend the email, fax, SMS, or postal mail in its entirety, including

The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values, in which case the CA MUST follow its CPS.

Effective March 15, 2026, this method SHOULD NOT be used to issue Subscriber Certificates.

Effective March 15, 2027:
- The CA MUST NOT rely on this method.
- Prior validations using this method and validation data gathered according to this method MUST NOT be used to issue Subscriber Certificates.

##### 3.2.2.5.3 Reverse Address Lookup

Confirming the Applicant’s control over the IP Address by obtaining a Domain Name associated with the IP Address through a reverse-IP lookup on the IP Address and then verifying control over the FQDN using a method permitted under [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control).
Expand All @@ -1141,6 +1143,12 @@ In the event of reaching voicemail, the CA may leave the Random Value and the IP

The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values.

Effective March 15, 2026, this method SHOULD NOT be used to issue Subscriber Certificates.

Effective March 15, 2027:
- The CA MUST NOT rely on this method.
- Prior validations using this method and validation data gathered according to this method MUST NOT be used to issue Subscriber Certificates.

##### 3.2.2.5.6 ACME "http-01" method for IP Addresses

Confirming the Applicant's control over the IP Address by performing the procedure documented for an "http-01" challenge in RFC 8738.
Expand Down