<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 10/10/2024 5:42 μ.μ., Ryan Dickson
      via Servercert-wg wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:0100019276e15d14-7de2fd6e-5a22-4591-b87d-23319bad8022-000000@email.amazonses.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">Hi Yoshihiko,<br>
        <br>
        Thanks for clarifying your question.<br>
        <br>
        In my opinion, as currently written, the phrase “direct contact"
        is not well-defined by the TLS BRs. <br>
        <br>
        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.<br>
        <br>
        To help better describe my interpretation, please see the
        illustrative examples below:<br>
        <br>
        Phone or Email:<br>
        - CA representative calls/emails the Registrar.<br>
        - A representative of the Registrar authenticates the CA
        representative.<br>
        - The CA representative asks the Registrar representative to
        look up the Domain Contact information for the target domain.<br>
        - 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.<br>
        - The CA representative uses the Domain Contact information as
        permitted by the TLS BRs.<br>
      </div>
    </blockquote>
    <br>
    <blockquote type="cite"
cite="mid:0100019276e15d14-7de2fd6e-5a22-4591-b87d-23319bad8022-000000@email.amazonses.com">
      <div dir="ltr"><br>
        Automated System:<br>
        - CA representative submits a form requesting Domain Contact
        information from the Registrar.<br>
        - The Registrar authenticates the requestor.<br>
        <div>- 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).<br>
          - The CA representative uses the Domain Contact information as
          permitted by the TLS BRs.</div>
        <div><br>
        </div>
      </div>
    </blockquote>
    <br>
    Hi Ryan,<br>
    <br>
    I don't think the Registrar needs to necessarily authenticate the CA
    representative. Some Registrars offer the Domain Contact information
    publicly. It is similar to the WHOIS process where no authentication
    is needed by default.<br>
    <br>
    <blockquote type="cite"
cite="mid:0100019276e15d14-7de2fd6e-5a22-4591-b87d-23319bad8022-000000@email.amazonses.com">
      <div dir="ltr">
        <div>
          <div>
            <div>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"))<br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Equally, the Applicant doesn't need to "authenticate" the CA for the
    communication to be considered "direct".<br>
    <br>
    <blockquote type="cite"
cite="mid:0100019276e15d14-7de2fd6e-5a22-4591-b87d-23319bad8022-000000@email.amazonses.com">
      <div dir="ltr">
        <div>
          <div>
            <div><br>
              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.<br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    I kind of disagree because the intent of the requirement has always
    been to allow the WHOIS/RDAP service to be used in "direct contact"
    with the Registrar. I'm sure the Registrar's website was considered
    part of the "Web address" language of the EV Guidelines, so
    discovering Domain Contact information by using the Registrar's web
    site is also considered acceptable.<br>
    <br>
    <blockquote type="cite"
cite="mid:0100019276e15d14-7de2fd6e-5a22-4591-b87d-23319bad8022-000000@email.amazonses.com">
      <div dir="ltr">
        <div>
          <div>
            <div><br>
              If this interpretation is misaligned with others’
              expectations, discussion is welcome.<br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    I'm sure others can join the discussion as well.<br>
    <br>
    <br>
    Thank you,<br>
    Dimitris.<br>
    <br>
    <br>
    <blockquote type="cite"
cite="mid:0100019276e15d14-7de2fd6e-5a22-4591-b87d-23319bad8022-000000@email.amazonses.com">
      <div dir="ltr">
        <div>
          <div>
            <div><br>
              Thanks,<br>
              Ryan<br>
               
              <div>[1] <a
href="https://labs.watchtowr.com/we-spent-20-to-achieve-rce-and-accidentally-became-the-admins-of-mobi/"
                  moz-do-not-send="true" class="moz-txt-link-freetext">https://labs.watchtowr.com/we-spent-20-to-achieve-rce-and-accidentally-became-the-admins-of-mobi/</a><br>
              </div>
            </div>
          </div>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Thu, Oct 10, 2024 at
          6:27 AM Matsuo Yoshihiko <<a
            href="mailto:yoshihiko@jprs.co.jp" moz-do-not-send="true"
            class="moz-txt-link-freetext">yoshihiko@jprs.co.jp</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
          Ryan,<br>
          <br>
          Thank you for your reply.<br>
          <br>
          I feel like I didn't express my points clearly in the previous
          email, so please disregard it.<br>
          <br>
          I apologize for the confusion, but I have reorganized the
          point I would like to confirm as follows:<br>
          <br>
          I am considering updating our system implementation for
          obtaining Domain Contact in light of this revision.<br>
          <br>
          BR defines the source of Domain Contact as follows.<br>
          #1 WHOIS record<br>
          #2 DNS SOA record<br>
          #3 direct contact with the Domain Name Registrar<br>
          <br>
          The questions I would like to ask is...<br>
          <br>
          <br>
          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"?<br>
          I would like to hear your opinion on this.<br>
          <br>
          Thanks,<br>
          <br>
          Yoshihiko Matsuo(JPRS)<br>
          <br>
          <br>
          On Tue, 8 Oct 2024 15:10:38 -0400<br>
          Ryan Dickson <<a href="mailto:ryandickson@google.com"
            moz-do-not-send="true" class="moz-txt-link-freetext">ryandickson@google.com</a>>
          wrote:<br>
          <br>
          > Hi Yoshihiko,<br>
          > <br>
          > The definition for “Domain Contact" (unchanged by the
          proposal) is: “The<br>
          > Domain Name Registrant, technical contact, or
          administrative contact (or<br>
          > the equivalent under a ccTLD) as listed in the WHOIS
          record of the Base<br>
          > Domain Name or in a DNS SOA record, or as obtained
          through direct contact<br>
          > with the Domain Name Registrar.”<br>
          > <br>
          > The definition for “Domain Name Registrar" (also
          unchanged by the proposal)<br>
          > is: “A person or entity that registers Domain Names under
          the auspices of<br>
          > or by agreement with:<br>
          > - the Internet Corporation for Assigned Names and Numbers
          (ICANN),<br>
          > - a national Domain Name authority/registry, or<br>
          > *- a Network Information Center (including their
          affiliates, contractors,<br>
          > delegates, successors, or assignees)*.”<br>
          > <br>
          > For the circumstances described in your message, can you
          please confirm<br>
          > whether the organization operating the CA is considered:<br>
          > - ONLY the ccTLD Domain Name Authority/Registry<br>
          > - ONLY the Domain Name Registrar<br>
          > - BOTH the ccTLD Domain Name Authority/Registry and
          sometimes a Domain Name<br>
          > Registrar<br>
          > - BOTH the ccTLD Domain Name Authority/Registry and
          always the Domain Name<br>
          > Registrar<br>
          > <br>
          > Given the definition of “Domain Contact" and its
          reference in 3.2.2.4.2,<br>
          > 3.2.2.4.12, and 3.2.2.4.15, I believe the distinction
          between roles (Domain<br>
          > Name Authority/Registry and Domain Name Registrar) is
          important.<br>
          > <br>
          > Thanks,<br>
          > <br>
          > Ryan<br>
          > <br>
          > <br>
          > <br>
          > <br>
          > On Tue, Oct 8, 2024 at 7:29?AM Yoshihiko Matsuo via
          Servercert-wg <<br>
          > <a href="mailto:servercert-wg@cabforum.org"
            moz-do-not-send="true" class="moz-txt-link-freetext">servercert-wg@cabforum.org</a>>
          wrote:<br>
          > <br>
          > > All,<br>
          > ><br>
          > > > The only method relying on identifying a
          “Domain Contact" via<br>
          > > registration data left by the ballot is 3.2.2.4.12
          (“Validating Applicant<br>
          > > as a Domain Contact"). This was originally excluded
          from the scope of<br>
          > > sunsets given the expectation that in cases where
          the organization<br>
          > > operating the CA was also the Domain Name Registrar
          (or an Affiliate),<br>
          > > there would be (1) a lower likelihood of unreliable
          Domain Contact<br>
          > > information given a direct relationship with the
          subscriber/subscriber<br>
          > > organization, and (2) a higher potential for
          seamless certificate lifecycle<br>
          > > management because of that relationship. Regardless
          of whether this<br>
          > > expectation is misguided, nothing stops a future
          ballot from contemplating<br>
          > > the further improvement or sunset of 3.2.2.4.12
          (“Validating Applicant as a<br>
          > > Domain Contact").<br>
          > ><br>
          > > We are the CA, and at the same time we are also the
          gTLD Registrar and the<br>
          > > ccTLD Registry.<br>
          > > In this case, I understand that it is acceptable to
          use the Domain<br>
          > > Contacts we hold as The gTLD Registrar for DCV.I
          would like to hear your<br>
          > > opinions on whether the same can be said for the
          Domain Contacts we hold as<br>
          > > the ccTLD Registry.<br>
          > ><br>
          > > Note: We require that ccTLD Domain Contacts be kept
          current as the contact<br>
          > > information for the domain name registrant.<br>
          > ><br>
          > > With this question, I would like to clarify whether
          the BR allows the<br>
          > > following cases.<br>
          > ><br>
          > > 1. The CA that is also the ccTLD Registry retrieves
          Domain Contacts from<br>
          > > its own database and performs validation in
          accordance with 3.2.2.4.2.<br>
          > ><br>
          > > 2. The CA that is also the ccTLD Registry retrieves
          Domain Contacts from<br>
          > > the WHOIS operated by the ccTLD Registry (which is
          also a CA) and performs<br>
          > > validation in accordance with 3.2.2.4.2.<br>
          > ><br>
          > > Thanks,<br>
          > > Yoshihiko Matsuo(JPRS)<br>
          > ><br>
          > ><br>
          > > On 2024/10/08 4:49, Ryan Dickson via Servercert-wg
          wrote:<br>
          > > > Hi Doug,<br>
          > > ><br>
          > > >  > The title, purpose and background of this
          ballot define the removal<br>
          > > of WHOIS and does not discuss any other changes, but
          we’re actually<br>
          > > sunsetting other aspects of domain validation while
          also leaving method<br>
          > > 3.2.2.4.12 that can continue to use WHOIS.<br>
          > > ><br>
          > > > I feel “Objective 2", included in the
          “Background" section, makes the<br>
          > > intent to sunset methods clear (the objective's
          description is: "/Sunset<br>
          > > Methods 3.2.2.4.2 (“Email, Fax, SMS, or Postal Mail
          to Domain Contact”) and<br>
          > > 3.2.2.4.15 (“Phone Contact with Domain Contact")/").<br>
          > > ><br>
          > > > Would changing the title to something like
          “/Strengthen registration<br>
          > > data lookups and Sunset Methods 3.2.2.4.2 and
          3.2.2.4.15/" help?<br>
          > > ><br>
          > > >  > I understand the desire to remove WHOIS
          based on the recent<br>
          > > incident(s), but if we’re going to focus on
          sunsetting WHOIS, we should<br>
          > > 100% sunset it for all uses and we should not
          include the removal of other<br>
          > > methods within this ballot.<br>
          > > ><br>
          > > > All methods relying on identifying Domain
          Contacts via registration data<br>
          > > are strengthened by this ballot, beginning January
          15, 2025. This includes<br>
          > > methods:<br>
          > > > - 3.2.2.4.2 (“Email, Fax, SMS, or Postal Mail
          to Domain Contact")<br>
          > > > - 3.2.2.4.12 (“Validating Applicant as a Domain
          Contact")<br>
          > > > - 3.2.2.4.15 (“Phone Contact with Domain
          Contact")<br>
          > > ><br>
          > > > The ballot goes on to sunset the following
          methods, beginning July 15,<br>
          > > 2025:<br>
          > > > - 3.2.2.4.2 (“Email, Fax, SMS, or Postal Mail
          to Domain Contact")<br>
          > > > - 3.2.2.4.15 (“Phone Contact with Domain
          Contact")<br>
          > > ><br>
          > > > The only method relying on identifying a
          “Domain Contact" via<br>
          > > registration data left by the ballot is 3.2.2.4.12
          (“Validating Applicant<br>
          > > as a Domain Contact"). This was originally excluded
          from the scope of<br>
          > > sunsets given the expectation that in cases where
          the organization<br>
          > > operating the CA was also the Domain Name Registrar
          (or an Affiliate),<br>
          > > there would be (1) a lower likelihood of unreliable
          Domain Contact<br>
          > > information given a direct relationship with the
          subscriber/subscriber<br>
          > > organization, and (2) a higher potential for
          seamless certificate lifecycle<br>
          > > management because of that relationship. Regardless
          of whether this<br>
          > > expectation is misguided, nothing stops a future
          ballot from contemplating<br>
          > > the further improvement or sunset of 3.2.2.4.12
          (“Validating Applicant as a<br>
          > > Domain Contact").<br>
          > > ><br>
          > > > If there’s a case to make for including
          3.2.2.4.12 in the sunsets<br>
          > > covered in the proposal, it’s also welcome.<br>
          > > ><br>
          > > >  > The VWG can be tasked to review methods
          we think are weak and discuss<br>
          > > removing them, for example, imo, all the methods
          that rely on phone calls<br>
          > > (Domain and IP address both), which to me are weaker
          than automated methods<br>
          > > like using they SOA record.<br>
          > > ><br>
          > > > I agree that it’s important for this community
          to routinely re-evaluate<br>
          > > the DCV methods permitted by the TLS BRs and
          consider them against a set of<br>
          > > desirable security and operational properties that
          best enable subscriber<br>
          > > organizations to make securely managing their TLS
          implementations “boring"<br>
          > > (effortless, routine, reliable, and without
          excitement - even when facing<br>
          > > the unexpected).<br>
          > > ><br>
          > > > Periodically over the past three years (when I
          joined this community),<br>
          > > I’ve participated in discussions where members have
          expressed a desire for<br>
          > > improved DCV methods, which has included suggestions
          to remove perceived<br>
          > > weak methods (with those that are phone or
          email-based cited as examples).<br>
          > > While very few of these discussions have led to
          direct action, this ballot<br>
          > > presents a proactive opportunity to address some of
          those concerns, along<br>
          > > with mitigating concerns related to registration
          data lookups identified by<br>
          > > recent events.<br>
          > > ><br>
          > > > I do not believe a holistic evaluation of the
          DCV-methods permitted by<br>
          > > the TLS BRs needs to be a blocking function on this
          ballot, and that both<br>
          > > activities can take place independently of one
          another.<br>
          > > ><br>
          > > > Thanks,<br>
          > > > Ryan<br>
          > > ><br>
          > > ><br>
          > > > On Mon, Oct 7, 2024 at 7:35?AM Doug Beattie
          <<a href="mailto:doug.beattie@globalsign.com"
            moz-do-not-send="true" class="moz-txt-link-freetext">doug.beattie@globalsign.com</a><br>
          > > <mailto:<a
            href="mailto:doug.beattie@globalsign.com"
            moz-do-not-send="true" class="moz-txt-link-freetext">doug.beattie@globalsign.com</a>>>
          wrote:<br>
          > > ><br>
          > > >     Hi Ryan,____<br>
          > > ><br>
          > > >     __ __<br>
          > > ><br>
          > > >     The title, purpose and background of this
          ballot define the removal<br>
          > > of WHOIS and does not discuss any other changes, but
          we’re actually<br>
          > > sunsetting other aspects of domain validation while
          also leaving method<br>
          > > 3.2.2.4.12 that can continue to use WHOIS.  Part of
          this is the<br>
          > > unfortunately extremely broad definition of “Domain
          Contact” and “Domain<br>
          > > Name Registrant” and the wide scope of 3.2.2.4.2,
          which I agree we need to<br>
          > > clarify and fix.   I understand the desire to remove
          WHOIS based on the<br>
          > > recent incident(s), but if we’re going to focus on
          sunsetting WHOIS, we<br>
          > > should 100% sunset if for all uses and we should not
          include the removal of<br>
          > > other methods within this ballot.  The VWG can be
          tasked to review methods<br>
          > > we think are weak and discuss removing them, for
          example, imo, all the<br>
          > > methods that rely on phone calls (Domain and IP
          address both), which to me<br>
          > > are weaker than automated methods like using they
          SOA record.____<br>
          > > ><br>
          > > >     __ __<br>
          > > ><br>
          > > >     Doug____<br>
          > > ><br>
          > > >     __ __<br>
          > > ><br>
          > > >     *From:*Ryan Dickson <<a
            href="mailto:ryandickson@google.com" moz-do-not-send="true"
            class="moz-txt-link-freetext">ryandickson@google.com</a>
          <mailto:<br>
          > > <a href="mailto:ryandickson@google.com"
            moz-do-not-send="true" class="moz-txt-link-freetext">ryandickson@google.com</a>>><br>
          > > >     *Sent:* Friday, October 4, 2024 2:55 PM<br>
          > > >     *To:* Doug Beattie <<a
            href="mailto:doug.beattie@globalsign.com"
            moz-do-not-send="true" class="moz-txt-link-freetext">doug.beattie@globalsign.com</a>
          <mailto:<br>
          > > <a href="mailto:doug.beattie@globalsign.com"
            moz-do-not-send="true" class="moz-txt-link-freetext">doug.beattie@globalsign.com</a>>><br>
          > > >     *Cc:* CA/B Forum Server Certificate WG
          Public Discussion List <<br>
          > > <a href="mailto:servercert-wg@cabforum.org"
            moz-do-not-send="true" class="moz-txt-link-freetext">servercert-wg@cabforum.org</a>
          <mailto:<a href="mailto:servercert-wg@cabforum.org"
            moz-do-not-send="true" class="moz-txt-link-freetext">servercert-wg@cabforum.org</a>>><br>
          > > >     *Subject:* Re: [Servercert-wg] Discussion
          Period Begins - Ballot<br>
          > > SC-080 V2: "Sunset the use of WHOIS to identify
          Domain Contacts and relying<br>
          > > DCV Methods”____<br>
          > > ><br>
          > > >     __ __<br>
          > > ><br>
          > > >     Hi Doug,____<br>
          > > ><br>
          > > >     __ __<br>
          > > ><br>
          > > >     Your interpretation of the latest version
          of the ballot is correct.<br>
          > > ____<br>
          > > ><br>
          > > >     __ __<br>
          > > ><br>
          > > >     As currently presented, Method 3.2.2.4.2
          (“Email, Fax, SMS, or<br>
          > > Postal Mail to Domain Contact”) and Method
          3.2.2.4.15 (“Phone Contact with<br>
          > > Domain Contact”) are sunset, in their entirety,
          effective July 15, 2025.<br>
          > > ____<br>
          > > ><br>
          > > >     __ __<br>
          > > ><br>
          > > >     Specific to domain contact email addresses
          from SOA records, can you<br>
          > > share your perspective for adding this specific
          option given the existence<br>
          > > of (1) other email-based alternatives (e.g.,
          3.2.2.4.4, 3.2.2.4.13 and<br>
          > > 3.2.2.4.14) and (2) other far more heavily relied
          upon DCV methods that<br>
          > > present an opportunity for improved automation and
          scalability (and also<br>
          > > benefit from MPIC)?____<br>
          > > ><br>
          > > >     __ __<br>
          > > ><br>
          > > >     For example, detailing responses below
          would be helpful for<br>
          > > understanding:____<br>
          > > ><br>
          > > >       * existing reliance on this specific
          approach in comparison to the<br>
          > > other DCV methods offered?____<br>
          > > >       * how this reliance has trended over time
          (e.g., last 1 / 3 / 5<br>
          > > years)?____<br>
          > > >       * how the sunset would affect
          subscribers?____<br>
          > > >       * a general description of the level of
          effort for affected<br>
          > > subscribers to transition to another method?____<br>
          > > >       * what barriers exist that prevent
          subscribers from transitioning<br>
          > > to other methods?____<br>
          > > ><br>
          > > >     __ __<br>
          > > ><br>
          > > >     I think it’s reasonable for the community
          to approach RNAME lookups<br>
          > > with the same degree of concern for accuracy and
          reliability as<br>
          > > registration data due to the potential for:____<br>
          > > ><br>
          > > >       * neglected configurations (e.g., in
          2020, [1] indicated only<br>
          > > 39.74% of a set of “top” 1M domains contained
          “reachable” SOA contacts, and<br>
          > > only approximately 20% of the sampled .com and .net
          domains did).____<br>
          > > >       * potential CA reliance on third-party
          tools with unknown<br>
          > > operational characteristics for performing SOA
          lookups (the same concern as<br>
          > > WHOIS lookups using HTTPS websites).____<br>
          > > >       * a lack of oversight and enforcement for
          ensuring SOA record<br>
          > > updates (e.g, accuracy/correctness and
          timeliness).____<br>
          > > >       * use of automated DNS management
          solutions that can result in an<br>
          > > unintended and/or unknown delegation of authority to
          approve TLS<br>
          > > certificates, while also representing a single point
          of failure (or<br>
          > > attack).____<br>
          > > ><br>
          > > >     __ __<br>
          > > ><br>
          > > >     Thanks,____<br>
          > > ><br>
          > > >     Ryan____<br>
          > > ><br>
          > > >     __ __<br>
          > > ><br>
          > > >     [1] <a
            href="https://mkorczynski.com/WTMC2020.pdf" rel="noreferrer"
            moz-do-not-send="true" class="moz-txt-link-freetext">https://mkorczynski.com/WTMC2020.pdf</a>
          <<br>
          > > <a href="https://mkorczynski.com/WTMC2020.pdf"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://mkorczynski.com/WTMC2020.pdf</a>>____<br>
          > > ><br>
          > > >     __ __<br>
          > > ><br>
          > > >     __ __<br>
          > > ><br>
          > > >     On Thu, Oct 3, 2024 at 9:57?AM Doug Beattie
          <<br>
          > > <a href="mailto:doug.beattie@globalsign.com"
            moz-do-not-send="true" class="moz-txt-link-freetext">doug.beattie@globalsign.com</a>
          <mailto:<a href="mailto:doug.beattie@globalsign.com"
            moz-do-not-send="true" class="moz-txt-link-freetext">doug.beattie@globalsign.com</a>>><br>
          > > wrote:____<br>
          > > ><br>
          > > >         Hey Ryan,____<br>
          > > ><br>
          > > >         ____<br>
          > > ><br>
          > > >         The way I read the ballot is that using
          domain approver email<br>
          > > addresses from SOA records is being removed since
          that’s part of<br>
          > > 3.2.2.4.2.   Should we add a new method specifically
          for that, or was the<br>
          > > intent to remove that as a valid location to obtain
          domain approver email<br>
          > > addresses?____<br>
          > > ><br>
          > > ><br>
          > > >         Doug____<br>
          > > ><br>
          > > >         ____<br>
          > > ><br>
          > > >         *From:*Servercert-wg <<a
            href="mailto:servercert-wg-bounces@cabforum.org"
            moz-do-not-send="true" class="moz-txt-link-freetext">servercert-wg-bounces@cabforum.org</a><br>
          > > <mailto:<a
            href="mailto:servercert-wg-bounces@cabforum.org"
            moz-do-not-send="true" class="moz-txt-link-freetext">servercert-wg-bounces@cabforum.org</a>>>
          *On Behalf Of *Ryan Dickson<br>
          > > via Servercert-wg<br>
          > > >         *Sent:* Tuesday, October 1, 2024 12:59
          PM<br>
          > > >         *To:* ServerCert CA/BF <<a
            href="mailto:servercert-wg@cabforum.org"
            moz-do-not-send="true" class="moz-txt-link-freetext">servercert-wg@cabforum.org</a>
          <mailto:<br>
          > > <a href="mailto:servercert-wg@cabforum.org"
            moz-do-not-send="true" class="moz-txt-link-freetext">servercert-wg@cabforum.org</a>>><br>
          > > >         *Subject:* [Servercert-wg] Discussion
          Period Begins - Ballot<br>
          > > SC-080 V2: "Sunset the use of WHOIS to identify
          Domain Contacts and relying<br>
          > > DCV Methods”____<br>
          > > ><br>
          > > >         ____<br>
          > > ><br>
          > > >         *_Purpose of Ballot SC-080 V2:<br>
          > > >         _*This ballot proposes updates to the
          Baseline Requirements for<br>
          > > the Issuance and Management of Publicly-Trusted TLS
          Server Certificates<br>
          > > (TLS BRs) to address concerns regarding the use of
          WHOIS and HTTPS websites<br>
          > > for identifying Domain Contacts.<br>
          > > ><br>
          > > >         *_Background:<br>
          > > >         _*This ballot intends to accomplish two
          objectives, originally<br>
          > > described in [1].____<br>
          > > ><br>
          > > >         Objective 1: Enhance WHOIS/RDAP
          validation of gTLDs with<br>
          > > comparable security properties to DNS-based
          validation and sunset<br>
          > > WHOIS/RDAP for ccTLDs.<br>
          > > ><br>
          > > >         _Justification:_____<br>
          > > ><br>
          > > >           * A recent disclosure [2]
          demonstrated how threat actors could<br>
          > > exploit deficiencies in the WHOIS protocol and WHOIS
          tools served via HTTPS<br>
          > > websites to obtain fraudulent TLS certificates.____<br>
          > > >           * Discussions within the Mozilla Dev
          Security Policy (MDSP)<br>
          > > community [3] further expressed corresponding risks
          related to WHOIS, while<br>
          > > also noting that ccTLDs may not maintain accurate or
          up-to-date WHOIS<br>
          > > server records. Several examples of inoperative
          WHOIS servers for ccTLDs<br>
          > > were identified.____<br>
          > > >           * Discussion in [4] further called
          into question the<br>
          > > reliability of ccTLD WHOIS servers given, per IANA,
          there is no global<br>
          > > policy requirement for ccTLD managers to operate a
          WHOIS server, and if<br>
          > > they do, what kind of information is provided.____<br>
          > > >           * Solutions to strengthen existing
          WHOIS lookup methods were<br>
          > > proposed in [5] and are considered in this
          ballot.____<br>
          > > ><br>
          > > >         ____<br>
          > > ><br>
          > > >         Objective 2: Sunset Methods 3.2.2.4.2
          (“Email, Fax, SMS, or<br>
          > > Postal Mail to Domain Contact”) and 3.2.2.4.15
          (“Phone Contact with Domain<br>
          > > Contact”).<br>
          > > ><br>
          > > >         _Justification:_____<br>
          > > ><br>
          > > >           * While solutions to strengthen
          WHOIS-relying DCV methods are<br>
          > > considered in this ballot (see above), there is
          limited public evidence of<br>
          > > significant reliance on these methods, including in
          response to [3] and<br>
          > > [6].____<br>
          > > >           * Instead, discussion has identified
          at least one CA Owner has<br>
          > > already sunset reliance on WHOIS [7], and another
          that has changed its<br>
          > > approach [8] for relying on WHOIS since disclosure
          of [2].____<br>
          > > >           * More modern and heavily relied-upon
          DCV methods offer<br>
          > > advantages over the existing WHOIS-based methods,
          including greater<br>
          > > opportunity for seamless certificate lifecycle
          management automation (e.g.,<br>
          > > [9] and [10]), while also benefiting from recently
          improved security<br>
          > > practices [11]. These methods can also more
          effectively align subscriber<br>
          > > capabilities with agility and resilience
          expectations necessary to respond<br>
          > > to the revocation timelines described in the TLS BRs
          [12].____<br>
          > > >           * Beyond the above, previous
          discussions within the CA/Browser<br>
          > > Forum have raised concerns about the perceived value
          (e.g., [13]) and<br>
          > > security (e.g., [14]) of the DCV methods relying on
          WHOIS, further<br>
          > > supporting the rationale for their gradual
          sunset.____<br>
          > > ><br>
          > > ><br>
          > > >         *_Benefits of adoption:_*____<br>
          > > ><br>
          > > >           * Enhanced Security: Eliminates
          reliance on outdated and<br>
          > > vulnerable DCV methods that cannot consistently
          provide the security<br>
          > > required by the TLS BRs, or benefit from recent DCV
          security enhancements<br>
          > > (i.e., Multi-Perspective Issuance Corroboration
          [11]). ____<br>
          > > >           * Increased Agility: Encourages site
          owners to transition to<br>
          > > modern DCV methods, creating opportunities for
          faster, more efficient, and<br>
          > > less error-prone certificate lifecycle management.
          ____<br>
          > > >           * Opportunity for Innovation:
          Promotes the development of new<br>
          > > and/or improved DCV methods, fostering innovation
          that may enhance the<br>
          > > overall security and agility of the ecosystem.____<br>
          > > ><br>
          > > ><br>
          > > >         *_Proposed Key Dates:_*____<br>
          > > ><br>
          > > >         The effective dates considered in this
          update are intended to 1)<br>
          > > address the immediate concerns identified by [2],
          and 2) offer near-term<br>
          > > and longer-term transition periods for subscribers
          and CA Owners relying on<br>
          > > existing implementations of these methods.____<br>
          > > ><br>
          > > >           * January 15, 2025: (1) Prohibit the
          use of RFC 3912 (WHOIS)<br>
          > > and HTTPS websites to identify Domain Contact
          information. (2) Prohibit the<br>
          > > reuse of DCV relying on information obtained using
          these technologies. (3)<br>
          > > Prohibit WHOIS-based DCV methods for Subscriber
          Certificates containing<br>
          > > ccTLDs. (4) CAs MUST NOT rely on cached WHOIS/RDAP
          data more than 48 hours<br>
          > > old. ____<br>
          > > >           * July 15, 2025: (1) Sunset DCV
          Methods 3.2.2.4.2 ("Email,<br>
          > > Fax, SMS, or Postal Mail to Domain Contact") and
          3.2.2.4.15 ("Phone Contact<br>
          > > with Domain Contact"). (2) Prior validations using
          these methods and<br>
          > > validation data gathered therein MUST NOT be used to
          issue new Subscriber<br>
          > > Certificates.____<br>
          > > ><br>
          > > ><br>
          > > >         *_Proposal Revision History:_*____<br>
          > > ><br>
          > > >           * Pre-Ballot Version #1 [4]____<br>
          > > >           * Ballot Version #1 [7]____<br>
          > > >           * Version #2 Pre-Release [17] and
          discussion [18]____<br>
          > > >           * Version #2 (this version) [19]____<br>
          > > ><br>
          > > ><br>
          > > >         The following motion has been proposed
          by Ryan Dickson and Chris<br>
          > > Clements of Google (Chrome Root Program) and
          endorsed by Arvid Vermote<br>
          > > (GlobalSign) and Pedro Fuentes (OISTE).____<br>
          > > ><br>
          > > ><br>
          > > >         ? Motion Begins ?<br>
          > > ><br>
          > > >         This ballot modifies the “Baseline
          Requirements for the Issuance<br>
          > > and Management of Publicly-Trusted TLS Server
          Certificates” (“Baseline<br>
          > > Requirements”), based on Version 2.0.7.<br>
          > > ><br>
          > > >         MODIFY the Baseline Requirements as
          specified in the following<br>
          > > Redline:<br>
          > > ><br>
          > > ><br>
          > > <a
href="https://github.com/cabforum/servercert/compare/ba28d04894d69c8fac62850b9d0de5061658c7c5..7f2b54cfa5b89f41458a88211566ce508c464804"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://github.com/cabforum/servercert/compare/ba28d04894d69c8fac62850b9d0de5061658c7c5..7f2b54cfa5b89f41458a88211566ce508c464804</a><br>
          > > <<br>
          > > <a
href="https://github.com/cabforum/servercert/compare/ba28d04894d69c8fac62850b9d0de5061658c7c5..7f2b54cfa5b89f41458a88211566ce508c464804"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://github.com/cabforum/servercert/compare/ba28d04894d69c8fac62850b9d0de5061658c7c5..7f2b54cfa5b89f41458a88211566ce508c464804</a><br>
          > > ><br>
          > > ><br>
          > > >         ? Motion Ends ?<br>
          > > ><br>
          > > >         This ballot proposes a Final
          Maintenance Guideline. The<br>
          > > procedure for approval of this ballot is as follows:<br>
          > > ><br>
          > > >         _Discussion (no less than 7 days)_____<br>
          > > ><br>
          > > >           * Start: 2024-10-01 17:00:00 UTC____<br>
          > > >           * End no earlier than: 2024-10-08
          17:00:00 UTC____<br>
          > > ><br>
          > > ><br>
          > > >         _Vote for approval (7 days)_____<br>
          > > ><br>
          > > >           * Start: TBD____<br>
          > > >           * End: TBD____<br>
          > > ><br>
          > > >         ____<br>
          > > ><br>
          > > >         Comments are welcome either on-list or
          with suggested edits via<br>
          > > GitHub (preferred) at [19].____<br>
          > > ><br>
          > > >         ____<br>
          > > ><br>
          > > >         Thanks,____<br>
          > > ><br>
          > > >         Ryan____<br>
          > > ><br>
          > > >         ____<br>
          > > ><br>
          > > >         ____<br>
          > > ><br>
          > > >         *References:*____<br>
          > > ><br>
          > > >         [1]<br>
          > > <a
href="https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004900.html"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004900.html</a><br>
          > > <<br>
          > > <a
href="https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004900.html"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004900.html</a><br>
          > > ><br>
          > > >         [2]<br>
          > > <a
href="https://labs.watchtowr.com/we-spent-20-to-achieve-rce-and-accidentally-became-the-admins-of-mobi/"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://labs.watchtowr.com/we-spent-20-to-achieve-rce-and-accidentally-became-the-admins-of-mobi/</a><br>
          > > <<br>
          > > <a
href="https://labs.watchtowr.com/we-spent-20-to-achieve-rce-and-accidentally-became-the-admins-of-mobi/"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://labs.watchtowr.com/we-spent-20-to-achieve-rce-and-accidentally-became-the-admins-of-mobi/</a><br>
          > > ><br>
          > > >         [3]<br>
          > > <a
href="https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/FuOi_uhQB6U/m/hKJOz3XzAAAJ"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/FuOi_uhQB6U/m/hKJOz3XzAAAJ</a><br>
          > > <<br>
          > > <a
href="https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/FuOi_uhQB6U/m/hKJOz3XzAAAJ"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/FuOi_uhQB6U/m/hKJOz3XzAAAJ</a><br>
          > > ><br>
          > > >         [4]<br>
          > > <a
href="https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/mAl9XjieSkA/m/oDNWxtPwAQAJ"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/mAl9XjieSkA/m/oDNWxtPwAQAJ</a><br>
          > > <<br>
          > > <a
href="https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/mAl9XjieSkA/m/oDNWxtPwAQAJ"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/mAl9XjieSkA/m/oDNWxtPwAQAJ</a><br>
          > > ><br>
          > > >         [5]<br>
          > > <a
href="https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004839.html"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004839.html</a><br>
          > > <<br>
          > > <a
href="https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004839.html"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004839.html</a><br>
          > > ><br>
          > > >         [6]<br>
          > > <a
href="https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004844.html"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004844.html</a><br>
          > > <<br>
          > > <a
href="https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004844.html"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004844.html</a><br>
          > > ><br>
          > > >         [7]<br>
          > > <a
href="https://aws.amazon.com/blogs/security/aws-certificate-manager-will-discontinue-whois-lookup-for-email-validated-certificates/"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://aws.amazon.com/blogs/security/aws-certificate-manager-will-discontinue-whois-lookup-for-email-validated-certificates/</a><br>
          > > <<br>
          > > <a
href="https://aws.amazon.com/blogs/security/aws-certificate-manager-will-discontinue-whois-lookup-for-email-validated-certificates/"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://aws.amazon.com/blogs/security/aws-certificate-manager-will-discontinue-whois-lookup-for-email-validated-certificates/</a><br>
          > > ><br>
          > > >         [8] <a
            href="https://bugzilla.mozilla.org/show_bug.cgi?id=1917896"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://bugzilla.mozilla.org/show_bug.cgi?id=1917896</a>
          <<br>
          > > <a
            href="https://bugzilla.mozilla.org/show_bug.cgi?id=1917896"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://bugzilla.mozilla.org/show_bug.cgi?id=1917896</a>><br>
          > > >         [9]<br>
          > > <a
href="https://cabforum.org/working-groups/server/baseline-requirements/requirements/#32247-dns-change"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://cabforum.org/working-groups/server/baseline-requirements/requirements/#32247-dns-change</a><br>
          > > <<br>
          > > <a
href="https://cabforum.org/working-groups/server/baseline-requirements/requirements/#32247-dns-change"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://cabforum.org/working-groups/server/baseline-requirements/requirements/#32247-dns-change</a><br>
          > > ><br>
          > > >         [10]<br>
          > > <a
href="https://cabforum.org/working-groups/server/baseline-requirements/requirements/#322419-agreed-upon-change-to-website---acme"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://cabforum.org/working-groups/server/baseline-requirements/requirements/#322419-agreed-upon-change-to-website---acme</a><br>
          > > <<br>
          > > <a
href="https://cabforum.org/working-groups/server/baseline-requirements/requirements/#322419-agreed-upon-change-to-website---acme"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://cabforum.org/working-groups/server/baseline-requirements/requirements/#322419-agreed-upon-change-to-website---acme</a><br>
          > > ><br>
          > > >         [11]<br>
          > > <a
href="https://cabforum.org/working-groups/server/baseline-requirements/requirements/#3229-multi-perspective-issuance-corroboration"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://cabforum.org/working-groups/server/baseline-requirements/requirements/#3229-multi-perspective-issuance-corroboration</a><br>
          > > <<br>
          > > <a
href="https://cabforum.org/working-groups/server/baseline-requirements/requirements/#3229-multi-perspective-issuance-corroboration"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://cabforum.org/working-groups/server/baseline-requirements/requirements/#3229-multi-perspective-issuance-corroboration</a><br>
          > > ><br>
          > > >         [12]<br>
          > > <a
href="https://cabforum.org/working-groups/server/baseline-requirements/requirements/#491-circumstances-for-revocation"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://cabforum.org/working-groups/server/baseline-requirements/requirements/#491-circumstances-for-revocation</a><br>
          > > <<br>
          > > <a
href="https://cabforum.org/working-groups/server/baseline-requirements/requirements/#491-circumstances-for-revocation"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://cabforum.org/working-groups/server/baseline-requirements/requirements/#491-circumstances-for-revocation</a><br>
          > > ><br>
          > > >         [13]<br>
          > > <a
href="https://archive.cabforum.org/pipermail/servercert-wg/2018-August/000113.html"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://archive.cabforum.org/pipermail/servercert-wg/2018-August/000113.html</a><br>
          > > <<br>
          > > <a
href="https://archive.cabforum.org/pipermail/servercert-wg/2018-August/000113.html"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://archive.cabforum.org/pipermail/servercert-wg/2018-August/000113.html</a><br>
          > > ><br>
          > > >         [14]<br>
          > > <a
href="https://lists.cabforum.org/pipermail/validation/2024-July/001995.html"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://lists.cabforum.org/pipermail/validation/2024-July/001995.html</a>
          <<br>
          > > <a
href="https://lists.cabforum.org/pipermail/validation/2024-July/001995.html"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://lists.cabforum.org/pipermail/validation/2024-July/001995.html</a>><br>
          > > >         [15]<br>
          > > <a
href="https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004825.html"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004825.html</a><br>
          > > <<br>
          > > <a
href="https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004825.html"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004825.html</a><br>
          > > ><br>
          > > >         [16]<br>
          > > <a
href="https://github.com/ryancdickson/staging/compare/356799f0dcfe11deb0a375a11233403236ab72c9..7a2ea7b33611bebf006a99a9a82729f183143eac"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://github.com/ryancdickson/staging/compare/356799f0dcfe11deb0a375a11233403236ab72c9..7a2ea7b33611bebf006a99a9a82729f183143eac</a><br>
          > > <<br>
          > > <a
href="https://github.com/ryancdickson/staging/compare/356799f0dcfe11deb0a375a11233403236ab72c9..7a2ea7b33611bebf006a99a9a82729f183143eac"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://github.com/ryancdickson/staging/compare/356799f0dcfe11deb0a375a11233403236ab72c9..7a2ea7b33611bebf006a99a9a82729f183143eac</a><br>
          > > ><br>
          > > >         [17]<br>
          > > <a
href="https://github.com/ryancdickson/staging/compare/ba28d04894d69c8fac62850b9d0de5061658c7c5..7a2ea7b33611bebf006a99a9a82729f183143eac"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://github.com/ryancdickson/staging/compare/ba28d04894d69c8fac62850b9d0de5061658c7c5..7a2ea7b33611bebf006a99a9a82729f183143eac</a><br>
          > > <<br>
          > > <a
href="https://github.com/ryancdickson/staging/compare/ba28d04894d69c8fac62850b9d0de5061658c7c5..7a2ea7b33611bebf006a99a9a82729f183143eac"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://github.com/ryancdickson/staging/compare/ba28d04894d69c8fac62850b9d0de5061658c7c5..7a2ea7b33611bebf006a99a9a82729f183143eac</a><br>
          > > ><br>
          > > >         [18] <a
            href="https://github.com/ryancdickson/staging/pull/9"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://github.com/ryancdickson/staging/pull/9</a>
          <<br>
          > > <a
            href="https://github.com/ryancdickson/staging/pull/9"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://github.com/ryancdickson/staging/pull/9</a>><br>
          > > >         [19] <a
            href="https://github.com/cabforum/servercert/pull/551"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://github.com/cabforum/servercert/pull/551</a>
          <<br>
          > > <a
            href="https://github.com/cabforum/servercert/pull/551"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://github.com/cabforum/servercert/pull/551</a>>____<br>
          > > ><br>
          > > >         ____<br>
          > > ><br>
          > > ><br>
          > > > _______________________________________________<br>
          > > > Servercert-wg mailing list<br>
          > > > <a href="mailto:Servercert-wg@cabforum.org"
            moz-do-not-send="true" class="moz-txt-link-freetext">Servercert-wg@cabforum.org</a><br>
          > > > <a
href="https://lists.cabforum.org/mailman/listinfo/servercert-wg"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><br>
          > ><br>
          > > _______________________________________________<br>
          > > Servercert-wg mailing list<br>
          > > <a href="mailto:Servercert-wg@cabforum.org"
            moz-do-not-send="true" class="moz-txt-link-freetext">Servercert-wg@cabforum.org</a><br>
          > > <a
href="https://lists.cabforum.org/mailman/listinfo/servercert-wg"
            rel="noreferrer" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><br>
          > ><br>
          <br>
        </blockquote>
      </div>
      <br>
      <fieldset class="moz-mime-attachment-header"></fieldset>
      <pre wrap="" class="moz-quote-pre">_______________________________________________
Servercert-wg mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Servercert-wg@cabforum.org">Servercert-wg@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://lists.cabforum.org/mailman/listinfo/servercert-wg">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>