[Servercert-wg] Discussion Period Begins - Ballot SC-080 V2: "Sunset the use of WHOIS to identify Domain Contacts and relying DCV Methods”

Tue Oct 1 16:59:00 UTC 2024

*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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20241001/ac92e59d/attachment-0001.html>