I guess that if the aim is parity with DNS-based validation (which I agree it should be), one question is "what is the equivalent of MPIC for WHOIS, and is it feasible to do?"
Mike On Mon, Sep 23, 2024 at 3:48 PM Ryan Dickson via Servercert-wg < [email protected]> wrote: > [Responding to the most recent message in the discussion, apologies if > this causes unexpected threading.] > > Hi all, > > Given the discussion thus far, I’d like to propose the following for the > group’s consideration in an effort to help guide a second round of > discussion (TBD, but expected to begin no earlier than September 30). > > > *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 [1] 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 > [2] 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 [3] 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 [4] and are considered in this update. > > *Approach: * > > - Add the following requirements in Sections 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”), and 3.2.2.4.15 (“Phone Contact with Domain > Contact”). > > “ > *Effective January 15, 2025, 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.* > - *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.* > - *When obtaining Domain Contact information using the WHOIS protocol, > the CA MUST query IANA's WHOIS server and follow referrals to the > appropriate gTLD WHOIS server.* > - *When obtaining Domain Contact information using the Registry Data > Access Protocol, the CA MUST utilize IANA's bootstrap file to identify and > query the correct RDAP server for the domain.* > - *The CA SHOULD NOT rely on cached 1) WHOIS server information or 2) > RDAP bootstrap data from IANA to ensure that it relies upon up-to-date and > accurate information.*” > > > > *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 update (above), there is limited public evidence of > significant reliance on these methods, including in response to [2] and > [5]. > - Instead, discussion has identified at least one CA Owner has already > sunset reliance on WHOIS [6], and another that has changed its approach [7] > for relying on WHOIS since disclosure of [1]. > - 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., [8] and [9]), > while also benefiting from recently improved security practices [10]. 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 [11]. > - Beyond the above, previous discussions within the CA/Browser Forum > have raised concerns about the perceived value (e.g., [12]) and security > (e.g., [13]) of the DCV methods relying on WHOIS, further supporting the > rationale for their gradual sunset. > > *Approach:* > > - Add the following requirements to Sections 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”). > > “*Effective September 15, 2025, the CA MUST NOT rely on this method.*” > > > The effective dates considered in this update are intended to 1) address > the immediate concerns identified by [1], 2) offer near-term and > longer-term transition periods for subscribers and CA Owners relying on > existing implementations of these methods, and 3) align with existing > effective dates in the TLS BRs (e.g., [10]). > > The above proposed updates compared to the initial effort described in > [14] are highlighted at [15]. A comparison of these proposed updates > against the in-force BRs is available at [16] > > Comments are welcome either on-list or with suggested edits via GitHub > (preferred) at [17]. > > Thanks, > Ryan > > [1] > https://labs.watchtowr.com/we-spent-20-to-achieve-rce-and-accidentally-became-the-admins-of-mobi/ > [2] > https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/FuOi_uhQB6U/m/hKJOz3XzAAAJ > [3] > https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/mAl9XjieSkA/m/oDNWxtPwAQAJ > [4] > https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004839.html > [5] > https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004844.html > [6] > https://aws.amazon.com/blogs/security/aws-certificate-manager-will-discontinue-whois-lookup-for-email-validated-certificates/ > [7] https://bugzilla.mozilla.org/show_bug.cgi?id=1917896 > [8] > https://cabforum.org/working-groups/server/baseline-requirements/requirements/#32247-dns-change > [9] > https://cabforum.org/working-groups/server/baseline-requirements/requirements/#322419-agreed-upon-change-to-website---acme > [10] > https://cabforum.org/working-groups/server/baseline-requirements/requirements/#3229-multi-perspective-issuance-corroboration > [11] > https://cabforum.org/working-groups/server/baseline-requirements/requirements/#491-circumstances-for-revocation > [12] > https://archive.cabforum.org/pipermail/servercert-wg/2018-August/000113.html > [13] https://lists.cabforum.org/pipermail/validation/2024-July/001995.html > [14] > https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004825.html > [15] > https://github.com/ryancdickson/staging/compare/356799f0dcfe11deb0a375a11233403236ab72c9..7a2ea7b33611bebf006a99a9a82729f183143eac > [16] > https://github.com/ryancdickson/staging/compare/ba28d04894d69c8fac62850b9d0de5061658c7c5..7a2ea7b33611bebf006a99a9a82729f183143eac > [17] https://github.com/ryancdickson/staging/pull/9 > > > On Wed, Sep 18, 2024 at 3:11 PM Amir Omidi via Servercert-wg < > [email protected]> wrote: > >> I do not know much about the state of subdomain auth deployment in the CA >> ecosystem unfortunately. >> >> On Wed, Sep 18, 2024 at 2:09 PM Andrew Ayer <[email protected]> wrote: >> >>> Hi Amir, >>> >>> On Wed, 18 Sep 2024 15:48:38 +0000 >>> Amir Omidi via Servercert-wg <[email protected]> wrote: >>> >>> > There are two CAs (Let's Encrypt and Google Trust Services) with >>> > DNS-ACCOUNT-01 ( >>> > >>> https://datatracker.ietf.org/doc/draft-ietf-acme-scoped-dns-challenges/) >>> > mostly ready to go. This draft is designed to solve the CNAME >>> > delegation problem. >>> >>> It doesn't obviate the need to run an acme-dns server (or similar) but >>> DNS-ACCOUNT-01 would indeed be a great help. Note that RFC9444 >>> (subdomain auth) support is also needed as otherwise the subscriber >>> has to add delegations for every hostname instead of just one per zone. >>> Do you know what the state of CA adoption is there? >>> >>> In any case, I'll give this I-D a more thorough look and provide >>> feedback in the ACME WG. >>> >>> Regards, >>> Andrew >>> >> _______________________________________________ >> Servercert-wg mailing list >> [email protected] >> https://lists.cabforum.org/mailman/listinfo/servercert-wg >> > _______________________________________________ > Servercert-wg mailing list > [email protected] > https://lists.cabforum.org/mailman/listinfo/servercert-wg >
_______________________________________________ Servercert-wg mailing list [email protected] https://lists.cabforum.org/mailman/listinfo/servercert-wg
