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 < [email protected]> 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 <[email protected]> on behalf of > Ryan Dickson via Servercert-wg <[email protected]> > *Date: *Tuesday, 1. October 2024 at 19.59 > *To: *ServerCert CA/BF <[email protected]> > *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 > > >
_______________________________________________ Servercert-wg mailing list [email protected] https://lists.cabforum.org/mailman/listinfo/servercert-wg
