<div dir="ltr">I don't think we could support such a ballot, without having an explanation of why you believe method #1 is valuable and equivalent - even if tightened up - to the other methods of validation.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 22, 2017 at 2:22 AM, Adriano Santoni via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <p><font face="Calibri">Ryan,</font></p>
    <p><font face="Calibri">I think I see what you mean, but I also
        believe that the problem is not in method #1 per se, but rather
        in the "degrees of freedom" with which it may be implemented, as
        allowed by the BRs. <br>
      </font></p>
    <p><font face="Calibri">In particular, I believe that establishing
        the authenticity of the request directly with the Applicant's
        Representative is a bad practice, regardless of the DCV method
        employed.</font><font face="Calibri"><br>
      </font></p>
    <p><font face="Calibri">I'd suggest to try and improve (tighten) the
        BRs, instead of killing DCV methods that make sense, per se, but
        should be implemented in a more robust way.</font><br>
    </p>
    <font face="Calibri">For instance, I'd favour zapping the words "</font><font face="Calibri"><font face="Calibri">directly with the Applicant's
        Representative or</font>" from the second paragraph of BR
      §3.2.5. Would not that be an improvement?<br>
    </font>
    <p>Adriano</p><div><div class="h5">
    <p><br>
    </p>
    <br>
    <div class="m_-7663650188854025198moz-cite-prefix">Il 21/12/2017 17:57, Ryan Sleevi ha
      scritto:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">Adriano,
        <div><br>
        </div>
        <div>Do you have an example of how you believe 3.2.2.4.1 can be
          used correctly? </div>
        <div><br>
        </div>
        <div>Specifically, it does not describe the process for
          validating that the Applicant is the Domain Contact with the
          Registrar - this isn't equivalent to using WHOIS.</div>
        <div><br>
        </div>
        <div>Here's just one scenario:</div>
        <div>- I ("Ryan Sleevi") apply to Foo CA for <a href="http://example.com" target="_blank">example.com</a>,
          which is owned by "Andriano Santoni's Lightly Validated
          Certificates" - you.</div>
        <div>- Foo CA decides to employ 3.2.2.4.1, using 3.2.2.4(1)</div>
        <div>  - Note, as worded, all of 3.2.2.1 can be read as
          'optional' for DV certs, thus automatically met, but lets
          pretend its OV</div>
        <div>  - They verify "Andriano Santoni's Lightly Validated
          Certificates" is a real company with a real existence using a
          QGIS. That's all that's needed - there's no binding to the
          Applicant, just an existence proof of the data.</div>
        <div>  - Alternatively, I send a photoshopped letter claiming
          your company exists, valid under 3.2.2.1(4)</div>
        <div>  - Alternatively, the CA declares that "Google Maps" is a
          Reliable Data Source (it isn't, but again, underspecified),
          and verifies that there's an entry under 3.2.2.1(2) - despite
          the fact I just added the entry</div>
        <div>- They then need to verify whether or not I'm authorized to
          speak for your company.</div>
        <div>  - The information used in 3.2.2.1 doesn't have to be used
          ("the CA MAY use ..."), but remember, I may have made it up
          under 3.2.2.1</div>
        <div>  - The CA can directly call me, Ryan Sleevi, asking if I'm
          authorized ("the CA MAY establish the authenticity of the
          certificate request directly with the Applicant
          Representative")</div>
        <div>  - The requirement to use an RMOC simply means that Foo CA
          could decide to call up Jeremy, since Jeremy knows me, and say
          "Hey, does Ryan work for Adriano Santoni" - that's all that's
          required.</div>
        <div>- Finally, the CA contacts the registrar, and says "Hey,
          does Adriano Santoni's Lightly Validated Certificates own <a href="http://example.com" target="_blank">example.com</a>"
          - and the registrar says sure</div>
        <div>  - Note: There's no consensus whether we're talking about
          the same organization - perhaps I created a version
          incorporated in the US, but you're incorporated in Italy</div>
        <div><br>
        </div>
        <div>These are just a few of the legal-but-bad things you can
          do. I'm sure we'll see the normal rush from some CAs saying
          "Yes, but we'd never do that" - while ignoring the fact that
          some could, as it's valid under the language, and we
          consistently see "That which is valid (or subject to
          misinterpretation) is possible to use"</div>
        <div><br>
        </div>
        <div><br>
        </div>
        <div>Could you provide an example of how you believe 3.2.2.4.1
          "should" work and offer the same level of assurance as the
          other methods, without normatively prescribing the data
          sources used? From conversations with both current and past
          employees of CAs, I am adamantly convinced that there is not a
          consistent standard of reliableness being applies. Google Maps
          being used as a Reliable Data Source is not a hypothetical,
          despite it allowing community edits.</div>
        <div><br>
        </div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Thu, Dec 21, 2017 at 4:00 AM,
          Adriano Santoni via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div text="#000000" bgcolor="#FFFFFF">
              <p><font face="Calibri">Jeremy, I am not sure I fully
                  understand the problems you describe. <br>
                </font></p>
              <p><font face="Calibri">Would it be possible for you to
                  provide some concrete example related to method #1,
                  with some details, without of course mentioning
                  specific certificates and/or organizations?</font><br>
              </p>
              <div>
                <div class="m_-7663650188854025198h5"> <br>
                  <br>
                  <div class="m_-7663650188854025198m_710245841136644683moz-cite-prefix">Il
                    19/12/2017 22:30, Jeremy Rowley via Public ha
                    scritto:<br>
                  </div>
                </div>
              </div>
              <blockquote type="cite">
                <div>
                  <div class="m_-7663650188854025198h5">
                    <div class="m_-7663650188854025198m_710245841136644683WordSection1">
                      <p class="MsoNormal">Hi all, </p>
                      <p class="MsoNormal"> </p>
                      <p class="MsoNormal">When reviewing the Symantec
                        validation methods and the customers using each
                        method, I found an alarming number of customers
                        verified under 3.2.2.4.1 (Verification of a
                        Domain Contact) or 3.2.2.4.5 (Domain
                        Authorization Document) where the domain is not
                        technically associated with the entity. These
                        two methods need improvement or removal as the
                        way they are currently lacks sufficient controls
                        to associate the domain verification with the
                        actual certificate approver. I’ve had too many
                        calls with customers explaining re-verification
                        where the domain holder didn’t understand that a
                        cert issued for the domain. Although the
                        organization verification was successfully
                        complete, the only tie between the domain and
                        organization is a call to the organization that
                        happened within the last years to approve the
                        account for issuance. I wanted to bring it up
                        here because I’ve always thought these methods
                        were less desirable than others. I think other
                        large CAs use this method quite a bit so I’m
                        hoping to get clarity on why these methods are
                        permitted when the domain verification seems
                        more “hand-wavy” than other methods. </p>
                      <p class="MsoNormal"> </p>
                      <p class="MsoNormal">Method 3.2.2.4.1 permits a CA
                        to issue a certificate if the certificate is an
                        EV or OV cert. With EV certificates, there is a
                        call to a verified telephone number that
                        confirms the requester’s affiliation with the
                        organization. I can see this method working for
                        EV.  For OV certificates, there is a reliable
                        method of communication that confirms the
                        account holder as affiliated with the
                        organization.  Unlike EV, for OV certs there is
                        no tie between the requester and their authority
                        to request a certificate. Once the organization
                        is verified, the BRs permit auto-issuance for
                        any domain that reflects an affiliation with the
                        verified entity for up to 825 days. There’s no
                        notice to the domain contact that the
                        certificate was requested or approved.  Perhaps
                        this is sufficient as the account has been
                        affiliated with the organization through the
                        reliable method of communication and because CT
                        will soon become mandatory. </p>
                      <p class="MsoNormal"> </p>
                      <p class="MsoNormal">Method 3.2.2.4.5 permits a CA
                        to issue a certificate using a legal opinion
                        letter for the domain. Unfortunately the BRs
                        lack clear requirements about how the legal
                        opinion letter is verified. If I want a cert for
                        Google.com and the CA is following the bare
                        minimum, all I need to do is copy their
                        letterhead and sign the document. Magically, a
                        certificate can issue.  This method lacks a lot
                        of controls of method 1 because there is no
                        requirement around verification of the company.
                        I can list as many domains in the letter as I’d
                        like provided the entity listed in the
                        corresponding WHOIS’s letterhead is used.</p>
                      <p class="MsoNormal"> </p>
                      <p class="MsoNormal">I’m looking to remove/fix
                        both of these methods as both these methods lack
                        the necessary controls to ensure that the
                        verification ties to the domain holder. These
                        methods probably should have been removed back
                        when we passed 169/182. Would anyone being
                        willing to endorse a ballot killing these or
                        making some necessary improvements?  </p>
                      <p class="MsoNormal"> </p>
                      <p class="MsoNormal">Jeremy</p>
                      <p class="MsoNormal"> </p>
                    </div>
                    <br>
                    <fieldset class="m_-7663650188854025198m_710245841136644683mimeAttachmentHeader"></fieldset>
                    <br>
                  </div>
                </div>
                <pre>______________________________<wbr>_________________
Public mailing list
<a class="m_-7663650188854025198m_710245841136644683moz-txt-link-abbreviated" href="mailto:Public@cabforum.org" target="_blank">Public@cabforum.org</a>
<a class="m_-7663650188854025198m_710245841136644683moz-txt-link-freetext" href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/l<wbr>istinfo/public</a>
</pre>
              </blockquote>
              <br>
            </div>
            <br>
            ______________________________<wbr>_________________<br>
            Public mailing list<br>
            <a href="mailto:Public@cabforum.org" target="_blank">Public@cabforum.org</a><br>
            <a href="https://cabforum.org/mailman/listinfo/public" rel="noreferrer" target="_blank">https://cabforum.org/mailman/l<wbr>istinfo/public</a><br>
            <br>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
  </div></div></div>

<br>______________________________<wbr>_________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" rel="noreferrer" target="_blank">https://cabforum.org/mailman/<wbr>listinfo/public</a><br>
<br></blockquote></div><br></div>