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-boun...@cabforum.org> on behalf of Ryan
Dickson via Servercert-wg <servercert-wg@cabforum.org>
Date: Tuesday, 1. October 2024 at 19.59
To: ServerCert CA/BF <servercert-wg@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
<_blank>
— 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>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Servercert-wg mailing list Servercert-wg@cabforum.org https://lists.cabforum.org/mailman/listinfo/servercert-wg
