Hi Ryan, Both of these objectives are valuable outcomes to pursue, from my perspective. Regarding Objective 2, I think a shorter timeline for an effective date is desirable, especially in relation to 3.2.2.4.2’s inclusion of Fax, SMS, and Postal Mail as communication mediums for domain validation. I would suggest July 15, 2025 as a reasonable date which still meets the criteria you provided, excepting that it doesn’t match an effective date already present in the TBRs. Other than that, I think these objectives and the overall proposal are sound and provide demonstrable improvement to the overall security of domain validation. Thank you for spearheading this!
Cheers, -Clint > On Sep 23, 2024, at 12:48 PM, Ryan Dickson via Servercert-wg > <servercert-wg@cabforum.org> 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 > <servercert-wg@cabforum.org <mailto:servercert-wg@cabforum.org>> 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 <a...@andrewayer.name >> <mailto:a...@andrewayer.name>> wrote: >>> Hi Amir, >>> >>> On Wed, 18 Sep 2024 15:48:38 +0000 >>> Amir Omidi via Servercert-wg <servercert-wg@cabforum.org >>> <mailto:servercert-wg@cabforum.org>> 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 >> Servercert-wg@cabforum.org <mailto:Servercert-wg@cabforum.org> >> https://lists.cabforum.org/mailman/listinfo/servercert-wg > _______________________________________________ > Servercert-wg mailing list > Servercert-wg@cabforum.org > https://lists.cabforum.org/mailman/listinfo/servercert-wg
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Servercert-wg mailing list Servercert-wg@cabforum.org https://lists.cabforum.org/mailman/listinfo/servercert-wg
