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

Wed Oct 2 13:05:23 UTC 2024

Hi Antti,

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

On Wed, Oct 2, 2024 at 1:21 AM Backman, Antti <
antti.backman at teliacompany.com> wrote:

> 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
>
>
>
> *From: *Servercert-wg <servercert-wg-bounces at cabforum.org> on behalf of
> Ryan Dickson via Servercert-wg <servercert-wg at cabforum.org>
> *Date: *Tuesday, 1. October 2024 at 19.59
> *To: *ServerCert CA/BF <servercert-wg at 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
>
> — 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/20241002/2042016d/attachment.html>