[Servercert-wg] Discussion Period Begins - Ballot SC-080 V2: "Sunset the use of WHOIS to identify Domain Contacts and relying DCV Methods”
Ryan Dickson
This ballot proposes updates to the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (TLS BRs) to address concerns regarding the use of WHOIS and HTTPS websites for identifying Domain Contacts.
Background:
This ballot intends to accomplish two objectives, originally described in [1].
Justification:
- A recent disclosure [2] demonstrated how threat actors could exploit deficiencies in the WHOIS protocol and WHOIS tools served via HTTPS websites to obtain fraudulent TLS certificates.
- Discussions within the Mozilla Dev Security Policy (MDSP) community [3] further expressed corresponding risks related to WHOIS, while also noting that ccTLDs may not maintain accurate or up-to-date WHOIS server records. Several examples of inoperative WHOIS servers for ccTLDs were identified.
- Discussion in [4] further called into question the reliability of ccTLD WHOIS servers given, per IANA, there is no global policy requirement for ccTLD managers to operate a WHOIS server, and if they do, what kind of information is provided.
- Solutions to strengthen existing WHOIS lookup methods were proposed in [5] and are considered in this ballot.
Justification:
- While solutions to strengthen WHOIS-relying DCV methods are considered in this ballot (see above), there is limited public evidence of significant reliance on these methods, including in response to [3] and [6].
- Instead, discussion has identified at least one CA Owner has already sunset reliance on WHOIS [7], and another that has changed its approach [8] for relying on WHOIS since disclosure of [2].
- More modern and heavily relied-upon DCV methods offer advantages over the existing WHOIS-based methods, including greater opportunity for seamless certificate lifecycle management automation (e.g., [9] and [10]), while also benefiting from recently improved security practices [11]. These methods can also more effectively align subscriber capabilities with agility and resilience expectations necessary to respond to the revocation timelines described in the TLS BRs [12].
- Beyond the above, previous discussions within the CA/Browser Forum have raised concerns about the perceived value (e.g., [13]) and security (e.g., [14]) of the DCV methods relying on WHOIS, further supporting the rationale for their gradual sunset.
Benefits of adoption:
- Enhanced Security: Eliminates reliance on outdated and vulnerable DCV methods that cannot consistently provide the security required by the TLS BRs, or benefit from recent DCV security enhancements (i.e., Multi-Perspective Issuance Corroboration [11]).
- Increased Agility: Encourages site owners to transition to modern DCV methods, creating opportunities for faster, more efficient, and less error-prone certificate lifecycle management.
- Opportunity for Innovation: Promotes the development of new and/or improved DCV methods, fostering innovation that may enhance the overall security and agility of the ecosystem.
Proposed Key Dates:
- January 15, 2025: (1) Prohibit the use of RFC 3912 (WHOIS) and HTTPS websites to identify Domain Contact information. (2) Prohibit the reuse of DCV relying on information obtained using these technologies. (3) Prohibit WHOIS-based DCV methods for Subscriber Certificates containing ccTLDs. (4) CAs MUST NOT rely on cached WHOIS/RDAP data more than 48 hours old.
- July 15, 2025: (1) Sunset DCV Methods 3.2.2.4.2 ("Email, Fax, SMS, or Postal Mail to Domain Contact") and 3.2.2.4.15 ("Phone Contact with Domain Contact"). (2) Prior validations using these methods and validation data gathered therein MUST NOT be used to issue new Subscriber Certificates.
Proposal Revision History:
- Pre-Ballot Version #1 [4]
- Ballot Version #1 [7]
- Version #2 Pre-Release [17] and discussion [18]
- Version #2 (this version) [19]
The following motion has been proposed by Ryan Dickson and Chris Clements of Google (Chrome Root Program) and endorsed by Arvid Vermote (GlobalSign) and Pedro Fuentes (OISTE).
— 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.0.7.
MODIFY the Baseline Requirements as specified in the following Redline:
https://github.com/cabforum/servercert/compare/ba28d04894d69c8fac62850b9d0de5061658c7c5..7f2b54cfa5b89f41458a88211566ce508c464804
— Motion Ends —
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (no less than 7 days)
- Start: 2024-10-01 17:00:00 UTC
- End no earlier than: 2024-10-08 17:00:00 UTC
Vote for approval (7 days)
- Start: TBD
- End: TBD
References:
[1] https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004900.html
[2] https://labs.watchtowr.com/we-spent-20-to-achieve-rce-and-accidentally-became-the-admins-of-mobi/
[3] https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/FuOi_uhQB6U/m/hKJOz3XzAAAJ
[4] https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/mAl9XjieSkA/m/oDNWxtPwAQAJ
[5] https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004839.html
[6] https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004844.html
[7] https://aws.amazon.com/blogs/security/aws-certificate-manager-will-discontinue-whois-lookup-for-email-validated-certificates/
[8] https://bugzilla.mozilla.org/show_bug.cgi?id=1917896
[9] https://cabforum.org/working-groups/server/baseline-requirements/requirements/#32247-dns-change
[10] https://cabforum.org/working-groups/server/baseline-requirements/requirements/#322419-agreed-upon-change-to-website---acme
[11] https://cabforum.org/working-groups/server/baseline-requirements/requirements/#3229-multi-perspective-issuance-corroboration
[12] https://cabforum.org/working-groups/server/baseline-requirements/requirements/#491-circumstances-for-revocation
[13] https://archive.cabforum.org/pipermail/servercert-wg/2018-August/000113.html
[14] https://lists.cabforum.org/pipermail/validation/2024-July/001995.html
[15] https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004825.html
[16] https://github.com/ryancdickson/staging/compare/356799f0dcfe11deb0a375a11233403236ab72c9..7a2ea7b33611bebf006a99a9a82729f183143eac
[17] https://github.com/ryancdickson/staging/compare/ba28d04894d69c8fac62850b9d0de5061658c7c5..7a2ea7b33611bebf006a99a9a82729f183143eac
[18] https://github.com/ryancdickson/staging/pull/9
[19] https://github.com/cabforum/servercert/pull/551
Backman, Antti
Hi,
As per my quick initial review of this ballot, one question / comment.
Should the relevant dates list the changes made to 3.2.2.4.12 coming effective Jan 15th, 2025? I believe the changes in the section are very relevant to CAs?
//Antti
Ryan Dickson
Thanks for your comment.
The proposed update contains an entry in the “Relevant Dates" Table that presents the following information:
Compliance: 2025-01-15
Sections: 3.2.2.4
Summary Description (See Full Text for Details): CAs MUST NOT rely on HTTPS websites to identify Domain Contact information. RFC 3912 and RFC 7482 MUST NOT be used to validate Domain Contact information of FQDNs containing a ccTLD. CAs MUST rely on IANA resources for identifying gTLD Domain Contact information.
In my opinion, the above offers a summary-level description of the detailed changes offered in Sections 3.2.2.4.2, 3.2.2.4.12, and 3.2.2.4.15.
If you have specific changes you’d like to suggest, please share them for the group’s consideration.
Thanks!
- Ryan
Backman, Antti
Hi Ryan
Thank you for your swift response. I missed that when (too) quickly took first glance on it. Yes this is just fine like you’ve drafted it, my bad.
//Antti
Doug Beattie
Hey Ryan,
The way I read the ballot is that using domain approver email addresses from SOA records is being removed since that’s part of 3.2.2.4.2. Should we add a new method specifically for that, or was the intent to remove that as a valid location to obtain domain approver email addresses?
Doug
Ryan Dickson
Hi Doug,
Your interpretation of the latest version of the ballot is correct.
As currently presented, Method 3.2.2.4.2 (“Email, Fax, SMS, or Postal Mail to Domain Contact”) and Method 3.2.2.4.15 (“Phone Contact with Domain Contact”) are sunset, in their entirety, effective July 15, 2025.
Specific to domain contact email addresses from SOA records, can you share your perspective for adding this specific option given the existence of (1) other email-based alternatives (e.g., 3.2.2.4.4, 3.2.2.4.13 and 3.2.2.4.14) and (2) other far more heavily relied upon DCV methods that present an opportunity for improved automation and scalability (and also benefit from MPIC)?
For example, detailing responses below would be helpful for understanding:
- existing reliance on this specific approach in comparison to the other DCV methods offered?
- how this reliance has trended over time (e.g., last 1 / 3 / 5 years)?
- how the sunset would affect subscribers?
- a general description of the level of effort for affected subscribers to transition to another method?
- what barriers exist that prevent subscribers from transitioning to other methods?
I think it’s reasonable for the community to approach RNAME lookups with the same degree of concern for accuracy and reliability as registration data due to the potential for:
- neglected configurations (e.g., in 2020, [1] indicated only 39.74% of a set of “top” 1M domains contained “reachable” SOA contacts, and only approximately 20% of the sampled .com and .net domains did).
- potential CA reliance on third-party tools with unknown operational characteristics for performing SOA lookups (the same concern as WHOIS lookups using HTTPS websites).
- a lack of oversight and enforcement for ensuring SOA record updates (e.g, accuracy/correctness and timeliness).
- use of automated DNS management solutions that can result in an unintended and/or unknown delegation of authority to approve TLS certificates, while also representing a single point of failure (or attack).
Thanks,
Ryan
Doug Beattie
Hi Ryan,
The title, purpose and background of this ballot define the removal of WHOIS and does not discuss any other changes, but we’re actually sunsetting other aspects of domain validation while also leaving method 3.2.2.4.12 that can continue to use WHOIS. Part of this is the unfortunately extremely broad definition of “Domain Contact” and “Domain Name Registrant” and the wide scope of 3.2.2.4.2, which I agree we need to clarify and fix. I understand the desire to remove WHOIS based on the recent incident(s), but if we’re going to focus on sunsetting WHOIS, we should 100% sunset if for all uses and we should not include the removal of other methods within this ballot. The VWG can be tasked to review methods we think are weak and discuss removing them, for example, imo, all the methods that rely on phone calls (Domain and IP address both), which to me are weaker than automated methods like using they SOA record.
Doug
From: Ryan Dickson <ryand...@google.com>
Sent: Friday, October 4, 2024 2:55 PM
To: Doug Beattie <doug.b...@globalsign.com>
Cc: CA/B Forum Server Certificate WG Public Discussion List <server...@cabforum.org>
Ryan Dickson
> The title, purpose and background of this ballot define the removal of WHOIS and does not discuss any other changes, but we’re actually sunsetting other aspects of domain validation while also leaving method 3.2.2.4.12 that can continue to use WHOIS.
Would changing the title to something like “Strengthen registration data lookups and Sunset Methods 3.2.2.4.2 and 3.2.2.4.15" help?
> I understand the desire to remove WHOIS based on the recent incident(s), but if we’re going to focus on sunsetting WHOIS, we should 100% sunset it for all uses and we should not include the removal of other methods within this ballot.
All methods relying on identifying Domain Contacts via registration data are strengthened by this ballot, beginning January 15, 2025. This includes methods:
- 3.2.2.4.2 (“Email, Fax, SMS, or Postal Mail to Domain Contact")
- 3.2.2.4.12 (“Validating Applicant as a Domain Contact")
- 3.2.2.4.15 (“Phone Contact with Domain Contact")
The ballot goes on to sunset the following methods, beginning July 15, 2025:
- 3.2.2.4.2 (“Email, Fax, SMS, or Postal Mail to Domain Contact")
- 3.2.2.4.15 (“Phone Contact with Domain Contact")
The only method relying on identifying a “Domain Contact" via registration data left by the ballot is 3.2.2.4.12 (“Validating Applicant as a Domain Contact"). This was originally excluded from the scope of sunsets given the expectation that in cases where the organization operating the CA was also the Domain Name Registrar (or an Affiliate), there would be (1) a lower likelihood of unreliable Domain Contact information given a direct relationship with the subscriber/subscriber organization, and (2) a higher potential for seamless certificate lifecycle management because of that relationship. Regardless of whether this expectation is misguided, nothing stops a future ballot from contemplating the further improvement or sunset of 3.2.2.4.12 (“Validating Applicant as a Domain Contact").
If there’s a case to make for including 3.2.2.4.12 in the sunsets covered in the proposal, it’s also welcome.
> The VWG can be tasked to review methods we think are weak and discuss removing them, for example, imo, all the methods that rely on phone calls (Domain and IP address both), which to me are weaker than automated methods like using they SOA record.
Periodically over the past three years (when I joined this community), I’ve participated in discussions where members have expressed a desire for improved DCV methods, which has included suggestions to remove perceived weak methods (with those that are phone or email-based cited as examples). While very few of these discussions have led to direct action, this ballot presents a proactive opportunity to address some of those concerns, along with mitigating concerns related to registration data lookups identified by recent events.
Thanks,
Ryan
Yoshihiko Matsuo
> The only method relying on identifying a “Domain Contact" via registration data left by the ballot is 3.2.2.4.12 (“Validating Applicant as a Domain Contact"). This was originally excluded from the scope of sunsets given the expectation that in cases where the organization operating the CA was also the Domain Name Registrar (or an Affiliate), there would be (1) a lower likelihood of unreliable Domain Contact information given a direct relationship with the subscriber/subscriber organization, and (2) a higher potential for seamless certificate lifecycle management because of that relationship. Regardless of whether this expectation is misguided, nothing stops a future ballot from contemplating the further improvement or sunset of 3.2.2.4.12 (“Validating Applicant as a Domain Contact").
We are the CA, and at the same time we are also the gTLD Registrar and the ccTLD Registry.
In this case, I understand that it is acceptable to use the Domain Contacts we hold as The gTLD Registrar for DCV.I would like to hear your opinions on whether the same can be said for the Domain Contacts we hold as the ccTLD Registry.
Note: We require that ccTLD Domain Contacts be kept current as the contact information for the domain name registrant.
With this question, I would like to clarify whether the BR allows the following cases.
1. The CA that is also the ccTLD Registry retrieves Domain Contacts from its own database and performs validation in accordance with 3.2.2.4.2.
2. The CA that is also the ccTLD Registry retrieves Domain Contacts from the WHOIS operated by the ccTLD Registry (which is also a CA) and performs validation in accordance with 3.2.2.4.2.
Thanks,
Yoshihiko Matsuo(JPRS)
On 2024/10/08 4:49, Ryan Dickson via Servercert-wg wrote:
> Hi Doug,
>
> > The title, purpose and background of this ballot define the removal of WHOIS and does not discuss any other changes, but we’re actually sunsetting other aspects of domain validation while also leaving method 3.2.2.4.12 that can continue to use WHOIS.
>
> I feel “Objective 2", included in the “Background" section, makes the intent to sunset methods clear (the objective's description is: "/Sunset Methods 3.2.2.4.2 (“Email, Fax, SMS, or Postal Mail to Domain Contact”) and 3.2.2.4.15 (“Phone Contact with Domain Contact")/").
>
> Would changing the title to something like “/Strengthen registration data lookups and Sunset Methods 3.2.2.4.2 and 3.2.2.4.15/" help?
>
> > I understand the desire to remove WHOIS based on the recent incident(s), but if we’re going to focus on sunsetting WHOIS, we should 100% sunset it for all uses and we should not include the removal of other methods within this ballot.
>
> All methods relying on identifying Domain Contacts via registration data are strengthened by this ballot, beginning January 15, 2025. This includes methods:
> - 3.2.2.4.2 (“Email, Fax, SMS, or Postal Mail to Domain Contact")
> - 3.2.2.4.12 (“Validating Applicant as a Domain Contact")
> - 3.2.2.4.15 (“Phone Contact with Domain Contact")
>
> The ballot goes on to sunset the following methods, beginning July 15, 2025:
> - 3.2.2.4.2 (“Email, Fax, SMS, or Postal Mail to Domain Contact")
> - 3.2.2.4.15 (“Phone Contact with Domain Contact")
>
> The only method relying on identifying a “Domain Contact" via registration data left by the ballot is 3.2.2.4.12 (“Validating Applicant as a Domain Contact"). This was originally excluded from the scope of sunsets given the expectation that in cases where the organization operating the CA was also the Domain Name Registrar (or an Affiliate), there would be (1) a lower likelihood of unreliable Domain Contact information given a direct relationship with the subscriber/subscriber organization, and (2) a higher potential for seamless certificate lifecycle management because of that relationship. Regardless of whether this expectation is misguided, nothing stops a future ballot from contemplating the further improvement or sunset of 3.2.2.4.12 (“Validating Applicant as a Domain Contact").
>
> If there’s a case to make for including 3.2.2.4.12 in the sunsets covered in the proposal, it’s also welcome.
>
> > The VWG can be tasked to review methods we think are weak and discuss removing them, for example, imo, all the methods that rely on phone calls (Domain and IP address both), which to me are weaker than automated methods like using they SOA record.
>
> I agree that it’s important for this community to routinely re-evaluate the DCV methods permitted by the TLS BRs and consider them against a set of desirable security and operational properties that best enable subscriber organizations to make securely managing their TLS implementations “boring" (effortless, routine, reliable, and without excitement - even when facing the unexpected).
>
> Periodically over the past three years (when I joined this community), I’ve participated in discussions where members have expressed a desire for improved DCV methods, which has included suggestions to remove perceived weak methods (with those that are phone or email-based cited as examples). While very few of these discussions have led to direct action, this ballot presents a proactive opportunity to address some of those concerns, along with mitigating concerns related to registration data lookups identified by recent events.
>
> I do not believe a holistic evaluation of the DCV-methods permitted by the TLS BRs needs to be a blocking function on this ballot, and that both activities can take place independently of one another.
>
> Thanks,
> Ryan
>
>
> On Mon, Oct 7, 2024 at 7:35 AM Doug Beattie <doug.b...@globalsign.com <mailto:doug.b...@globalsign.com>> wrote:
>
> Hi Ryan,____
>
> __ __
>
> The title, purpose and background of this ballot define the removal of WHOIS and does not discuss any other changes, but we’re actually sunsetting other aspects of domain validation while also leaving method 3.2.2.4.12 that can continue to use WHOIS. Part of this is the unfortunately extremely broad definition of “Domain Contact” and “Domain Name Registrant” and the wide scope of 3.2.2.4.2, which I agree we need to clarify and fix. I understand the desire to remove WHOIS based on the recent incident(s), but if we’re going to focus on sunsetting WHOIS, we should 100% sunset if for all uses and we should not include the removal of other methods within this ballot. The VWG can be tasked to review methods we think are weak and discuss removing them, for example, imo, all the methods that rely on phone calls (Domain and IP address both), which to me are weaker than automated methods like using they SOA record.____
>
> __ __
>
> Doug____
>
> __ __
>
> *From:*Ryan Dickson <ryand...@google.com <mailto:ryand...@google.com>>
> *Sent:* Friday, October 4, 2024 2:55 PM
> *To:* Doug Beattie <doug.b...@globalsign.com <mailto:doug.b...@globalsign.com>>
> *Cc:* CA/B Forum Server Certificate WG Public Discussion List <server...@cabforum.org <mailto:server...@cabforum.org>>
> *Subject:* Re: [Servercert-wg] Discussion Period Begins - Ballot SC-080 V2: "Sunset the use of WHOIS to identify Domain Contacts and relying DCV Methods”____
>
> __ __
>
> Hi Doug,____
>
> __ __
>
> Your interpretation of the latest version of the ballot is correct. ____
>
> __ __
>
> As currently presented, Method 3.2.2.4.2 (“Email, Fax, SMS, or Postal Mail to Domain Contact”) and Method 3.2.2.4.15 (“Phone Contact with Domain Contact”) are sunset, in their entirety, effective July 15, 2025. ____
>
> __ __
>
> Specific to domain contact email addresses from SOA records, can you share your perspective for adding this specific option given the existence of (1) other email-based alternatives (e.g., 3.2.2.4.4, 3.2.2.4.13 and 3.2.2.4.14) and (2) other far more heavily relied upon DCV methods that present an opportunity for improved automation and scalability (and also benefit from MPIC)?____
>
> __ __
>
> For example, detailing responses below would be helpful for understanding:____
>
> * existing reliance on this specific approach in comparison to the other DCV methods offered?____
> * how this reliance has trended over time (e.g., last 1 / 3 / 5 years)?____
> * how the sunset would affect subscribers?____
> * a general description of the level of effort for affected subscribers to transition to another method?____
> * what barriers exist that prevent subscribers from transitioning to other methods?____
>
> __ __
>
> I think it’s reasonable for the community to approach RNAME lookups with the same degree of concern for accuracy and reliability as registration data due to the potential for:____
>
> * neglected configurations (e.g., in 2020, [1] indicated only 39.74% of a set of “top” 1M domains contained “reachable” SOA contacts, and only approximately 20% of the sampled .com and .net domains did).____
> * potential CA reliance on third-party tools with unknown operational characteristics for performing SOA lookups (the same concern as WHOIS lookups using HTTPS websites).____
> * a lack of oversight and enforcement for ensuring SOA record updates (e.g, accuracy/correctness and timeliness).____
> * use of automated DNS management solutions that can result in an unintended and/or unknown delegation of authority to approve TLS certificates, while also representing a single point of failure (or attack).____
>
> __ __
>
> Thanks,____
>
> Ryan____
>
> __ __
>
> [1] https://mkorczynski.com/WTMC2020.pdf <https://mkorczynski.com/WTMC2020.pdf>____
>
> __ __
>
> __ __
>
> On Thu, Oct 3, 2024 at 9:57 AM Doug Beattie <doug.b...@globalsign.com <mailto:doug.b...@globalsign.com>> wrote:____
>
> Hey Ryan,____
>
> ____
>
> The way I read the ballot is that using domain approver email addresses from SOA records is being removed since that’s part of 3.2.2.4.2. Should we add a new method specifically for that, or was the intent to remove that as a valid location to obtain domain approver email addresses?____
>
>
> Doug____
>
> ____
>
> *From:*Servercert-wg <servercert...@cabforum.org <mailto:servercert...@cabforum.org>> *On Behalf Of *Ryan Dickson via Servercert-wg
> *Sent:* Tuesday, October 1, 2024 12:59 PM
> *To:* ServerCert CA/BF <server...@cabforum.org <mailto:server...@cabforum.org>>
> *Subject:* [Servercert-wg] Discussion Period Begins - Ballot SC-080 V2: "Sunset the use of WHOIS to identify Domain Contacts and relying DCV Methods”____
>
> ____
>
> *_Purpose of Ballot SC-080 V2:
> _*This ballot proposes updates to the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (TLS BRs) to address concerns regarding the use of WHOIS and HTTPS websites for identifying Domain Contacts.
>
> *_Background:
> _*This ballot intends to accomplish two objectives, originally described in [1].____
>
> Objective 1: Enhance WHOIS/RDAP validation of gTLDs with comparable security properties to DNS-based validation and sunset WHOIS/RDAP for ccTLDs.
>
> _Justification:_____
>
> * A recent disclosure [2] demonstrated how threat actors could exploit deficiencies in the WHOIS protocol and WHOIS tools served via HTTPS websites to obtain fraudulent TLS certificates.____
> * Discussions within the Mozilla Dev Security Policy (MDSP) community [3] further expressed corresponding risks related to WHOIS, while also noting that ccTLDs may not maintain accurate or up-to-date WHOIS server records. Several examples of inoperative WHOIS servers for ccTLDs were identified.____
> * Discussion in [4] further called into question the reliability of ccTLD WHOIS servers given, per IANA, there is no global policy requirement for ccTLD managers to operate a WHOIS server, and if they do, what kind of information is provided.____
> * Solutions to strengthen existing WHOIS lookup methods were proposed in [5] and are considered in this ballot.____
>
> ____
>
> Objective 2: Sunset Methods 3.2.2.4.2 (“Email, Fax, SMS, or Postal Mail to Domain Contact”) and 3.2.2.4.15 (“Phone Contact with Domain Contact”).
>
> _Justification:_____
>
> * While solutions to strengthen WHOIS-relying DCV methods are considered in this ballot (see above), there is limited public evidence of significant reliance on these methods, including in response to [3] and [6].____
> * Instead, discussion has identified at least one CA Owner has already sunset reliance on WHOIS [7], and another that has changed its approach [8] for relying on WHOIS since disclosure of [2].____
> * More modern and heavily relied-upon DCV methods offer advantages over the existing WHOIS-based methods, including greater opportunity for seamless certificate lifecycle management automation (e.g., [9] and [10]), while also benefiting from recently improved security practices [11]. These methods can also more effectively align subscriber capabilities with agility and resilience expectations necessary to respond to the revocation timelines described in the TLS BRs [12].____
> * Beyond the above, previous discussions within the CA/Browser Forum have raised concerns about the perceived value (e.g., [13]) and security (e.g., [14]) of the DCV methods relying on WHOIS, further supporting the rationale for their gradual sunset.____
>
>
> *_Benefits of adoption:_*____
>
> * Enhanced Security: Eliminates reliance on outdated and vulnerable DCV methods that cannot consistently provide the security required by the TLS BRs, or benefit from recent DCV security enhancements (i.e., Multi-Perspective Issuance Corroboration [11]). ____
> * Increased Agility: Encourages site owners to transition to modern DCV methods, creating opportunities for faster, more efficient, and less error-prone certificate lifecycle management. ____
> * Opportunity for Innovation: Promotes the development of new and/or improved DCV methods, fostering innovation that may enhance the overall security and agility of the ecosystem.____
>
>
> *_Proposed Key Dates:_*____
>
> The effective dates considered in this update are intended to 1) address the immediate concerns identified by [2], and 2) offer near-term and longer-term transition periods for subscribers and CA Owners relying on existing implementations of these methods.____
>
> * January 15, 2025: (1) Prohibit the use of RFC 3912 (WHOIS) and HTTPS websites to identify Domain Contact information. (2) Prohibit the reuse of DCV relying on information obtained using these technologies. (3) Prohibit WHOIS-based DCV methods for Subscriber Certificates containing ccTLDs. (4) CAs MUST NOT rely on cached WHOIS/RDAP data more than 48 hours old. ____
> * July 15, 2025: (1) Sunset DCV Methods 3.2.2.4.2 ("Email, Fax, SMS, or Postal Mail to Domain Contact") and 3.2.2.4.15 ("Phone Contact with Domain Contact"). (2) Prior validations using these methods and validation data gathered therein MUST NOT be used to issue new Subscriber Certificates.____
>
>
> *_Proposal Revision History:_*____
>
> * Pre-Ballot Version #1 [4]____
> * Ballot Version #1 [7]____
> * Version #2 Pre-Release [17] and discussion [18]____
> * Version #2 (this version) [19]____
>
>
> The following motion has been proposed by Ryan Dickson and Chris Clements of Google (Chrome Root Program) and endorsed by Arvid Vermote (GlobalSign) and Pedro Fuentes (OISTE).____
>
>
> — 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.0.7.
>
> MODIFY the Baseline Requirements as specified in the following Redline:
>
> https://github.com/cabforum/servercert/compare/ba28d04894d69c8fac62850b9d0de5061658c7c5..7f2b54cfa5b89f41458a88211566ce508c464804 <https://github.com/cabforum/servercert/compare/ba28d04894d69c8fac62850b9d0de5061658c7c5..7f2b54cfa5b89f41458a88211566ce508c464804>
>
> — Motion Ends —
>
> This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
>
> _Discussion (no less than 7 days)_____
>
> * Start: 2024-10-01 17:00:00 UTC____
> * End no earlier than: 2024-10-08 17:00:00 UTC____
>
>
> _Vote for approval (7 days)_____
>
> * Start: TBD____
> * End: TBD____
>
> ____
>
> Comments are welcome either on-list or with suggested edits via GitHub (preferred) at [19].____
>
> ____
>
> Thanks,____
>
> Ryan____
>
> ____
>
> ____
>
> *References:*____
>
> [1] https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004900.html <https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004900.html>
> [2] https://labs.watchtowr.com/we-spent-20-to-achieve-rce-and-accidentally-became-the-admins-of-mobi/ <https://labs.watchtowr.com/we-spent-20-to-achieve-rce-and-accidentally-became-the-admins-of-mobi/>
> [3] https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/FuOi_uhQB6U/m/hKJOz3XzAAAJ <https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/FuOi_uhQB6U/m/hKJOz3XzAAAJ>
> [4] https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/mAl9XjieSkA/m/oDNWxtPwAQAJ <https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/mAl9XjieSkA/m/oDNWxtPwAQAJ>
> [5] https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004839.html <https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004839.html>
> [6] https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004844.html <https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004844.html>
> [7] https://aws.amazon.com/blogs/security/aws-certificate-manager-will-discontinue-whois-lookup-for-email-validated-certificates/ <https://aws.amazon.com/blogs/security/aws-certificate-manager-will-discontinue-whois-lookup-for-email-validated-certificates/>
> [8] https://bugzilla.mozilla.org/show_bug.cgi?id=1917896 <https://bugzilla.mozilla.org/show_bug.cgi?id=1917896>
> [9] https://cabforum.org/working-groups/server/baseline-requirements/requirements/#32247-dns-change <https://cabforum.org/working-groups/server/baseline-requirements/requirements/#32247-dns-change>
> [10] https://cabforum.org/working-groups/server/baseline-requirements/requirements/#322419-agreed-upon-change-to-website---acme <https://cabforum.org/working-groups/server/baseline-requirements/requirements/#322419-agreed-upon-change-to-website---acme>
> [11] https://cabforum.org/working-groups/server/baseline-requirements/requirements/#3229-multi-perspective-issuance-corroboration <https://cabforum.org/working-groups/server/baseline-requirements/requirements/#3229-multi-perspective-issuance-corroboration>
> [12] https://cabforum.org/working-groups/server/baseline-requirements/requirements/#491-circumstances-for-revocation <https://cabforum.org/working-groups/server/baseline-requirements/requirements/#491-circumstances-for-revocation>
> [13] https://archive.cabforum.org/pipermail/servercert-wg/2018-August/000113.html <https://archive.cabforum.org/pipermail/servercert-wg/2018-August/000113.html>
> [14] https://lists.cabforum.org/pipermail/validation/2024-July/001995.html <https://lists.cabforum.org/pipermail/validation/2024-July/001995.html>
> [15] https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004825.html <https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004825.html>
> [16] https://github.com/ryancdickson/staging/compare/356799f0dcfe11deb0a375a11233403236ab72c9..7a2ea7b33611bebf006a99a9a82729f183143eac <https://github.com/ryancdickson/staging/compare/356799f0dcfe11deb0a375a11233403236ab72c9..7a2ea7b33611bebf006a99a9a82729f183143eac>
> [17] https://github.com/ryancdickson/staging/compare/ba28d04894d69c8fac62850b9d0de5061658c7c5..7a2ea7b33611bebf006a99a9a82729f183143eac <https://github.com/ryancdickson/staging/compare/ba28d04894d69c8fac62850b9d0de5061658c7c5..7a2ea7b33611bebf006a99a9a82729f183143eac>
> [18] https://github.com/ryancdickson/staging/pull/9 <https://github.com/ryancdickson/staging/pull/9>
> [19] https://github.com/cabforum/servercert/pull/551 <https://github.com/cabforum/servercert/pull/551>____
>
> ____
>
>
> _______________________________________________
> Servercert-wg mailing list
> Server...@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
Rob B
Just joined the WG as an Interested party, been lurking so far to get my bearings and this is my first post - please be gentle if I'm out of turn or off base.
Yoshihiko-sama's points below are very similar to a variety of use cases we're researching and unless there's an exception as outlined it looks like Ballot SC-080 could WEAKEN security in cases like this.
Feel the intent of SC-080 is to close a loophole created by 3rd party data of unknown provenance, however if you have validated non-public contact information (and almost certainly existing contractual obligations) then those contacts SHOULD be considered reliable and suitable starting points for extended validation.
Kind regards,
Rob Brady
-----Original Message-----
From: Servercert-wg <servercert...@cabforum.org> On Behalf Of Yoshihiko Matsuo via Servercert-wg
Sent: Tuesday, October 8, 2024 7:29 AM
To: CA/B Forum Server Certificate WG Public Discussion List <server...@cabforum.org>
Subject: Re: [Servercert-wg] Discussion Period Begins - Ballot SC-080 V2: "Sunset the use of WHOIS to identify Domain Contacts and relying DCV Methods”
> The only method relying on identifying a “Domain Contact" via registration data left by the ballot is 3.2.2.4.12 (“Validating Applicant as a Domain Contact"). This was originally excluded from the scope of sunsets given the expectation that in cases where the organization operating the CA was also the Domain Name Registrar (or an Affiliate), there would be (1) a lower likelihood of unreliable Domain Contact information given a direct relationship with the subscriber/subscriber organization, and (2) a higher potential for seamless certificate lifecycle management because of that relationship. Regardless of whether this expectation is misguided, nothing stops a future ballot from contemplating the further improvement or sunset of 3.2.2.4.12 (“Validating Applicant as a Domain Contact").
We are the CA, and at the same time we are also the gTLD Registrar and the ccTLD Registry.
In this case, I understand that it is acceptable to use the Domain Contacts we hold as The gTLD Registrar for DCV.I would like to hear your opinions on whether the same can be said for the Domain Contacts we hold as the ccTLD Registry.
Note: We require that ccTLD Domain Contacts be kept current as the contact information for the domain name registrant.
With this question, I would like to clarify whether the BR allows the following cases.
1. The CA that is also the ccTLD Registry retrieves Domain Contacts from its own database and performs validation in accordance with 3.2.2.4.2.
2. The CA that is also the ccTLD Registry retrieves Domain Contacts from the WHOIS operated by the ccTLD Registry (which is also a CA) and performs validation in accordance with 3.2.2.4.2.
Thanks,
Yoshihiko Matsuo(JPRS)
On 2024/10/08 4:49, Ryan Dickson via Servercert-wg wrote:
> Hi Doug,
>
>
>
> Would changing the title to something like “/Strengthen registration data lookups and Sunset Methods 3.2.2.4.2 and 3.2.2.4.15/" help?
>
> All methods relying on identifying Domain Contacts via registration data are strengthened by this ballot, beginning January 15, 2025. This includes methods:
> The ballot goes on to sunset the following methods, beginning July 15, 2025:
> - 3.2.2.4.15 (“Phone Contact with Domain Contact")
> The only method relying on identifying a “Domain Contact" via registration data left by the ballot is 3.2.2.4.12 (“Validating Applicant as a Domain Contact"). This was originally excluded from the scope of sunsets given the expectation that in cases where the organization operating the CA was also the Domain Name Registrar (or an Affiliate), there would be (1) a lower likelihood of unreliable Domain Contact information given a direct relationship with the subscriber/subscriber organization, and (2) a higher potential for seamless certificate lifecycle management because of that relationship. Regardless of whether this expectation is misguided, nothing stops a future ballot from contemplating the further improvement or sunset of 3.2.2.4.12 (“Validating Applicant as a Domain Contact").
>
> If there’s a case to make for including 3.2.2.4.12 in the sunsets covered in the proposal, it’s also welcome.
>
>
>
> Periodically over the past three years (when I joined this community), I’ve participated in discussions where members have expressed a desire for improved DCV methods, which has included suggestions to remove perceived weak methods (with those that are phone or email-based cited as examples). While very few of these discussions have led to direct action, this ballot presents a proactive opportunity to address some of those concerns, along with mitigating concerns related to registration data lookups identified by recent events.
>
> I do not believe a holistic evaluation of the DCV-methods permitted by the TLS BRs needs to be a blocking function on this ballot, and that both activities can take place independently of one another.
>
> Thanks,
> Ryan
>
>
> On Mon, Oct 7, 2024 at 7:35 AM Doug Beattie <doug.b...@globalsign.com <mailto:doug.b...@globalsign.com>> wrote:
>
> Hi Ryan,____
>
> __ __
>
> The title, purpose and background of this ballot define the removal of WHOIS and does not discuss any other changes, but we’re actually sunsetting other aspects of domain validation while also leaving method 3.2.2.4.12 that can continue to use WHOIS. Part of this is the unfortunately extremely broad definition of “Domain Contact” and “Domain Name Registrant” and the wide scope of 3.2.2.4.2, which I agree we need to clarify and fix. I understand the desire to remove WHOIS based on the recent incident(s), but if we’re going to focus on sunsetting WHOIS, we should 100% sunset if for all uses and we should not include the removal of other methods within this ballot. The VWG can be tasked to review methods we think are weak and discuss removing them, for example, imo, all the methods that rely on phone calls (Domain and IP address both), which to me are weaker than automated methods like using they SOA record.____
>
> __ __
>
> Doug____
>
> __ __
>
> *From:*Ryan Dickson <ryand...@google.com <mailto:ryand...@google.com>>
> *Cc:* CA/B Forum Server Certificate WG Public Discussion List <server...@cabforum.org <mailto:server...@cabforum.org>>
> *Subject:* Re: [Servercert-wg] Discussion Period Begins - Ballot SC-080 V2: "Sunset the use of WHOIS to identify Domain Contacts and relying DCV Methods”____
>
> __ __
>
> Hi Doug,____
>
> __ __
>
>
> __ __
>
> As currently presented, Method 3.2.2.4.2 (“Email, Fax, SMS, or Postal Mail to Domain Contact”) and Method 3.2.2.4.15 (“Phone Contact with Domain Contact”) are sunset, in their entirety, effective July 15, 2025. ____
>
> __ __
>
> Specific to domain contact email addresses from SOA records, can you share your perspective for adding this specific option given the existence of (1) other email-based alternatives (e.g., 3.2.2.4.4, 3.2.2.4.13 and 3.2.2.4.14) and (2) other far more heavily relied upon DCV methods that present an opportunity for improved automation and scalability (and also benefit from MPIC)?____
>
> __ __
>
> For example, detailing responses below would be helpful for understanding:____
>
> * existing reliance on this specific approach in comparison to the other DCV methods offered?____
> * how this reliance has trended over time (e.g., last 1 / 3 / 5 years)?____
> * how the sunset would affect subscribers?____
> * a general description of the level of effort for affected subscribers to transition to another method?____
> * what barriers exist that prevent subscribers from transitioning to other methods?____
>
> __ __
>
> I think it’s reasonable for the community to approach RNAME lookups with the same degree of concern for accuracy and reliability as registration data due to the potential for:____
>
> * neglected configurations (e.g., in 2020, [1] indicated only 39.74% of a set of “top” 1M domains contained “reachable” SOA contacts, and only approximately 20% of the sampled .com and .net domains did).____
> * potential CA reliance on third-party tools with unknown operational characteristics for performing SOA lookups (the same concern as WHOIS lookups using HTTPS websites).____
> * a lack of oversight and enforcement for ensuring SOA record updates (e.g, accuracy/correctness and timeliness).____
>
> __ __
>
> Thanks,____
>
> Ryan____
>
> __ __
>
> [1] https://mkorczynski.com/WTMC2020.pdf <https://mkorczynski.com/WTMC2020.pdf>____
>
> __ __
>
> __ __
>
> On Thu, Oct 3, 2024 at 9:57 AM Doug Beattie <doug.b...@globalsign.com <mailto:doug.b...@globalsign.com>> wrote:____
>
> Hey Ryan,____
>
> ____
>
> The way I read the ballot is that using domain approver email addresses from SOA records is being removed since that’s part of 3.2.2.4.2. Should we add a new method specifically for that, or was the intent to remove that as a valid location to obtain domain approver email addresses?____
>
>
> Doug____
>
> ____
>
> *From:*Servercert-wg <servercert...@cabforum.org <mailto:servercert...@cabforum.org>> *On Behalf Of *Ryan Dickson via Servercert-wg
> *Subject:* [Servercert-wg] Discussion Period Begins - Ballot SC-080 V2: "Sunset the use of WHOIS to identify Domain Contacts and relying DCV Methods”____
>
> ____
>
> *_Purpose of Ballot SC-080 V2:
>
> *_Background:
> _*This ballot intends to accomplish two objectives, originally described in [1].____
> Objective 1: Enhance WHOIS/RDAP validation of gTLDs with comparable security properties to DNS-based validation and sunset WHOIS/RDAP for ccTLDs.
>
>
> * A recent disclosure [2] demonstrated how threat actors could exploit deficiencies in the WHOIS protocol and WHOIS tools served via HTTPS websites to obtain fraudulent TLS certificates.____
> * Discussions within the Mozilla Dev Security Policy (MDSP) community [3] further expressed corresponding risks related to WHOIS, while also noting that ccTLDs may not maintain accurate or up-to-date WHOIS server records. Several examples of inoperative WHOIS servers for ccTLDs were identified.____
> * Discussion in [4] further called into question the reliability of ccTLD WHOIS servers given, per IANA, there is no global policy requirement for ccTLD managers to operate a WHOIS server, and if they do, what kind of information is provided.____
> * Solutions to strengthen existing WHOIS lookup methods were proposed in [5] and are considered in this ballot.____
>
> ____
> Objective 2: Sunset Methods 3.2.2.4.2 (“Email, Fax, SMS, or Postal Mail to Domain Contact”) and 3.2.2.4.15 (“Phone Contact with Domain Contact”).
>
>
> * While solutions to strengthen WHOIS-relying DCV methods are considered in this ballot (see above), there is limited public evidence of significant reliance on these methods, including in response to [3] and [6].____
> * Instead, discussion has identified at least one CA Owner has already sunset reliance on WHOIS [7], and another that has changed its approach [8] for relying on WHOIS since disclosure of [2].____
> * More modern and heavily relied-upon DCV methods offer advantages over the existing WHOIS-based methods, including greater opportunity for seamless certificate lifecycle management automation (e.g., [9] and [10]), while also benefiting from recently improved security practices [11]. These methods can also more effectively align subscriber capabilities with agility and resilience expectations necessary to respond to the revocation timelines described in the TLS BRs [12].____
>
>
> *_Benefits of adoption:_*____
>
> * Increased Agility: Encourages site owners to transition to modern DCV methods, creating opportunities for faster, more efficient, and less error-prone certificate lifecycle management. ____
>
>
> *_Proposed Key Dates:_*____
>
>
> * January 15, 2025: (1) Prohibit the use of RFC 3912 (WHOIS) and HTTPS websites to identify Domain Contact information. (2) Prohibit the reuse of DCV relying on information obtained using these technologies. (3) Prohibit WHOIS-based DCV methods for Subscriber Certificates containing ccTLDs. (4) CAs MUST NOT rely on cached WHOIS/RDAP data more than 48 hours old. ____
>
>
> *_Proposal Revision History:_*____
>
> * Pre-Ballot Version #1 [4]____
> * Ballot Version #1 [7]____
> * Version #2 (this version) [19]____
>
>
> The following motion has been proposed by Ryan Dickson and Chris Clements of Google (Chrome Root Program) and endorsed by Arvid Vermote (GlobalSign) and Pedro Fuentes (OISTE).____
>
> — 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.0.7.
>
> 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:
>
>
Ryan Dickson
Hi Yoshihiko,
The definition for “Domain Contact" (unchanged by the proposal) is: “The Domain Name Registrant, technical contact, or administrative contact (or the equivalent under a ccTLD) as listed in the WHOIS record of the Base Domain Name or in a DNS SOA record, or as obtained through direct contact with the Domain Name Registrar.”
The definition for “Domain Name Registrar" (also unchanged by the proposal) is: “A person or entity that registers Domain Names under the auspices of or by agreement with:
- the Internet Corporation for Assigned Names and Numbers (ICANN),- a national Domain Name authority/registry, or
- a Network Information Center (including their affiliates, contractors, delegates, successors, or assignees).”
For the circumstances described in your message, can you please confirm whether the organization operating the CA is considered:
- ONLY the ccTLD Domain Name Authority/Registry- ONLY the Domain Name Registrar
- BOTH the ccTLD Domain Name Authority/Registry and sometimes a Domain Name Registrar
- BOTH the ccTLD Domain Name Authority/Registry and always the Domain Name Registrar
Given the definition of “Domain Contact" and its reference in 3.2.2.4.2, 3.2.2.4.12, and 3.2.2.4.15, I believe the distinction between roles (Domain Name Authority/Registry and Domain Name Registrar) is important.
Thanks,
Ryan
All,
> The only method relying on identifying a “Domain Contact" via registration data left by the ballot is 3.2.2.4.12 (“Validating Applicant as a Domain Contact"). This was originally excluded from the scope of sunsets given the expectation that in cases where the organization operating the CA was also the Domain Name Registrar (or an Affiliate), there would be (1) a lower likelihood of unreliable Domain Contact information given a direct relationship with the subscriber/subscriber organization, and (2) a higher potential for seamless certificate lifecycle management because of that relationship. Regardless of whether this expectation is misguided, nothing stops a future ballot from contemplating the further improvement or sunset of 3.2.2.4.12 (“Validating Applicant as a Domain Contact").
We are the CA, and at the same time we are also the gTLD Registrar and the ccTLD Registry.
In this case, I understand that it is acceptable to use the Domain Contacts we hold as The gTLD Registrar for DCV.I would like to hear your opinions on whether the same can be said for the Domain Contacts we hold as the ccTLD Registry.
Note: We require that ccTLD Domain Contacts be kept current as the contact information for the domain name registrant.
With this question, I would like to clarify whether the BR allows the following cases.
1. The CA that is also the ccTLD Registry retrieves Domain Contacts from its own database and performs validation in accordance with 3.2.2.4.2.
2. The CA that is also the ccTLD Registry retrieves Domain Contacts from the WHOIS operated by the ccTLD Registry (which is also a CA) and performs validation in accordance with 3.2.2.4.2.
Thanks,
Yoshihiko Matsuo(JPRS)
On 2024/10/08 4:49, Ryan Dickson via Servercert-wg wrote:
> Hi Doug,
>
> > The title, purpose and background of this ballot define the removal of WHOIS and does not discuss any other changes, but we’re actually sunsetting other aspects of domain validation while also leaving method 3.2.2.4.12 that can continue to use WHOIS.
>
> I feel “Objective 2", included in the “Background" section, makes the intent to sunset methods clear (the objective's description is: "/Sunset Methods 3.2.2.4.2 (“Email, Fax, SMS, or Postal Mail to Domain Contact”) and 3.2.2.4.15 (“Phone Contact with Domain Contact")/").
>
> Would changing the title to something like “/Strengthen registration data lookups and Sunset Methods 3.2.2.4.2 and 3.2.2.4.15/" help?
>
> > I understand the desire to remove WHOIS based on the recent incident(s), but if we’re going to focus on sunsetting WHOIS, we should 100% sunset it for all uses and we should not include the removal of other methods within this ballot.
>
> All methods relying on identifying Domain Contacts via registration data are strengthened by this ballot, beginning January 15, 2025. This includes methods:
> - 3.2.2.4.2 (“Email, Fax, SMS, or Postal Mail to Domain Contact")
> - 3.2.2.4.12 (“Validating Applicant as a Domain Contact")
> - 3.2.2.4.15 (“Phone Contact with Domain Contact")
>
> The ballot goes on to sunset the following methods, beginning July 15, 2025:
> - 3.2.2.4.2 (“Email, Fax, SMS, or Postal Mail to Domain Contact")
> - 3.2.2.4.15 (“Phone Contact with Domain Contact")
>
> The only method relying on identifying a “Domain Contact" via registration data left by the ballot is 3.2.2.4.12 (“Validating Applicant as a Domain Contact"). This was originally excluded from the scope of sunsets given the expectation that in cases where the organization operating the CA was also the Domain Name Registrar (or an Affiliate), there would be (1) a lower likelihood of unreliable Domain Contact information given a direct relationship with the subscriber/subscriber organization, and (2) a higher potential for seamless certificate lifecycle management because of that relationship. Regardless of whether this expectation is misguided, nothing stops a future ballot from contemplating the further improvement or sunset of 3.2.2.4.12 (“Validating Applicant as a Domain Contact").
>
> If there’s a case to make for including 3.2.2.4.12 in the sunsets covered in the proposal, it’s also welcome.
>
> > The VWG can be tasked to review methods we think are weak and discuss removing them, for example, imo, all the methods that rely on phone calls (Domain and IP address both), which to me are weaker than automated methods like using they SOA record.
>
> I agree that it’s important for this community to routinely re-evaluate the DCV methods permitted by the TLS BRs and consider them against a set of desirable security and operational properties that best enable subscriber organizations to make securely managing their TLS implementations “boring" (effortless, routine, reliable, and without excitement - even when facing the unexpected).
>
> Periodically over the past three years (when I joined this community), I’ve participated in discussions where members have expressed a desire for improved DCV methods, which has included suggestions to remove perceived weak methods (with those that are phone or email-based cited as examples). While very few of these discussions have led to direct action, this ballot presents a proactive opportunity to address some of those concerns, along with mitigating concerns related to registration data lookups identified by recent events.
>
> I do not believe a holistic evaluation of the DCV-methods permitted by the TLS BRs needs to be a blocking function on this ballot, and that both activities can take place independently of one another.
>
> Thanks,
> Ryan
>
>
> On Mon, Oct 7, 2024 at 7:35 AM Doug Beattie <doug.b...@globalsign.com <mailto:doug.b...@globalsign.com>> wrote:
>
> Hi Ryan,____
>
> __ __
>
> The title, purpose and background of this ballot define the removal of WHOIS and does not discuss any other changes, but we’re actually sunsetting other aspects of domain validation while also leaving method 3.2.2.4.12 that can continue to use WHOIS. Part of this is the unfortunately extremely broad definition of “Domain Contact” and “Domain Name Registrant” and the wide scope of 3.2.2.4.2, which I agree we need to clarify and fix. I understand the desire to remove WHOIS based on the recent incident(s), but if we’re going to focus on sunsetting WHOIS, we should 100% sunset if for all uses and we should not include the removal of other methods within this ballot. The VWG can be tasked to review methods we think are weak and discuss removing them, for example, imo, all the methods that rely on phone calls (Domain and IP address both), which to me are weaker than automated methods like using they SOA record.____
>
> __ __
>
> Doug____
>
> __ __
>
> *From:*Ryan Dickson <ryand...@google.com <mailto:ryand...@google.com>>
> *Sent:* Friday, October 4, 2024 2:55 PM
> *To:* Doug Beattie <doug.b...@globalsign.com <mailto:doug.b...@globalsign.com>>
> *Cc:* CA/B Forum Server Certificate WG Public Discussion List <server...@cabforum.org <mailto:server...@cabforum.org>>
> *Subject:* Re: [Servercert-wg] Discussion Period Begins - Ballot SC-080 V2: "Sunset the use of WHOIS to identify Domain Contacts and relying DCV Methods”____
>
> __ __
>
> Hi Doug,____
>
> __ __
>
> Your interpretation of the latest version of the ballot is correct. ____
>
> __ __
>
> As currently presented, Method 3.2.2.4.2 (“Email, Fax, SMS, or Postal Mail to Domain Contact”) and Method 3.2.2.4.15 (“Phone Contact with Domain Contact”) are sunset, in their entirety, effective July 15, 2025. ____
>
> __ __
>
> Specific to domain contact email addresses from SOA records, can you share your perspective for adding this specific option given the existence of (1) other email-based alternatives (e.g., 3.2.2.4.4, 3.2.2.4.13 and 3.2.2.4.14) and (2) other far more heavily relied upon DCV methods that present an opportunity for improved automation and scalability (and also benefit from MPIC)?____
>
> __ __
>
> For example, detailing responses below would be helpful for understanding:____
>
> * existing reliance on this specific approach in comparison to the other DCV methods offered?____
> * how this reliance has trended over time (e.g., last 1 / 3 / 5 years)?____
> * how the sunset would affect subscribers?____
> * a general description of the level of effort for affected subscribers to transition to another method?____
> * what barriers exist that prevent subscribers from transitioning to other methods?____
>
> __ __
>
> I think it’s reasonable for the community to approach RNAME lookups with the same degree of concern for accuracy and reliability as registration data due to the potential for:____
>
> * neglected configurations (e.g., in 2020, [1] indicated only 39.74% of a set of “top” 1M domains contained “reachable” SOA contacts, and only approximately 20% of the sampled .com and .net domains did).____
> * potential CA reliance on third-party tools with unknown operational characteristics for performing SOA lookups (the same concern as WHOIS lookups using HTTPS websites).____
> * a lack of oversight and enforcement for ensuring SOA record updates (e.g, accuracy/correctness and timeliness).____
> * use of automated DNS management solutions that can result in an unintended and/or unknown delegation of authority to approve TLS certificates, while also representing a single point of failure (or attack).____
>
> __ __
>
> Thanks,____
>
> Ryan____
>
> __ __
>
> [1] https://mkorczynski.com/WTMC2020.pdf <https://mkorczynski.com/WTMC2020.pdf>____
>
> __ __
>
> __ __
>
> On Thu, Oct 3, 2024 at 9:57 AM Doug Beattie <doug.b...@globalsign.com <mailto:doug.b...@globalsign.com>> wrote:____
>
> Hey Ryan,____
>
> ____
>
> The way I read the ballot is that using domain approver email addresses from SOA records is being removed since that’s part of 3.2.2.4.2. Should we add a new method specifically for that, or was the intent to remove that as a valid location to obtain domain approver email addresses?____
>
>
> Doug____
>
> ____
>
> *From:*Servercert-wg <servercert...@cabforum.org <mailto:servercert...@cabforum.org>> *On Behalf Of *Ryan Dickson via Servercert-wg
> *Sent:* Tuesday, October 1, 2024 12:59 PM
> *To:* ServerCert CA/BF <server...@cabforum.org <mailto:server...@cabforum.org>>
> *Subject:* [Servercert-wg] Discussion Period Begins - Ballot SC-080 V2: "Sunset the use of WHOIS to identify Domain Contacts and relying DCV Methods”____
>
> ____
>
> *_Purpose of Ballot SC-080 V2:
> _*This ballot proposes updates to the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (TLS BRs) to address concerns regarding the use of WHOIS and HTTPS websites for identifying Domain Contacts.
>
> *_Background:
> _*This ballot intends to accomplish two objectives, originally described in [1].____
>
> Objective 1: Enhance WHOIS/RDAP validation of gTLDs with comparable security properties to DNS-based validation and sunset WHOIS/RDAP for ccTLDs.
>
> _Justification:_____
>
> * A recent disclosure [2] demonstrated how threat actors could exploit deficiencies in the WHOIS protocol and WHOIS tools served via HTTPS websites to obtain fraudulent TLS certificates.____
> * Discussions within the Mozilla Dev Security Policy (MDSP) community [3] further expressed corresponding risks related to WHOIS, while also noting that ccTLDs may not maintain accurate or up-to-date WHOIS server records. Several examples of inoperative WHOIS servers for ccTLDs were identified.____
> * Discussion in [4] further called into question the reliability of ccTLD WHOIS servers given, per IANA, there is no global policy requirement for ccTLD managers to operate a WHOIS server, and if they do, what kind of information is provided.____
> * Solutions to strengthen existing WHOIS lookup methods were proposed in [5] and are considered in this ballot.____
>
> ____
>
> Objective 2: Sunset Methods 3.2.2.4.2 (“Email, Fax, SMS, or Postal Mail to Domain Contact”) and 3.2.2.4.15 (“Phone Contact with Domain Contact”).
>
> _Justification:_____
>
> * While solutions to strengthen WHOIS-relying DCV methods are considered in this ballot (see above), there is limited public evidence of significant reliance on these methods, including in response to [3] and [6].____
> * Instead, discussion has identified at least one CA Owner has already sunset reliance on WHOIS [7], and another that has changed its approach [8] for relying on WHOIS since disclosure of [2].____
> * More modern and heavily relied-upon DCV methods offer advantages over the existing WHOIS-based methods, including greater opportunity for seamless certificate lifecycle management automation (e.g., [9] and [10]), while also benefiting from recently improved security practices [11]. These methods can also more effectively align subscriber capabilities with agility and resilience expectations necessary to respond to the revocation timelines described in the TLS BRs [12].____
> * Beyond the above, previous discussions within the CA/Browser Forum have raised concerns about the perceived value (e.g., [13]) and security (e.g., [14]) of the DCV methods relying on WHOIS, further supporting the rationale for their gradual sunset.____
>
>
> *_Benefits of adoption:_*____
>
> * Enhanced Security: Eliminates reliance on outdated and vulnerable DCV methods that cannot consistently provide the security required by the TLS BRs, or benefit from recent DCV security enhancements (i.e., Multi-Perspective Issuance Corroboration [11]). ____
> * Increased Agility: Encourages site owners to transition to modern DCV methods, creating opportunities for faster, more efficient, and less error-prone certificate lifecycle management. ____
> * Opportunity for Innovation: Promotes the development of new and/or improved DCV methods, fostering innovation that may enhance the overall security and agility of the ecosystem.____
>
>
> *_Proposed Key Dates:_*____
>
> The effective dates considered in this update are intended to 1) address the immediate concerns identified by [2], and 2) offer near-term and longer-term transition periods for subscribers and CA Owners relying on existing implementations of these methods.____
>
> * January 15, 2025: (1) Prohibit the use of RFC 3912 (WHOIS) and HTTPS websites to identify Domain Contact information. (2) Prohibit the reuse of DCV relying on information obtained using these technologies. (3) Prohibit WHOIS-based DCV methods for Subscriber Certificates containing ccTLDs. (4) CAs MUST NOT rely on cached WHOIS/RDAP data more than 48 hours old. ____
> * July 15, 2025: (1) Sunset DCV Methods 3.2.2.4.2 ("Email, Fax, SMS, or Postal Mail to Domain Contact") and 3.2.2.4.15 ("Phone Contact with Domain Contact"). (2) Prior validations using these methods and validation data gathered therein MUST NOT be used to issue new Subscriber Certificates.____
>
>
> *_Proposal Revision History:_*____
>
> * Pre-Ballot Version #1 [4]____
> * Ballot Version #1 [7]____
> * Version #2 Pre-Release [17] and discussion [18]____
> * Version #2 (this version) [19]____
>
>
> The following motion has been proposed by Ryan Dickson and Chris Clements of Google (Chrome Root Program) and endorsed by Arvid Vermote (GlobalSign) and Pedro Fuentes (OISTE).____
>
>
> — 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.0.7.
>
> MODIFY the Baseline Requirements as specified in the following Redline:
>
> https://github.com/cabforum/servercert/compare/ba28d04894d69c8fac62850b9d0de5061658c7c5..7f2b54cfa5b89f41458a88211566ce508c464804 <https://github.com/cabforum/servercert/compare/ba28d04894d69c8fac62850b9d0de5061658c7c5..7f2b54cfa5b89f41458a88211566ce508c464804>
>
> — Motion Ends —
>
> This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
>
> _Discussion (no less than 7 days)_____
>
> * Start: 2024-10-01 17:00:00 UTC____
Ryan Dickson
Welcome to the community, we’re glad to have you!
> Yoshihiko-sama's points below are very similar to a variety of use cases we're researching and unless there's an exception as outlined it looks like Ballot SC-080 could WEAKEN security in cases like this.
- How specifically will the proposed changes weaken security?
- What precisely is the exception that should be considered?
- What are you referring to by the phrase “extended validation?"
- How do the proposed changes impact “extended validation?”
Thanks,
Ryan
Hello everyone,
Just joined the WG as an Interested party, been lurking so far to get my bearings and this is my first post - please be gentle if I'm out of turn or off base.
Yoshihiko-sama's points below are very similar to a variety of use cases we're researching and unless there's an exception as outlined it looks like Ballot SC-080 could WEAKEN security in cases like this.
Feel the intent of SC-080 is to close a loophole created by 3rd party data of unknown provenance, however if you have validated non-public contact information (and almost certainly existing contractual obligations) then those contacts SHOULD be considered reliable and suitable starting points for extended validation.
Kind regards,
Rob Brady
-----Original Message-----
From: Servercert-wg <servercert...@cabforum.org> On Behalf Of Yoshihiko Matsuo via Servercert-wg
Sent: Tuesday, October 8, 2024 7:29 AM
To: CA/B Forum Server Certificate WG Public Discussion List <server...@cabforum.org>
Subject: Re: [Servercert-wg] Discussion Period Begins - Ballot SC-080 V2: "Sunset the use of WHOIS to identify Domain Contacts and relying DCV Methods”
All,
> The only method relying on identifying a “Domain Contact" via registration data left by the ballot is 3.2.2.4.12 (“Validating Applicant as a Domain Contact"). This was originally excluded from the scope of sunsets given the expectation that in cases where the organization operating the CA was also the Domain Name Registrar (or an Affiliate), there would be (1) a lower likelihood of unreliable Domain Contact information given a direct relationship with the subscriber/subscriber organization, and (2) a higher potential for seamless certificate lifecycle management because of that relationship. Regardless of whether this expectation is misguided, nothing stops a future ballot from contemplating the further improvement or sunset of 3.2.2.4.12 (“Validating Applicant as a Domain Contact").
We are the CA, and at the same time we are also the gTLD Registrar and the ccTLD Registry.
In this case, I understand that it is acceptable to use the Domain Contacts we hold as The gTLD Registrar for DCV.I would like to hear your opinions on whether the same can be said for the Domain Contacts we hold as the ccTLD Registry.
Note: We require that ccTLD Domain Contacts be kept current as the contact information for the domain name registrant.
With this question, I would like to clarify whether the BR allows the following cases.
1. The CA that is also the ccTLD Registry retrieves Domain Contacts from its own database and performs validation in accordance with 3.2.2.4.2.
2. The CA that is also the ccTLD Registry retrieves Domain Contacts from the WHOIS operated by the ccTLD Registry (which is also a CA) and performs validation in accordance with 3.2.2.4.2.
Thanks,
Yoshihiko Matsuo(JPRS)
On 2024/10/08 4:49, Ryan Dickson via Servercert-wg wrote:
> Hi Doug,
>
> > The title, purpose and background of this ballot define the removal of WHOIS and does not discuss any other changes, but we’re actually sunsetting other aspects of domain validation while also leaving method 3.2.2.4.12 that can continue to use WHOIS.
>
> I feel “Objective 2", included in the “Background" section, makes the intent to sunset methods clear (the objective's description is: "/Sunset Methods 3.2.2.4.2 (“Email, Fax, SMS, or Postal Mail to Domain Contact”) and 3.2.2.4.15 (“Phone Contact with Domain Contact")/").
>
> Would changing the title to something like “/Strengthen registration data lookups and Sunset Methods 3.2.2.4.2 and 3.2.2.4.15/" help?
>
> > I understand the desire to remove WHOIS based on the recent incident(s), but if we’re going to focus on sunsetting WHOIS, we should 100% sunset it for all uses and we should not include the removal of other methods within this ballot.
>
> All methods relying on identifying Domain Contacts via registration data are strengthened by this ballot, beginning January 15, 2025. This includes methods:
> - 3.2.2.4.2 (“Email, Fax, SMS, or Postal Mail to Domain Contact")
> - 3.2.2.4.12 (“Validating Applicant as a Domain Contact")
> - 3.2.2.4.15 (“Phone Contact with Domain Contact")
>
> The ballot goes on to sunset the following methods, beginning July 15, 2025:
> - 3.2.2.4.2 (“Email, Fax, SMS, or Postal Mail to Domain Contact")
> - 3.2.2.4.15 (“Phone Contact with Domain Contact")
>
> The only method relying on identifying a “Domain Contact" via registration data left by the ballot is 3.2.2.4.12 (“Validating Applicant as a Domain Contact"). This was originally excluded from the scope of sunsets given the expectation that in cases where the organization operating the CA was also the Domain Name Registrar (or an Affiliate), there would be (1) a lower likelihood of unreliable Domain Contact information given a direct relationship with the subscriber/subscriber organization, and (2) a higher potential for seamless certificate lifecycle management because of that relationship. Regardless of whether this expectation is misguided, nothing stops a future ballot from contemplating the further improvement or sunset of 3.2.2.4.12 (“Validating Applicant as a Domain Contact").
>
> If there’s a case to make for including 3.2.2.4.12 in the sunsets covered in the proposal, it’s also welcome.
>
> > The VWG can be tasked to review methods we think are weak and discuss removing them, for example, imo, all the methods that rely on phone calls (Domain and IP address both), which to me are weaker than automated methods like using they SOA record.
>
> _*This ballot proposes updates to the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (TLS BRs) to address concerns regarding the use of WHOIS and HTTPS websites for identifying Domain Contacts.
>
> *_Background:
> _*This ballot intends to accomplish two objectives, originally described in [1].____
>
> Objective 1: Enhance WHOIS/RDAP validation of gTLDs with comparable security properties to DNS-based validation and sunset WHOIS/RDAP for ccTLDs.
>
> _Justification:_____
>
> * A recent disclosure [2] demonstrated how threat actors could exploit deficiencies in the WHOIS protocol and WHOIS tools served via HTTPS websites to obtain fraudulent TLS certificates.____
> * Discussions within the Mozilla Dev Security Policy (MDSP) community [3] further expressed corresponding risks related to WHOIS, while also noting that ccTLDs may not maintain accurate or up-to-date WHOIS server records. Several examples of inoperative WHOIS servers for ccTLDs were identified.____
> * Discussion in [4] further called into question the reliability of ccTLD WHOIS servers given, per IANA, there is no global policy requirement for ccTLD managers to operate a WHOIS server, and if they do, what kind of information is provided.____
> * Solutions to strengthen existing WHOIS lookup methods were proposed in [5] and are considered in this ballot.____
>
> ____
>
> Objective 2: Sunset Methods 3.2.2.4.2 (“Email, Fax, SMS, or Postal Mail to Domain Contact”) and 3.2.2.4.15 (“Phone Contact with Domain Contact”).
>
> _Justification:_____
>
> * While solutions to strengthen WHOIS-relying DCV methods are considered in this ballot (see above), there is limited public evidence of significant reliance on these methods, including in response to [3] and [6].____
> * Instead, discussion has identified at least one CA Owner has already sunset reliance on WHOIS [7], and another that has changed its approach [8] for relying on WHOIS since disclosure of [2].____
> * More modern and heavily relied-upon DCV methods offer advantages over the existing WHOIS-based methods, including greater opportunity for seamless certificate lifecycle management automation (e.g., [9] and [10]), while also benefiting from recently improved security practices [11]. These methods can also more effectively align subscriber capabilities with agility and resilience expectations necessary to respond to the revocation timelines described in the TLS BRs [12].____
> * Beyond the above, previous discussions within the CA/Browser Forum have raised concerns about the perceived value (e.g., [13]) and security (e.g., [14]) of the DCV methods relying on WHOIS, further supporting the rationale for their gradual sunset.____
>
>
> *_Benefits of adoption:_*____
>
> * Enhanced Security: Eliminates reliance on outdated and vulnerable DCV methods that cannot consistently provide the security required by the TLS BRs, or benefit from recent DCV security enhancements (i.e., Multi-Perspective Issuance Corroboration [11]). ____
> * Increased Agility: Encourages site owners to transition to modern DCV methods, creating opportunities for faster, more efficient, and less error-prone certificate lifecycle management. ____
> * Opportunity for Innovation: Promotes the development of new and/or improved DCV methods, fostering innovation that may enhance the overall security and agility of the ecosystem.____
>
>
> *_Proposed Key Dates:_*____
>
> The effective dates considered in this update are intended to 1) address the immediate concerns identified by [2], and 2) offer near-term and longer-term transition periods for subscribers and CA Owners relying on existing implementations of these methods.____
>
> * January 15, 2025: (1) Prohibit the use of RFC 3912 (WHOIS) and HTTPS websites to identify Domain Contact information. (2) Prohibit the reuse of DCV relying on information obtained using these technologies. (3) Prohibit WHOIS-based DCV methods for Subscriber Certificates containing ccTLDs. (4) CAs MUST NOT rely on cached WHOIS/RDAP data more than 48 hours old. ____
> * July 15, 2025: (1) Sunset DCV Methods 3.2.2.4.2 ("Email, Fax, SMS, or Postal Mail to Domain Contact") and 3.2.2.4.15 ("Phone Contact with Domain Contact"). (2) Prior validations using these methods and validation data gathered therein MUST NOT be used to issue new Subscriber Certificates.____
>
>
> *_Proposal Revision History:_*____
>
> * Pre-Ballot Version #1 [4]____
> * Ballot Version #1 [7]____
> * Version #2 Pre-Release [17] and discussion [18]____
> * Version #2 (this version) [19]____
>
>
> The following motion has been proposed by Ryan Dickson and Chris Clements of Google (Chrome Root Program) and endorsed by Arvid Vermote (GlobalSign) and Pedro Fuentes (OISTE).____
>
>
> — 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.0.7.
>
> MODIFY the Baseline Requirements as specified in the following Redline:
>
> https://github.com/cabforum/servercert/compare/ba28d04894d69c8fac62850b9d0de5061658c7c5..7f2b54cfa5b89f41458a88211566ce508c464804 <https://github.com/cabforum/servercert/compare/ba28d04894d69c8fac62850b9d0de5061658c7c5..7f2b54cfa5b89f41458a88211566ce508c464804>
>
> — Motion Ends —
>
> This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
>
Rob B
>Hi Rob!
>Welcome to the community, we’re glad to have you!
Thank you for the kind words. The level of experience and expertise in this WG is daunting and for the most part I’ll stick to reading along with the odd question here or there.
Without getting too specific, we’re working through the steps of building several “Trust Services” in a lab environment (Baremetal) that don’t reinvent the wheel, honor and most importantly conform to prior art and best current practices.
Obviously, strictly adhering to the CABForum’s Baseline requirements is a critical requirement here.
The use cases and scenarios we’re looking at aren’t “mainstream”, so may be entirely out of scope for this discussion, but then again maybe not.
>Can you offer more detail on:
>- How specifically will the proposed changes weaken security?
Delivering Objective 1 will mitigate several significant threats to relying parties and it’s clear the consensus is that it should be enacted ASAP.
We do have some questions around the wording and the goals of Objective 2
Some were addressed by prior clarifications, but the wording appears to sunset 3.2.2.4.2 and 3.2.2.4.15 entirely next summer (vs prohibiting the contact information coming from WHOIS at a higher level in the basic requirements as a “Pending Prohibition”).
If 3.2.2.4.2 and 3.2.2.4.15 are entirely deprecated – Doesn’t that all but eliminate “out of band” verification using data from “Reliable Data Sources” sources via “Reliable Methods of Communication” or even using “DNS SOA” as currently defined in “Domain
Contact”?
I suspect we’re misreading the requirements, but clarification is very much appreciated if we are.
Also, regardless of “WHOIS”, if a registrar doesn’t have, or publish accurate data, or is potentially not permitted to release it to a CA (eg Certain jurisdictions with strong Privacy Regulations or other legal obligations) or for that matter and equally valid
reasons certain domain owners are publicly tight lipped and don’t publish contact information via CAA tags what would be the process?
This next scenario is almost certainly out of scope, but it’s not unheard of for mid-large publicly listed companies to have poor oversight of shared / “special” mailboxes and mediocre OPSEC.
This lends support to deprecating email as a method, if said email was sent via “Trustworthy Email” would that be acceptable?
EG Email compliant with NIST 800-177 or using something like the EU’s PEC mitigates a substantial amount of risk, or is the risk being mitigated something else?
It appears that as it stands, prohibiting “email” entirely would prohibit these too without further clarification – an attempt to say they’re not “Email” in the conventional sense appears run afoul of the prohibition in 3.2.2.4.11
However In cases where there is doubt that a request is made with appropriate authority, using a “well known” fax or postal address (ideally via certified/registered service) feels a viable alternate path to verifying the Applicant’s control is legitimate.
Finally, does the proposed prohibition on using information obtained from HTTPS websites mean the use of ANY site that is accessed via HTTPS or are we again over-reading this?
>- What precisely is the exception that should be considered?
Instead of sunsetting 3.2.2.4.2 and 3.2.2.4.15 entirely, which appears to prevent compliance if these methods are used in Sensitive / High Risk Certificate requests we suggest changing the language to recommend
these methods SHOULD NOT be used.
This leaves the door open for compliance using these methods, but responsibility for using them rests with the CA and must be justified.
>- What are you referring to by the phrase “extended validation?"
See above, that was a poor choice of words on my part. Apologies.
>- How do the proposed changes impact “extended validation?
Likewise.
Many thanks again & kind regards,
Rob
Ryan Dickson
> If 3.2.2.4.2 and 3.2.2.4.15 are entirely deprecated – Doesn’t that all but eliminate “out of band” verification using data from “Reliable Data Sources” sources via “Reliable Methods of Communication” or even using “DNS SOA” as currently defined in “Domain Contact”?
The phrase “Domain Contact," and by extension, DNS SOA, is still referenced in 3.2.2.4.12 - although it seems unlikely to be relied upon.
> Also, regardless of “WHOIS”, if a registrar doesn’t have, or publish accurate data, or is potentially not permitted to release it to a CA (eg Certain jurisdictions with strong Privacy Regulations or other legal obligations) or for that matter and equally valid reasons certain domain owners are publicly tight lipped and don’t publish contact information via CAA tags what would be the process?
The BRs support domain control validation methods that do not rely on contact information, either persistently or temporarily posted, for example, 3.2.2.4.7 (“DNS Change"), 3.2.2.4.18 (“Agreed‑Upon Change to Website v2", and 3.2.2.4.19 (“Agreed‑Upon Change to Website ‑ ACME"). If privacy concerns are a significant factor for these subscribers, can you share why these other methods should not be considered useful alternatives?
Beyond potential privacy concerns, other methods are better equipped for automation, dealing with certificate lifecycle management needs at scale, and offer improved security properties like multi-perspective issuance corroboration that don't always translate well to “contact-based” methods like phone and email.
> This next scenario is almost certainly out of scope, but it’s not unheard of for mid-large publicly listed companies to have poor oversight of shared / “special” mailboxes and mediocre OPSEC.
> This lends support to deprecating email as a method, if said email was sent via “Trustworthy Email” would that be acceptable?
> EG Email compliant with NIST 800-177 or using something like the EU’s PEC mitigates a substantial amount of risk, or is the risk being mitigated something else?
> It appears that as it stands, prohibiting “email” entirely would prohibit these too without further clarification – an attempt to say they’re not “Email” in the conventional sense appears run afoul of the prohibition in 3.2.2.4.11
> However In cases where there is doubt that a request is made with appropriate authority, using a “well known” fax or postal address (ideally via certified/registered service) feels a viable alternate path to verifying the Applicant’s control is legitimate.
For the sake of staying focused on only the contents in-scope of this ballot, I hope we can defer these discussions to the future.
> Finally, does the proposed prohibition on using information obtained from HTTPS websites mean the use of ANY site that is accessed via HTTPS or are we again over-reading this?
This proposal does not cast a sweeping prohibition against obtaining information from HTTPS websites. For example, this doesn’t prevent a CA from relying on HTTPS when performing Method 3.2.2.4.18 (“Agreed-Upon Change to Website V2").
- Ryan
[1] https://cabforum.org/2016/09/15/2016-09-15-minutes/#:~:text=(a)%20Inadvertent%20domain%20validation%20by,validation%20by%20email%20scanning%20applications.
Matsuo Yoshihiko
Thank you for your reply.
I feel like I didn't express my points clearly in the previous email, so please disregard it.
I apologize for the confusion, but I have reorganized the point I would like to confirm as follows:
I am considering updating our system implementation for obtaining Domain Contact in light of this revision.
BR defines the source of Domain Contact as follows.
#1 WHOIS record
#2 DNS SOA record
#3 direct contact with the Domain Name Registrar
The questions I would like to ask is...
Could it be interpreted that retrieving Domain Contact information from the Whois operated by the Domain Name Registrar itself falls under "3 direct contact with the Domain Name Registrar"?
I would like to hear your opinion on this.
Thanks,
Yoshihiko Matsuo(JPRS)
On Tue, 8 Oct 2024 15:10:38 -0400
Ryan Dickson <ryand...@google.com> wrote:
> Hi Yoshihiko,
>
> The definition for “Domain Contact" (unchanged by the proposal) is: “The
> Domain Name Registrant, technical contact, or administrative contact (or
> the equivalent under a ccTLD) as listed in the WHOIS record of the Base
> Domain Name or in a DNS SOA record, or as obtained through direct contact
> with the Domain Name Registrar.”
>
> The definition for “Domain Name Registrar" (also unchanged by the proposal)
> is: “A person or entity that registers Domain Names under the auspices of
> or by agreement with:
> - the Internet Corporation for Assigned Names and Numbers (ICANN),
> - a national Domain Name authority/registry, or
> *- a Network Information Center (including their affiliates, contractors,
> delegates, successors, or assignees)*.”
>
> For the circumstances described in your message, can you please confirm
> whether the organization operating the CA is considered:
> - ONLY the ccTLD Domain Name Authority/Registry
> - ONLY the Domain Name Registrar
> - BOTH the ccTLD Domain Name Authority/Registry and sometimes a Domain Name
> Registrar
> - BOTH the ccTLD Domain Name Authority/Registry and always the Domain Name
> Registrar
>
> Given the definition of “Domain Contact" and its reference in 3.2.2.4.2,
> 3.2.2.4.12, and 3.2.2.4.15, I believe the distinction between roles (Domain
> Name Authority/Registry and Domain Name Registrar) is important.
>
> Thanks,
>
> Ryan
>
>
>
>
> On Tue, Oct 8, 2024 at 7:29?AM Yoshihiko Matsuo via Servercert-wg <
> > > On Mon, Oct 7, 2024 at 7:35?AM Doug Beattie <doug.b...@globalsign.com
> > > On Thu, Oct 3, 2024 at 9:57?AM Doug Beattie <
> > > ? 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.0.7.
> > >
> > > MODIFY the Baseline Requirements as specified in the following
> > Redline:
> > >
> > >
> > https://github.com/cabforum/servercert/compare/ba28d04894d69c8fac62850b9d0de5061658c7c5..7f2b54cfa5b89f41458a88211566ce508c464804
> > <
> > https://github.com/cabforum/servercert/compare/ba28d04894d69c8fac62850b9d0de5061658c7c5..7f2b54cfa5b89f41458a88211566ce508c464804
> > >
> > >
> > > ? Motion Ends ?
Ryan Dickson
Thanks for clarifying your question.
In my opinion, as currently written, the phrase “direct contact" is not well-defined by the TLS BRs.
My interpretation of “direct contact" between a CA and the Domain Name Registrar is a phone-call or email between representatives of the two organizations, possibly also involving some sort of automated system.
To help better describe my interpretation, please see the illustrative examples below:
Phone or Email:
- CA representative calls/emails the Registrar.
- A representative of the Registrar authenticates the CA representative.
- The CA representative asks the Registrar representative to look up the Domain Contact information for the target domain.
- The Registrar representative looks up the Domain Contact information by relying on its authoritative database / source of truth, and shares this with the CA representative.
- The CA representative uses the Domain Contact information as permitted by the TLS BRs.
Automated System:
- CA representative submits a form requesting Domain Contact information from the Registrar.
- The Registrar authenticates the requestor.
- The CA representative uses the Domain Contact information as permitted by the TLS BRs.
Consequently, I would not consider querying a Registrar’s WHOIS service to constitute “direct contact.” I further interpret the WatchTowr report [1] to have demonstrated flaws with several Registrar WHOIS-function websites.
If this interpretation is misaligned with others’ expectations, discussion is welcome.
Thanks,
Ryan
Matsuo Yoshihiko
Thank you so much for your detailed feedback.
Your insights are greatly appreciated.
We also welcome feedback from anyone else.
Thanks,
Yoshihiko Matsuo (JPRS)
On Thu, 10 Oct 2024 10:41:02 -0400
Ryan Dickson <ryand...@google.com> wrote:
> Hi Yoshihiko,
>
> On Thu, Oct 10, 2024 at 6:27?AM Matsuo Yoshihiko <yosh...@jprs.co.jp>
Dimitris Zacharopoulos (HARICA)
Hi Yoshihiko,
Thanks for clarifying your question.
In my opinion, as currently written, the phrase “direct contact" is not well-defined by the TLS BRs.
My interpretation of “direct contact" between a CA and the Domain Name Registrar is a phone-call or email between representatives of the two organizations, possibly also involving some sort of automated system.
To help better describe my interpretation, please see the illustrative examples below:
Phone or Email:
- CA representative calls/emails the Registrar.
- A representative of the Registrar authenticates the CA representative.
- The CA representative asks the Registrar representative to look up the Domain Contact information for the target domain.
- The Registrar representative looks up the Domain Contact information by relying on its authoritative database / source of truth, and shares this with the CA representative.
- The CA representative uses the Domain Contact information as permitted by the TLS BRs.
Automated System:
- CA representative submits a form requesting Domain Contact information from the Registrar.
- The Registrar authenticates the requestor.
- The Registrar looks up the Domain Contact information by relying on its authoritative database / source of truth, and shares this with the CA representative (e.g., phone or email).
- The CA representative uses the Domain Contact information as permitted by the TLS BRs.
Hi Ryan,
I don't think the Registrar needs to necessarily authenticate the CA representative. Some Registrars offer the Domain Contact information publicly. It is similar to the WHOIS process where no authentication is needed by default.
My interpretation is heavily influenced by language in the TLS EVGs which, in my opinion, establishes framing for the communication mechanisms considered by “direct contact" through phrasing such as “or by direct contact with the Incorporating or Registration Agency in person or via mail, e‐mail, Web address, or telephone, using an address or phone number obtained directly from the Qualified Government Information Source, Incorporating or Registration Agency, or from a Qualified Independent Information Source.” (from 3.2.2.2.2 (“Acceptable Method of Verification"))
Consequently, I would not consider querying a Registrar’s WHOIS service to constitute “direct contact.” I further interpret the WatchTowr report [1] to have demonstrated flaws with several Registrar WHOIS-function websites.
If this interpretation is misaligned with others’ expectations, discussion is welcome.
Thank you,
Dimitris.
On Thu, Oct 10, 2024 at 6:27 AM Matsuo Yoshihiko <yosh...@jprs.co.jp> wrote:
Ryan Dickson
> Equally, the Applicant doesn't need to "authenticate" the CA for the communication to be considered "direct".
Dimitris Zacharopoulos (HARICA)
HARICA would like to push-back on the differentiation of ccTLD vs gTLD Registrars. As mentioned in my previous email, the Domain Name Registrars in the EU are very well regulated and supervised, equally if not stricter than the gTLD Registrars. They have been considered part of "critical infrastructure" by Law and should be considered very reliable.
If there is any evidence to the contrary for European Domain Name Registrars, I would like to ask people to share with the WG.
For HARICA it is a matter of principle. We are ok with the deprecation plan for July 2025. If there is no exception for European ccTLD Registrars, I would like to request that the ballot is amended to remove the language for not allowing ccTLDs in general, in January 2025. It seems unfair for the "responsible" ccTLD Registrars who have been doing excellent work all these years.
Thank you,
Dimitris.
Purpose of Ballot SC-080 V2:
This ballot proposes updates to the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (TLS BRs) to address concerns regarding the use of WHOIS and HTTPS websites for identifying Domain Contacts.
Background:
This ballot intends to accomplish two objectives, originally described in [1].
Objective 1: Enhance WHOIS/RDAP validation of gTLDs with comparable security properties to DNS-based validation and sunset WHOIS/RDAP for ccTLDs.
Justification:
- A recent disclosure [2] demonstrated how threat actors could exploit deficiencies in the WHOIS protocol and WHOIS tools served via HTTPS websites to obtain fraudulent TLS certificates.
- Discussions within the Mozilla Dev Security Policy (MDSP) community [3] further expressed corresponding risks related to WHOIS, while also noting that ccTLDs may not maintain accurate or up-to-date WHOIS server records. Several examples of inoperative WHOIS servers for ccTLDs were identified.
- Discussion in [4] further called into question the reliability of ccTLD WHOIS servers given, per IANA, there is no global policy requirement for ccTLD managers to operate a WHOIS server, and if they do, what kind of information is provided.
- Solutions to strengthen existing WHOIS lookup methods were proposed in [5] and are considered in this ballot.
Objective 2: Sunset Methods 3.2.2.4.2 (“Email, Fax, SMS, or Postal Mail to Domain Contact”) and 3.2.2.4.15 (“Phone Contact with Domain Contact”).
Justification:
- While solutions to strengthen WHOIS-relying DCV methods are considered in this ballot (see above), there is limited public evidence of significant reliance on these methods, including in response to [3] and [6].
- Instead, discussion has identified at least one CA Owner has already sunset reliance on WHOIS [7], and another that has changed its approach [8] for relying on WHOIS since disclosure of [2].
- More modern and heavily relied-upon DCV methods offer advantages over the existing WHOIS-based methods, including greater opportunity for seamless certificate lifecycle management automation (e.g., [9] and [10]), while also benefiting from recently improved security practices [11]. These methods can also more effectively align subscriber capabilities with agility and resilience expectations necessary to respond to the revocation timelines described in the TLS BRs [12].
- Beyond the above, previous discussions within the CA/Browser Forum have raised concerns about the perceived value (e.g., [13]) and security (e.g., [14]) of the DCV methods relying on WHOIS, further supporting the rationale for their gradual sunset.
Benefits of adoption:
- Enhanced Security: Eliminates reliance on outdated and vulnerable DCV methods that cannot consistently provide the security required by the TLS BRs, or benefit from recent DCV security enhancements (i.e., Multi-Perspective Issuance Corroboration [11]).
- Increased Agility: Encourages site owners to transition to modern DCV methods, creating opportunities for faster, more efficient, and less error-prone certificate lifecycle management.
- Opportunity for Innovation: Promotes the development of new and/or improved DCV methods, fostering innovation that may enhance the overall security and agility of the ecosystem.
Proposed Key Dates:
The effective dates considered in this update are intended to 1) address the immediate concerns identified by [2], and 2) offer near-term and longer-term transition periods for subscribers and CA Owners relying on existing implementations of these methods.
- January 15, 2025: (1) Prohibit the use of RFC 3912 (WHOIS) and HTTPS websites to identify Domain Contact information. (2) Prohibit the reuse of DCV relying on information obtained using these technologies. (3) Prohibit WHOIS-based DCV methods for Subscriber Certificates containing ccTLDs. (4) CAs MUST NOT rely on cached WHOIS/RDAP data more than 48 hours old.
- July 15, 2025: (1) Sunset DCV Methods 3.2.2.4.2 ("Email, Fax, SMS, or Postal Mail to Domain Contact") and 3.2.2.4.15 ("Phone Contact with Domain Contact"). (2) Prior validations using these methods and validation data gathered therein MUST NOT be used to issue new Subscriber Certificates.
Proposal Revision History:
- Pre-Ballot Version #1 [4]
- Ballot Version #1 [7]
- Version #2 Pre-Release [17] and discussion [18]
- Version #2 (this version) [19]
The following motion has been proposed by Ryan Dickson and Chris Clements of Google (Chrome Root Program) and endorsed by Arvid Vermote (GlobalSign) and Pedro Fuentes (OISTE).
— 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.0.7.
MODIFY the Baseline Requirements as specified in the following Redline:
https://github.com/cabforum/servercert/compare/ba28d04894d69c8fac62850b9d0de5061658c7c5..7f2b54cfa5b89f41458a88211566ce508c464804
— Motion Ends —
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (no less than 7 days)
- Start: 2024-10-01 17:00:00 UTC
- End no earlier than: 2024-10-08 17:00:00 UTC
Vote for approval (7 days)
- Start: TBD
- End: TBD
Comments are welcome either on-list or with suggested edits via GitHub (preferred) at [19].
Thanks,Ryan
References:
[1] https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004900.html
[2] https://labs.watchtowr.com/we-spent-20-to-achieve-rce-and-accidentally-became-the-admins-of-mobi/
[3] https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/FuOi_uhQB6U/m/hKJOz3XzAAAJ
[4] https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/mAl9XjieSkA/m/oDNWxtPwAQAJ
[5] https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004839.html
[6] https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004844.html
[7] https://aws.amazon.com/blogs/security/aws-certificate-manager-will-discontinue-whois-lookup-for-email-validated-certificates/
[8] https://bugzilla.mozilla.org/show_bug.cgi?id=1917896
[9] https://cabforum.org/working-groups/server/baseline-requirements/requirements/#32247-dns-change
[10] https://cabforum.org/working-groups/server/baseline-requirements/requirements/#322419-agreed-upon-change-to-website---acme
[11] https://cabforum.org/working-groups/server/baseline-requirements/requirements/#3229-multi-perspective-issuance-corroboration
[12] https://cabforum.org/working-groups/server/baseline-requirements/requirements/#491-circumstances-for-revocation
[13] https://archive.cabforum.org/pipermail/servercert-wg/2018-August/000113.html
[14] https://lists.cabforum.org/pipermail/validation/2024-July/001995.html
[15] https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004825.html
[16] https://github.com/ryancdickson/staging/compare/356799f0dcfe11deb0a375a11233403236ab72c9..7a2ea7b33611bebf006a99a9a82729f183143eac
[17] https://github.com/ryancdickson/staging/compare/ba28d04894d69c8fac62850b9d0de5061658c7c5..7a2ea7b33611bebf006a99a9a82729f183143eac
[18] https://github.com/ryancdickson/staging/pull/9
[19] https://github.com/cabforum/servercert/pull/551
Mike Shaver
--
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 on the web visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/406a65a7-3695-450d-885a-3eb152d28702%40harica.gr.
Dimitris Zacharopoulos (HARICA)
Hi Dimitris,
I understand that you feel that ccTLDs are not, as a class, operated in a way that is less reliable than gTLDs, which makes a lot of sense. ccTLDs cover a wide range of jurisdictional priorities and historic investment in relevant infrastructure, which can certainly put them in different "postures" as far as suitability for use as a DCV component. Ideally, if we want registrar contact to be a DCV approach, we would have a way of systematically classifying each TLD's registrar as being suitable or not; I think you would agree that we lack that systematic capability right now, unfortunately!
You write of it being "unfair", though, and so I'm curious about what the negative impact would be on "suitable" ccTLDs if they were no longer consulted as part of DCV. Do these TLDs offer services or compete on the basis of being used in such a way? It seems to me that this is not damaging to them in any way. It's just a pragmatic compromise that takes advantage of gTLDs being a named group that share an appropriate governance profile in order to allow CAs to continue to consult them for DCV. We're starting from "we can't rely on the governance of registrars being consistently suitable", and then accepting (grudgingly, in my case at least!) that there is an easily-identifiable, and high-volume, group of registrars that happen to have appropriate governance. This doesn't benefit gTLD operators in any way, just CAs who trade in certificates issued against gTLD domains. I don't know why a gTLD or ccTLD operator would even care (or know?) if they were a permitted component of DCV, practically.
For the EU ccTLD Registries, the NIS 2 Directive (article 28) (and similar legislation prior to NIS2) has very specific provisions for TLD operators. The CA/B Forum should consider that 27 EU Member States (plus countries are not in the EU but follow the legal framework of the EU and implement the same legislation within their jurisdiction) is not a negligible part of the TLD Operators or the Internet.
To repeat myself a bit, this distinction is not to cast aspersions on any ccTLD's governance! It's just that ccTLDs are so varied in their operations that we don't want to codify reliance on them *as a group*. However, if there's another way to name a group in the policy such that we know that all members (and future members) will be governed in a way that is suitable for this use--which, of course, could be a use that is not anticipated by the ways they are regulated as "critical infrastructure" or similar--then I suspect that the WG would be amenable to naming that group as well. Is there a specific piece of legislation or accreditation that covers the ccTLDs you have in mind, and could be referenced succinctly perhaps? Enumerating specific ccTLDs is likely not workable, at least in my opinion.
Removing the special gTLD treatment would simplify things, though, and simplicity is a virtue that I feel the BRs too infrequently exhibit...
With that said, if you or other Members have proposals to simplify certain requirements, please share them and we will discuss.
Best regards,
Dimitris.
To view this discussion on the web visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CADQzZqv91uhNEAbewD4UjRz4vSH2CU2m201_diTX_P1-qbgj6w%40mail.gmail.com.
Ryan Dickson
Hi Dimitris,
Thank you for communicating these concerns.
To confirm my understanding:
- HARICA supports the sunset of methods 3.2.2.4.2 (“Email, Fax, SMS, or Postal Mail to Domain Contact") and 3.2.2.4.15 (“Phone Contact with Domain Contact”), beginning July 15, 2025.
- HARICA requests either:
- (A) the removal of “When issuing Subscriber Certificates, the CA MUST NOT rely on Domain Contact information obtained using the WHOIS protocol (RFC 3912) or the Registry Data Access Protocol (RFC 7482) if the requested Domain Name contains a ccTLD, regardless of whether previously obtained information is within the allowed reuse period.” from 3.2.2.4.2, 3.2.2.4.12, and 3.2.2.4.15, OR
- (B) a carve-out to the above prohibition for European ccTLDs / corresponding Registrars.
In general, I find carve outs like (B) undesirable because they add complexity. I also suspect other ccTLDs could also make similar claims about the assurances of how their corresponding Registrars are managed. Claims of this nature appear difficult to corroborate, and I don’t think it’s in the Forum’s interest or area of expertise to be responsible for evaluating the sustained accuracy and reliability of these claims.
Unless there are strong objections in doing so, we’d be comfortable with approach (A), given the July 15, 2025 sunsets.
Thanks,
Ryan
To view this discussion on the web visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/a4e3a756-7883-47f8-b8aa-d171ff74af27%40harica.gr.
Dimitris Zacharopoulos (HARICA)
Thank you very much for acknowledging HARICA's concerns and for your commitment to addressing them building the necessary consensus.
Hi Dimitris,
Thank you for communicating these concerns.
To confirm my understanding:
- HARICA supports the sunset of methods 3.2.2.4.2 (“Email, Fax, SMS, or Postal Mail to Domain Contact") and 3.2.2.4.15 (“Phone Contact with Domain Contact”), beginning July 15, 2025.
- HARICA requests either:
- (A) the removal of “When issuing Subscriber Certificates, the CA MUST NOT rely on Domain Contact information obtained using the WHOIS protocol (RFC 3912) or the Registry Data Access Protocol (RFC 7482) if the requested Domain Name contains a ccTLD, regardless of whether previously obtained information is within the allowed reuse period.” from 3.2.2.4.2, 3.2.2.4.12, and 3.2.2.4.15, OR
- (B) a carve-out to the above prohibition for European ccTLDs / corresponding Registrars.
In general, I find carve outs like (B) undesirable because they add complexity. I also suspect other ccTLDs could also make similar claims about the assurances of how their corresponding Registrars are managed. Claims of this nature appear difficult to corroborate, and I don’t think it’s in the Forum’s interest or area of expertise to be responsible for evaluating the sustained accuracy and reliability of these claims.
Unless there are strong objections in doing so, we’d be comfortable with approach (A), given the July 15, 2025 sunsets.
Thanks,
Dimitris.
To view this discussion on the web visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CADEW5O-watjcAx5WYE9SehZPqx%3DiJWEfQzfkwzrEngGDFfgK-g%40mail.gmail.com.
Ryan Dickson
- 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 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.
To view this discussion on the web visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/a151f1a6-d476-4c19-923f-d9e38de92be0%40harica.gr.