<div dir="ltr">[Responding to the most recent message in the discussion, apologies if this causes unexpected threading.]<div><br></div>Hi all,<br><br>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).<br><br><b><u>Objective 1: Enhance WHOIS/RDAP validation of gTLDs with comparable security properties to DNS-based validation and sunset WHOIS/RDAP for ccTLDs.<br></u></b><br><b>Justification: <br></b><ul><li>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.</li><li>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.</li><li>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.</li><li>Solutions to strengthen existing WHOIS lookup methods were proposed in [4] and are considered in this update.</li></ul><b>Approach: </b><br><ul><li>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”).</li></ul>“<i>Effective January 15, 2025, when issuing Subscriber Certificates…<br></i><ul><li><i>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.</i></li><li><i>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.</i></li><li><i>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.</i></li><li><i>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.</i></li><li><i>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.</i>”</li></ul><br><b><u>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”).<br></u></b><br><b>Justification:</b><br><ul><li>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].</li><li>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].</li><li>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].</li><li>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.</li></ul><b>Approach:</b><div><ul><li>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”).</li></ul>“<i>Effective September 15, 2025, the CA MUST NOT rely on this method.</i>”<br><br><br>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]).<br><br>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]<br><br>Comments are welcome either on-list or with suggested edits via GitHub (preferred) at [17].<br><br>Thanks,<br>Ryan<br><br>[1] <a href="https://labs.watchtowr.com/we-spent-20-to-achieve-rce-and-accidentally-became-the-admins-of-mobi/" target="_blank">https://labs.watchtowr.com/we-spent-20-to-achieve-rce-and-accidentally-became-the-admins-of-mobi/</a><br>[2] <a href="https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/FuOi_uhQB6U/m/hKJOz3XzAAAJ" target="_blank">https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/FuOi_uhQB6U/m/hKJOz3XzAAAJ</a><br>[3] <a href="https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/mAl9XjieSkA/m/oDNWxtPwAQAJ" target="_blank">https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/mAl9XjieSkA/m/oDNWxtPwAQAJ</a><br>[4] <a href="https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004839.html" target="_blank">https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004839.html</a><br>[5] <a href="https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004844.html" target="_blank">https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004844.html</a><br>[6] <a href="https://aws.amazon.com/blogs/security/aws-certificate-manager-will-discontinue-whois-lookup-for-email-validated-certificates/" target="_blank">https://aws.amazon.com/blogs/security/aws-certificate-manager-will-discontinue-whois-lookup-for-email-validated-certificates/</a><br>[7] <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1917896" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=1917896</a><br>[8] <a href="https://cabforum.org/working-groups/server/baseline-requirements/requirements/#32247-dns-change" target="_blank">https://cabforum.org/working-groups/server/baseline-requirements/requirements/#32247-dns-change</a><br>[9] <a href="https://cabforum.org/working-groups/server/baseline-requirements/requirements/#322419-agreed-upon-change-to-website---acme" target="_blank">https://cabforum.org/working-groups/server/baseline-requirements/requirements/#322419-agreed-upon-change-to-website---acme</a><br>[10] <a href="https://cabforum.org/working-groups/server/baseline-requirements/requirements/#3229-multi-perspective-issuance-corroboration" target="_blank">https://cabforum.org/working-groups/server/baseline-requirements/requirements/#3229-multi-perspective-issuance-corroboration</a><br>[11] <a href="https://cabforum.org/working-groups/server/baseline-requirements/requirements/#491-circumstances-for-revocation" target="_blank">https://cabforum.org/working-groups/server/baseline-requirements/requirements/#491-circumstances-for-revocation</a><br>[12] <a href="https://archive.cabforum.org/pipermail/servercert-wg/2018-August/000113.html" target="_blank">https://archive.cabforum.org/pipermail/servercert-wg/2018-August/000113.html</a><br>[13] <a href="https://lists.cabforum.org/pipermail/validation/2024-July/001995.html" target="_blank">https://lists.cabforum.org/pipermail/validation/2024-July/001995.html</a><br>[14] <a href="https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004825.html" target="_blank">https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004825.html</a><br>[15] <a href="https://github.com/ryancdickson/staging/compare/356799f0dcfe11deb0a375a11233403236ab72c9..7a2ea7b33611bebf006a99a9a82729f183143eac" target="_blank">https://github.com/ryancdickson/staging/compare/356799f0dcfe11deb0a375a11233403236ab72c9..7a2ea7b33611bebf006a99a9a82729f183143eac</a><br>[16] <a href="https://github.com/ryancdickson/staging/compare/ba28d04894d69c8fac62850b9d0de5061658c7c5..7a2ea7b33611bebf006a99a9a82729f183143eac" target="_blank">https://github.com/ryancdickson/staging/compare/ba28d04894d69c8fac62850b9d0de5061658c7c5..7a2ea7b33611bebf006a99a9a82729f183143eac</a><br>[17] <a href="https://github.com/ryancdickson/staging/pull/9" target="_blank">https://github.com/ryancdickson/staging/pull/9</a><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 18, 2024 at 3:11 PM Amir Omidi via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I do not know much about the state of subdomain auth deployment in the CA ecosystem unfortunately.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 18, 2024 at 2:09 PM Andrew Ayer <<a href="mailto:agwa@andrewayer.name" target="_blank">agwa@andrewayer.name</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Amir,<br>
<br>
On Wed, 18 Sep 2024 15:48:38 +0000<br>
Amir Omidi via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a>> wrote:<br>
<br>
> There are two CAs (Let's Encrypt and Google Trust Services) with<br>
> DNS-ACCOUNT-01 (<br>
> <a href="https://datatracker.ietf.org/doc/draft-ietf-acme-scoped-dns-challenges/" rel="noreferrer" target="_blank">https://datatracker.ietf.org/doc/draft-ietf-acme-scoped-dns-challenges/</a>)<br>
> mostly ready to go. This draft is designed to solve the CNAME<br>
> delegation problem.<br>
<br>
It doesn't obviate the need to run an acme-dns server (or similar) but<br>
DNS-ACCOUNT-01 would indeed be a great help.  Note that RFC9444<br>
(subdomain auth) support is also needed as otherwise the subscriber<br>
has to add delegations for every hostname instead of just one per zone.<br>
Do you know what the state of CA adoption is there?<br>
<br>
In any case, I'll give this I-D a more thorough look and provide<br>
feedback in the ACME WG.<br>
<br>
Regards,<br>
Andrew<br>
</blockquote></div>
_______________________________________________<br>
Servercert-wg mailing list<br>
<a href="mailto:Servercert-wg@cabforum.org" target="_blank">Servercert-wg@cabforum.org</a><br>
<a href="https://lists.cabforum.org/mailman/listinfo/servercert-wg" rel="noreferrer" target="_blank">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><br>
</blockquote></div>