[cabfpub] Verification of Domain Contact and Domain Authorization Document

Fri Dec 22 15:45:26 UTC 2017

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.

On Fri, Dec 22, 2017 at 2:22 AM, Adriano Santoni via Public <
public at cabforum.org> wrote:

> Ryan,
>
> 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.
>
> 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.
>
> 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.
> For instance, I'd favour zapping the words "directly with the Applicant's
> Representative or" from the second paragraph of BR §3.2.5. Would not that
> be an improvement?
>
> Adriano
>
>
>
> Il 21/12/2017 17:57, Ryan Sleevi ha scritto:
>
> Adriano,
>
> Do you have an example of how you believe 3.2.2.4.1 can be used correctly?
>
> 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.
>
> Here's just one scenario:
> - I ("Ryan Sleevi") apply to Foo CA for example.com, which is owned by
> "Andriano Santoni's Lightly Validated Certificates" - you.
> - Foo CA decides to employ 3.2.2.4.1, using 3.2.2.4(1)
>   - 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
>   - 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.
>   - Alternatively, I send a photoshopped letter claiming your company
> exists, valid under 3.2.2.1(4)
>   - 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
> - They then need to verify whether or not I'm authorized to speak for your
> company.
>   - 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
>   - 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")
>   - 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.
> - Finally, the CA contacts the registrar, and says "Hey, does Adriano
> Santoni's Lightly Validated Certificates own example.com" - and the
> registrar says sure
>   - 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
>
> 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"
>
>
> 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.
>
>
> On Thu, Dec 21, 2017 at 4:00 AM, Adriano Santoni via Public <
> public at cabforum.org> wrote:
>
>> Jeremy, I am not sure I fully understand the problems you describe.
>>
>> 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?
>>
>>
>> Il 19/12/2017 22:30, Jeremy Rowley via Public ha scritto:
>>
>> Hi all,
>>
>>
>>
>> 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.
>>
>>
>>
>> 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.
>>
>>
>>
>> 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.
>>
>>
>>
>> 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?
>>
>>
>>
>> Jeremy
>>
>>
>>
>>
>> _______________________________________________
>> Public mailing listPublic at cabforum.orghttps://cabforum.org/mailman/listinfo/public
>>
>>
>>
>> _______________________________________________
>> Public mailing list
>> Public at cabforum.org
>> https://cabforum.org/mailman/listinfo/public
>>
>>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20171222/3e62de0b/attachment-0003.html>