<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <br>
    Domain Name Registrars may use the Domain Contact information in
    their records, and published using the WHOIS/RDAP/WWW protocols, to
    contact a Domain Owner for password resets or modifications to the
    Domain Name Servers. <br>
    <br>
    If Domain Name Registrars use that information to make changes to
    the Name Servers associated with a Domain Name, which is way more
    critical for the security of that actual Domain Name, why shouldn't
    the WebPKI rely on it for demonstration of ownership of the Domain
    Name?<br>
    <br>
    Over the years, most Registrars have implemented additional controls
    like stronger authentication using 2FA and others, but the
    fundamental issue exists. What happens when a Domain Owner forgets
    their password? Each Registrar may have a different approach to
    handle this particular situation but I assure you most of them use
    the Domain Contact information to perform this reset.<br>
    <br>
    BTW, the same principles guide the IP address blocks
    assignment/management, and also still rely heavily on WHOIS.<br>
    <br>
    Dimitris.<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 18/9/2024 3:43 μ.μ., Mike Shaver via
      Servercert-wg wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:010001920528bb86-dfa58d79-2a02-4cd5-950a-6ba1afbd9e29-000000@email.amazonses.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div>Here's maybe a helpful way to frame the discussion: if the
          BRs didn't permit WHOIS/domain-registry-website DCV right now,
          and someone proposed adding it, what would we need to see in
          the associated ballot to be comfortable that it didn't
          represent a weakening of the sans-WHOIS DCV model? Would we
          permit it only for gTLD based on IANA requiring that there at
          least be a server operated? Would we permit unencrypted
          RFC-3912 wire transactions at all, in any case?</div>
        <div><br>
        </div>
        <div>The migration timeline will be a source of tension between
          "improve the security of the web" and "impose work on people
          who have been relying on the ease of WHOIS DCV", but it's not
          clear to me that this group even has consensus on what a
          desirable communicate-with-domain-registrant DCV would look
          like after a successful migration period.</div>
        <div><br>
        </div>
        <div>Mike</div>
        <div><br>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Wed, Sep 18, 2024 at
          8:38 AM Mike Shaver via Servercert-wg <<a
            href="mailto:servercert-wg@cabforum.org"
            moz-do-not-send="true" class="moz-txt-link-freetext">servercert-wg@cabforum.org</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
          <div dir="ltr">
            <div class="gmail_quote">
              <div class="gmail_attr">Hi Andrew,</div>
              <div class="gmail_attr"><br>
              </div>
              <div class="gmail_attr">Thanks for a really thoughtful
                analysis here!<br>
              </div>
              <div dir="ltr" class="gmail_attr"><br>
              </div>
              <div dir="ltr" class="gmail_attr">On Tue, Sep 17, 2024 at
                11:13 AM Andrew Ayer via Servercert-wg <<a
                  href="mailto:servercert-wg@cabforum.org"
                  moz-do-not-send="true" class="moz-txt-link-freetext">servercert-wg@cabforum.org</a>>
                wrote:<br>
              </div>
              <blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Delegating
                DNS records using CNAME (e.g. with [3]) is<br>
                better, but not as easy because it requires the
                subscriber to operate<br>
                public-facing infrastructure.<br>
              </blockquote>
              <div><br>
              </div>
              <div>I had understood that SCWG's BRs and the issuance of
                web PKI certs was indeed intended to only be for
                internet-accessible infrastructure anyway. Is it really
                a problem that SCWG needs to solve if people are trying
                to piggyback off the web PKI for their internal systems,
                rather than manage their own PKI model? This could be
                yet another nudge for people to stop doing that, which
                IMO would be a positive side-effect and not a
                counter-argument.<br>
              </div>
              <div><br>
              </div>
              <div>Mike</div>
              <div><br>
              </div>
            </div>
          </div>
          _______________________________________________<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>
        </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>