Hi Ryan, Thank you so much for your detailed feedback. Your insights are greatly appreciated. We also welcome feedback from anyone else.
Thanks, Yoshihiko Matsuo (JPRS) On Thu, 10 Oct 2024 10:41:02 -0400 Ryan Dickson <[email protected]> wrote: > Hi Yoshihiko, > > Thanks for clarifying your question. > > In my opinion, as currently written, the phrase “direct contact" is not > well-defined by the TLS BRs. > > My interpretation of “direct contact" between a CA and the Domain Name > Registrar is a phone-call or email between representatives of the two > organizations, possibly also involving some sort of automated system. > > To help better describe my interpretation, please see the illustrative > examples below: > > Phone or Email: > - CA representative calls/emails the Registrar. > - A representative of the Registrar authenticates the CA representative. > - The CA representative asks the Registrar representative to look up the > Domain Contact information for the target domain. > - The Registrar representative looks up the Domain Contact information by > relying on its authoritative database / source of truth, and shares this > with the CA representative. > - The CA representative uses the Domain Contact information as permitted by > the TLS BRs. > > Automated System: > - CA representative submits a form requesting Domain Contact information > from the Registrar. > - The Registrar authenticates the requestor. > - The Registrar looks up the Domain Contact information by relying on its > authoritative database / source of truth, and shares this with the CA > representative (e.g., phone or email). > - The CA representative uses the Domain Contact information as permitted by > the TLS BRs. > > My interpretation is heavily influenced by language in the TLS EVGs which, > in my opinion, establishes framing for the communication mechanisms > considered by “direct contact" through phrasing such as “or by direct > contact with the Incorporating or Registration Agency in person or via > mail, e‐mail, Web address, or telephone, using an address or phone number > obtained directly from the Qualified Government Information Source, > Incorporating or Registration Agency, or from a Qualified Independent > Information Source.” (from 3.2.2.2.2 (“Acceptable Method of Verification")) > > Consequently, I would not consider querying a Registrar’s WHOIS service to > constitute “direct contact.” I further interpret the WatchTowr report [1] > to have demonstrated flaws with several Registrar WHOIS-function websites. > > If this interpretation is misaligned with others’ expectations, discussion > is welcome. > > Thanks, > Ryan > > [1] > https://labs.watchtowr.com/we-spent-20-to-achieve-rce-and-accidentally-became-the-admins-of-mobi/ > > On Thu, Oct 10, 2024 at 6:27?AM Matsuo Yoshihiko <[email protected]> > wrote: > > > Hi Ryan, > > > > Thank you for your reply. > > > > I feel like I didn't express my points clearly in the previous email, so > > please disregard it. > > > > I apologize for the confusion, but I have reorganized the point I would > > like to confirm as follows: > > > > I am considering updating our system implementation for obtaining Domain > > Contact in light of this revision. > > > > BR defines the source of Domain Contact as follows. > > #1 WHOIS record > > #2 DNS SOA record > > #3 direct contact with the Domain Name Registrar > > > > The questions I would like to ask is... > > > > > > Could it be interpreted that retrieving Domain Contact information from > > the Whois operated by the Domain Name Registrar itself falls under "3 > > direct contact with the Domain Name Registrar"? > > I would like to hear your opinion on this. > > > > Thanks, > > > > Yoshihiko Matsuo(JPRS) > > > > > > On Tue, 8 Oct 2024 15:10:38 -0400 > > Ryan Dickson <[email protected]> wrote: > > > > > Hi Yoshihiko, > > > > > > The definition for “Domain Contact" (unchanged by the proposal) is: “The > > > Domain Name Registrant, technical contact, or administrative contact (or > > > the equivalent under a ccTLD) as listed in the WHOIS record of the Base > > > Domain Name or in a DNS SOA record, or as obtained through direct contact > > > with the Domain Name Registrar.” > > > > > > The definition for “Domain Name Registrar" (also unchanged by the > > proposal) > > > is: “A person or entity that registers Domain Names under the auspices of > > > or by agreement with: > > > - the Internet Corporation for Assigned Names and Numbers (ICANN), > > > - a national Domain Name authority/registry, or > > > *- a Network Information Center (including their affiliates, contractors, > > > delegates, successors, or assignees)*.” > > > > > > For the circumstances described in your message, can you please confirm > > > whether the organization operating the CA is considered: > > > - ONLY the ccTLD Domain Name Authority/Registry > > > - ONLY the Domain Name Registrar > > > - BOTH the ccTLD Domain Name Authority/Registry and sometimes a Domain > > Name > > > Registrar > > > - BOTH the ccTLD Domain Name Authority/Registry and always the Domain > > Name > > > Registrar > > > > > > Given the definition of “Domain Contact" and its reference in 3.2.2.4.2, > > > 3.2.2.4.12, and 3.2.2.4.15, I believe the distinction between roles > > (Domain > > > Name Authority/Registry and Domain Name Registrar) is important. > > > > > > Thanks, > > > > > > Ryan > > > > > > > > > > > > > > > On Tue, Oct 8, 2024 at 7:29?AM Yoshihiko Matsuo via Servercert-wg < > > > [email protected]> wrote: > > > > > > > All, > > > > > > > > > The only method relying on identifying a “Domain Contact" via > > > > registration data left by the ballot is 3.2.2.4.12 (“Validating > > Applicant > > > > as a Domain Contact"). This was originally excluded from the scope of > > > > sunsets given the expectation that in cases where the organization > > > > operating the CA was also the Domain Name Registrar (or an Affiliate), > > > > there would be (1) a lower likelihood of unreliable Domain Contact > > > > information given a direct relationship with the subscriber/subscriber > > > > organization, and (2) a higher potential for seamless certificate > > lifecycle > > > > management because of that relationship. Regardless of whether this > > > > expectation is misguided, nothing stops a future ballot from > > contemplating > > > > the further improvement or sunset of 3.2.2.4.12 (“Validating Applicant > > as a > > > > Domain Contact"). > > > > > > > > We are the CA, and at the same time we are also the gTLD Registrar and > > the > > > > ccTLD Registry. > > > > In this case, I understand that it is acceptable to use the Domain > > > > Contacts we hold as The gTLD Registrar for DCV.I would like to hear > > your > > > > opinions on whether the same can be said for the Domain Contacts we > > hold as > > > > the ccTLD Registry. > > > > > > > > Note: We require that ccTLD Domain Contacts be kept current as the > > contact > > > > information for the domain name registrant. > > > > > > > > With this question, I would like to clarify whether the BR allows the > > > > following cases. > > > > > > > > 1. The CA that is also the ccTLD Registry retrieves Domain Contacts > > from > > > > its own database and performs validation in accordance with 3.2.2.4.2. > > > > > > > > 2. The CA that is also the ccTLD Registry retrieves Domain Contacts > > from > > > > the WHOIS operated by the ccTLD Registry (which is also a CA) and > > performs > > > > validation in accordance with 3.2.2.4.2. > > > > > > > > Thanks, > > > > Yoshihiko Matsuo(JPRS) > > > > > > > > > > > > On 2024/10/08 4:49, Ryan Dickson via Servercert-wg wrote: > > > > > Hi Doug, > > > > > > > > > > > The title, purpose and background of this ballot define the > > removal > > > > of WHOIS and does not discuss any other changes, but we’re actually > > > > sunsetting other aspects of domain validation while also leaving method > > > > 3.2.2.4.12 that can continue to use WHOIS. > > > > > > > > > > I feel “Objective 2", included in the “Background" section, makes the > > > > intent to sunset methods clear (the objective's description is: > > "/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")/"). > > > > > > > > > > Would changing the title to something like “/Strengthen registration > > > > data lookups and Sunset Methods 3.2.2.4.2 and 3.2.2.4.15/" help? > > > > > > > > > > > I understand the desire to remove WHOIS based on the recent > > > > incident(s), but if we’re going to focus on sunsetting WHOIS, we should > > > > 100% sunset it for all uses and we should not include the removal of > > other > > > > methods within this ballot. > > > > > > > > > > All methods relying on identifying Domain Contacts via registration > > data > > > > are strengthened by this ballot, beginning January 15, 2025. This > > includes > > > > methods: > > > > > - 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") > > > > > - 3.2.2.4.15 (“Phone Contact with Domain Contact") > > > > > > > > > > The ballot goes on to sunset the following methods, beginning July > > 15, > > > > 2025: > > > > > - 3.2.2.4.2 (“Email, Fax, SMS, or Postal Mail to Domain Contact") > > > > > - 3.2.2.4.15 (“Phone Contact with Domain Contact") > > > > > > > > > > The only method relying on identifying a “Domain Contact" via > > > > registration data left by the ballot is 3.2.2.4.12 (“Validating > > Applicant > > > > as a Domain Contact"). This was originally excluded from the scope of > > > > sunsets given the expectation that in cases where the organization > > > > operating the CA was also the Domain Name Registrar (or an Affiliate), > > > > there would be (1) a lower likelihood of unreliable Domain Contact > > > > information given a direct relationship with the subscriber/subscriber > > > > organization, and (2) a higher potential for seamless certificate > > lifecycle > > > > management because of that relationship. Regardless of whether this > > > > expectation is misguided, nothing stops a future ballot from > > contemplating > > > > the further improvement or sunset of 3.2.2.4.12 (“Validating Applicant > > as a > > > > Domain Contact"). > > > > > > > > > > If there’s a case to make for including 3.2.2.4.12 in the sunsets > > > > covered in the proposal, it’s also welcome. > > > > > > > > > > > The VWG can be tasked to review methods we think are weak and > > discuss > > > > removing them, for example, imo, all the methods that rely on phone > > calls > > > > (Domain and IP address both), which to me are weaker than automated > > methods > > > > like using they SOA record. > > > > > > > > > > I agree that it’s important for this community to routinely > > re-evaluate > > > > the DCV methods permitted by the TLS BRs and consider them against a > > set of > > > > desirable security and operational properties that best enable > > subscriber > > > > organizations to make securely managing their TLS implementations > > “boring" > > > > (effortless, routine, reliable, and without excitement - even when > > facing > > > > the unexpected). > > > > > > > > > > Periodically over the past three years (when I joined this > > community), > > > > I’ve participated in discussions where members have expressed a desire > > for > > > > improved DCV methods, which has included suggestions to remove > > perceived > > > > weak methods (with those that are phone or email-based cited as > > examples). > > > > While very few of these discussions have led to direct action, this > > ballot > > > > presents a proactive opportunity to address some of those concerns, > > along > > > > with mitigating concerns related to registration data lookups > > identified by > > > > recent events. > > > > > > > > > > I do not believe a holistic evaluation of the DCV-methods permitted > > by > > > > the TLS BRs needs to be a blocking function on this ballot, and that > > both > > > > activities can take place independently of one another. > > > > > > > > > > Thanks, > > > > > Ryan > > > > > > > > > > > > > > > On Mon, Oct 7, 2024 at 7:35?AM Doug Beattie < > > [email protected] > > > > <mailto:[email protected]>> wrote: > > > > > > > > > > Hi Ryan,____ > > > > > > > > > > __ __ > > > > > > > > > > The title, purpose and background of this ballot define the > > removal > > > > of WHOIS and does not discuss any other changes, but we’re actually > > > > sunsetting other aspects of domain validation while also leaving method > > > > 3.2.2.4.12 that can continue to use WHOIS. Part of this is the > > > > unfortunately extremely broad definition of “Domain Contact” and > > “Domain > > > > Name Registrant” and the wide scope of 3.2.2.4.2, which I agree we > > need to > > > > clarify and fix. I understand the desire to remove WHOIS based on the > > > > recent incident(s), but if we’re going to focus on sunsetting WHOIS, we > > > > should 100% sunset if for all uses and we should not include the > > removal of > > > > other methods within this ballot. The VWG can be tasked to review > > methods > > > > we think are weak and discuss removing them, for example, imo, all the > > > > methods that rely on phone calls (Domain and IP address both), which > > to me > > > > are weaker than automated methods like using they SOA record.____ > > > > > > > > > > __ __ > > > > > > > > > > Doug____ > > > > > > > > > > __ __ > > > > > > > > > > *From:*Ryan Dickson <[email protected] <mailto: > > > > [email protected]>> > > > > > *Sent:* Friday, October 4, 2024 2:55 PM > > > > > *To:* Doug Beattie <[email protected] <mailto: > > > > [email protected]>> > > > > > *Cc:* CA/B Forum Server Certificate WG Public Discussion List < > > > > [email protected] <mailto:[email protected]>> > > > > > *Subject:* Re: [Servercert-wg] Discussion Period Begins - Ballot > > > > SC-080 V2: "Sunset the use of WHOIS to identify Domain Contacts and > > relying > > > > DCV Methods”____ > > > > > > > > > > __ __ > > > > > > > > > > Hi Doug,____ > > > > > > > > > > __ __ > > > > > > > > > > Your interpretation of the latest version of the ballot is > > correct. > > > > ____ > > > > > > > > > > __ __ > > > > > > > > > > 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. > > > > ____ > > > > > > > > > > __ __ > > > > > > > > > > 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)?____ > > > > > > > > > > __ __ > > > > > > > > > > For example, detailing responses below would be helpful for > > > > understanding:____ > > > > > > > > > > * existing reliance on this specific approach in comparison to > > the > > > > other DCV methods offered?____ > > > > > * how this reliance has trended over time (e.g., last 1 / 3 / 5 > > > > years)?____ > > > > > * how the sunset would affect subscribers?____ > > > > > * a general description of the level of effort for affected > > > > subscribers to transition to another method?____ > > > > > * what barriers exist that prevent subscribers from > > transitioning > > > > to other methods?____ > > > > > > > > > > __ __ > > > > > > > > > > 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:____ > > > > > > > > > > * 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).____ > > > > > * potential CA reliance on third-party tools with unknown > > > > operational characteristics for performing SOA lookups (the same > > concern as > > > > WHOIS lookups using HTTPS websites).____ > > > > > * a lack of oversight and enforcement for ensuring SOA record > > > > updates (e.g, accuracy/correctness and timeliness).____ > > > > > * 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).____ > > > > > > > > > > __ __ > > > > > > > > > > Thanks,____ > > > > > > > > > > Ryan____ > > > > > > > > > > __ __ > > > > > > > > > > [1] https://mkorczynski.com/WTMC2020.pdf < > > > > https://mkorczynski.com/WTMC2020.pdf>____ > > > > > > > > > > __ __ > > > > > > > > > > __ __ > > > > > > > > > > On Thu, Oct 3, 2024 at 9:57?AM Doug Beattie < > > > > [email protected] <mailto:[email protected]>> > > > > wrote:____ > > > > > > > > > > Hey Ryan,____ > > > > > > > > > > ____ > > > > > > > > > > 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?____ > > > > > > > > > > > > > > > Doug____ > > > > > > > > > > ____ > > > > > > > > > > *From:*Servercert-wg <[email protected] > > > > <mailto:[email protected]>> *On Behalf Of *Ryan > > Dickson > > > > via Servercert-wg > > > > > *Sent:* Tuesday, October 1, 2024 12:59 PM > > > > > *To:* ServerCert CA/BF <[email protected] <mailto: > > > > [email protected]>> > > > > > *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 > > > > < > > > > > > https://github.com/cabforum/servercert/compare/ba28d04894d69c8fac62850b9d0de5061658c7c5..7f2b54cfa5b89f41458a88211566ce508c464804 > > > > > > > > > > > > > > > ? 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>____ > > > > > > > > > > ____ > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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
