<div dir="ltr"><span id="m_5104295660654064551gmail-docs-internal-guid-10ec4afd-7fff-4d51-b6ec-1215032d93bd"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline"><font face="arial, sans-serif">Hi Doug,</font></span></p><font face="arial, sans-serif"><br></font><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline"><font face="arial, sans-serif">Your interpretation of the latest version of the ballot is correct. </font></span></p><font face="arial, sans-serif"><br></font><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline"><font face="arial, sans-serif">As currently presented, Method 3.2.2.4.2 (“Email, Fax, SMS, or Postal Mail to Domain Contact”) and Method 3.2.2.4.15 (“Phone Contact with Domain Contact”) are sunset, in their entirety, effective July 15, 2025. </font></span></p><font face="arial, sans-serif"><br></font><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline"><font face="arial, sans-serif">Specific to domain contact email addresses from SOA records, can you share your perspective for adding this specific option given the existence of (1) other email-based alternatives (e.g., 3.2.2.4.4, 3.2.2.4.13 and 3.2.2.4.14) and (2) other far more heavily relied upon DCV methods that present an opportunity for improved automation and scalability (and also benefit from MPIC)?</font></span></p><font face="arial, sans-serif"><br></font><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;text-decoration-line:underline;vertical-align:baseline"><font face="arial, sans-serif">For example, detailing responses below would be helpful for understanding:</font></span></p><ul><li><span id="m_5104295660654064551gmail-docs-internal-guid-10ec4afd-7fff-4d51-b6ec-1215032d93bd">existing reliance on this specific approach in comparison to the other DCV methods offered?</span></li><li><span id="m_5104295660654064551gmail-docs-internal-guid-10ec4afd-7fff-4d51-b6ec-1215032d93bd">how this reliance has trended over time (e.g., last 1 / 3 / 5 years)?</span></li><li><span id="m_5104295660654064551gmail-docs-internal-guid-10ec4afd-7fff-4d51-b6ec-1215032d93bd">how the sunset would affect subscribers?</span></li><li><span id="m_5104295660654064551gmail-docs-internal-guid-10ec4afd-7fff-4d51-b6ec-1215032d93bd">a general description of the level of effort for affected subscribers to transition to another method?</span></li><li><span id="m_5104295660654064551gmail-docs-internal-guid-10ec4afd-7fff-4d51-b6ec-1215032d93bd">what barriers exist that prevent subscribers from transitioning to other methods?</span></li></ul><p dir="ltr" style="line-height:1.38;margin-top:10pt;margin-bottom:10pt"><span style="font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline"><font face="arial, sans-serif"><br></font></span></p><p dir="ltr" style="line-height:1.38;margin-top:10pt;margin-bottom:10pt"><span style="font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline"><font face="arial, sans-serif">I think it’s reasonable for the community to approach RNAME lookups with the same degree of concern for accuracy and reliability as registration data due to the potential for:</font></span></p><ul><li><span id="m_5104295660654064551gmail-docs-internal-guid-10ec4afd-7fff-4d51-b6ec-1215032d93bd">neglected configurations (e.g., in 2020, [1] indicated only 39.74% of a set of “top” 1M domains contained “reachable” SOA contacts, and only approximately 20% of the sampled .com and .net domains did).</span></li><li><span id="m_5104295660654064551gmail-docs-internal-guid-10ec4afd-7fff-4d51-b6ec-1215032d93bd">potential CA reliance on third-party tools with unknown operational characteristics for performing SOA lookups (the same concern as WHOIS lookups using HTTPS websites).</span></li><li><span id="m_5104295660654064551gmail-docs-internal-guid-10ec4afd-7fff-4d51-b6ec-1215032d93bd">a lack of oversight and enforcement for ensuring SOA record updates (e.g, accuracy/correctness and timeliness).</span></li><li><span id="m_5104295660654064551gmail-docs-internal-guid-10ec4afd-7fff-4d51-b6ec-1215032d93bd">use of automated DNS management solutions that can result in an unintended and/or unknown delegation of authority to approve TLS certificates, while also representing a single point of failure (or attack).</span></li></ul><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline"><font face="arial, sans-serif"><br></font></span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline"><font face="arial, sans-serif">Thanks,</font></span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline"><font face="arial, sans-serif">Ryan</font></span></p><font face="arial, sans-serif"><br></font><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline"><font face="arial, sans-serif">[1] <a href="https://mkorczynski.com/WTMC2020.pdf" target="_blank">https://mkorczynski.com/WTMC2020.pdf</a></font></span></p></span><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 3, 2024 at 9:57 AM Doug Beattie <<a href="mailto:doug.beattie@globalsign.com" target="_blank">doug.beattie@globalsign.com</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><div lang="EN-US"><div><p class="MsoNormal"><span style="font-size:11pt">Hey Ryan,<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt">The way I read the ballot is that using domain approver email addresses from SOA records is being removed since that’s part of 3.2.2.4.2.   Should we add a new method specifically for that, or was the intent to remove that as a valid location to obtain domain approver email addresses?<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt"><br>Doug<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p><div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in"><p class="MsoNormal"><b><span style="font-size:11pt;font-family:Calibri,sans-serif">From:</span></b><span style="font-size:11pt;font-family:Calibri,sans-serif"> Servercert-wg <<a href="mailto:servercert-wg-bounces@cabforum.org" target="_blank">servercert-wg-bounces@cabforum.org</a>> <b>On Behalf Of </b>Ryan Dickson via Servercert-wg<br><b>Sent:</b> Tuesday, October 1, 2024 12:59 PM<br><b>To:</b> ServerCert CA/BF <<a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a>><br><b>Subject:</b> [Servercert-wg] Discussion Period Begins - Ballot SC-080 V2: "Sunset the use of WHOIS to identify Domain Contacts and relying DCV Methods”<u></u><u></u></span></p></div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal" style="margin-bottom:12pt"><b><u>Purpose of Ballot SC-080 V2:<br></u></b>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.<br><br><b><u>Background:<br></u></b>This ballot intends to accomplish two objectives, originally described in [1].<u></u><u></u></p><div><p class="MsoNormal">Objective 1: Enhance WHOIS/RDAP validation of gTLDs with comparable security properties to DNS-based validation and sunset WHOIS/RDAP for ccTLDs.<br><br><u>Justification:</u><u></u><u></u></p><ul type="disc"><li class="MsoNormal">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.<u></u><u></u></li><li class="MsoNormal">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.<u></u><u></u></li><li class="MsoNormal">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.<u></u><u></u></li><li class="MsoNormal">Solutions to strengthen existing WHOIS lookup methods were proposed in [5] and are considered in this ballot.<u></u><u></u></li></ul><div><p class="MsoNormal"><u></u> <u></u></p></div><p class="MsoNormal">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><br><u>Justification:</u><u></u><u></u></p><ul type="disc"><li class="MsoNormal">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].<u></u><u></u></li><li class="MsoNormal">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].<u></u><u></u></li><li class="MsoNormal">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].<u></u><u></u></li><li class="MsoNormal">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.<u></u><u></u></li></ul><p class="MsoNormal"><br><b><u>Benefits of adoption:</u></b><u></u><u></u></p><ul type="disc"><li class="MsoNormal">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]).  <u></u><u></u></li><li class="MsoNormal">Increased Agility: Encourages site owners to transition to modern DCV methods, creating opportunities for faster, more efficient, and less error-prone certificate lifecycle management.  <u></u><u></u></li><li class="MsoNormal">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.<u></u><u></u></li></ul><p class="MsoNormal"><br><b><u>Proposed Key Dates:</u></b><u></u><u></u></p></div><div><p class="MsoNormal">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.<u></u><u></u></p><ul type="disc"><li class="MsoNormal">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.  <u></u><u></u></li><li class="MsoNormal">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.<u></u><u></u></li></ul><p class="MsoNormal"><br><b><u>Proposal Revision History:</u></b><u></u><u></u></p><ul type="disc"><li class="MsoNormal">Pre-Ballot Version #1 [4]<u></u><u></u></li><li class="MsoNormal">Ballot Version #1 [7]<u></u><u></u></li><li class="MsoNormal">Version #2 Pre-Release [17] and discussion [18]<u></u><u></u></li><li class="MsoNormal">Version #2 (this version) [19]<u></u><u></u></li></ul><p class="MsoNormal"><br>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).<u></u><u></u></p></div><div><p class="MsoNormal"><br>— Motion Begins —<br><br>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.<br><br>MODIFY the Baseline Requirements as specified in the following Redline:<br><br><a href="https://github.com/cabforum/servercert/compare/ba28d04894d69c8fac62850b9d0de5061658c7c5..7f2b54cfa5b89f41458a88211566ce508c464804" target="_blank">https://github.com/cabforum/servercert/compare/ba28d04894d69c8fac62850b9d0de5061658c7c5..7f2b54cfa5b89f41458a88211566ce508c464804</a> <br><br>— Motion Ends —<br><br>This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:<br><br><u>Discussion (no less than 7 days)</u><u></u><u></u></p><ul type="disc"><li class="MsoNormal">Start: 2024-10-01 17:00:00 UTC<u></u><u></u></li><li class="MsoNormal">End no earlier than: 2024-10-08 17:00:00 UTC<u></u><u></u></li></ul><p class="MsoNormal"><br><u>Vote for approval (7 days)</u><u></u><u></u></p><ul type="disc"><li class="MsoNormal">Start: TBD<u></u><u></u></li><li class="MsoNormal">End: TBD<u></u><u></u></li></ul><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Comments are welcome either on-list or with suggested edits via GitHub (preferred) at [19].<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Thanks,<u></u><u></u></p></div><div><p class="MsoNormal">Ryan<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><p style="margin:0in"><b><span style="font-size:11pt;font-family:Arial,sans-serif;color:black">References:</span></b><u></u><u></u></p><p style="margin:0in">[1] <a href="https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004900.html" target="_blank">https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004900.html</a><br>[2] <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>[3] <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>[4] <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>[5] <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>[6] <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>[7] <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>[8] <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1917896" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=1917896</a><br>[9] <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>[10] <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>[11] <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>[12] <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>[13] <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>[14] <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>[15] <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>[16] <a href="https://github.com/ryancdickson/staging/compare/356799f0dcfe11deb0a375a11233403236ab72c9..7a2ea7b33611bebf006a99a9a82729f183143eac" target="_blank">https://github.com/ryancdickson/staging/compare/356799f0dcfe11deb0a375a11233403236ab72c9..7a2ea7b33611bebf006a99a9a82729f183143eac</a><br>[17] <a href="https://github.com/ryancdickson/staging/compare/ba28d04894d69c8fac62850b9d0de5061658c7c5..7a2ea7b33611bebf006a99a9a82729f183143eac" target="_blank">https://github.com/ryancdickson/staging/compare/ba28d04894d69c8fac62850b9d0de5061658c7c5..7a2ea7b33611bebf006a99a9a82729f183143eac</a><br>[18] <a href="https://github.com/ryancdickson/staging/pull/9" target="_blank">https://github.com/ryancdickson/staging/pull/9</a><br>[19] <a href="https://github.com/cabforum/servercert/pull/551" target="_blank">https://github.com/cabforum/servercert/pull/551</a><u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div></div></div></div></div></blockquote></div>