[cabfpub] [EXTERNAL]Re: Verification of Domain Contact and Domain Authorization Document

[Ryan Sleevi]

Given that CAs have competing interests - namely, to sell certificates
first and foremost, while at the same time not doing anything too egregious
to get noticed and thus distrusted - I don't think it's reasonable,
particularly given the economic incentives and industrial behaviour, to
suggest that CAs would find this as something to reject.

Most CAs, at the end of the day, mint certs for money. CAs particularly
concerned about appearances such as market share are further incentivized
to make minting certs easier. It is thus unsurprising that this sort of
incentive structure results in what we might term 'exploitative' (in a
security mindset), while the CA might call it 'innovative' or 'customer
friendly'.

On Wed, Jan 3, 2018 at 5:41 PM, Bruce Morton via Public <public at cabforum.org
> wrote:

> The requirement may mean a LOT of things, but it is also qualified by
> language such as “This method may only be used if: 1. The CA authenticates
> the Applicant's identity under BR Section 3.2.2.1 and the authority of the
> Applicant Representative under BR Section 3.2.5.”
>
>
>
> I assume it will be stated that the language in 3.2.2.1 and 3.2.5 also
> mean a LOT of things, but this is the job of the CA to create a policy
> which is effective. Per BR 5, the CA should also do risk assessments and
> security plans. Using this methodology will help the CA close the loopholes
> in its processes. Of course, if the CA still finds the risk too high, then
> they can stop using the method.
>
>
>
> Bruce.
>
>
>
> *From:* Public [mailto:public-bounces at cabforum.org] * On Behalf Of *Jeremy
> Rowley via Public
> *Sent:* January 3, 2018 5:25 PM
> *To:* geoffk at apple.com
> *Cc:* CA/Browser Forum Public Discussion List <public at cabforum.org>
> *Subject:* [EXTERNAL]Re: [cabfpub] Verification of Domain Contact and
> Domain Authorization Document
>
>
>
> The ambiguity is exactly why we need to remove method 1. I’ve seen all of
> the following:
>
> 1)      Approval based on a name match
>
> 2)      Approval based on an email match (same email as requester or the
> email is a corporate email) – note that this is a Domain Contact match
>
> 3)      Approval based on address and name match
>
> 4)      Approval based on a letter from the registrar
>
> 5)      Approval based on a call to the registrar
>
> 6)      Approval based on a validation email to the registrar
>
>
>
> All of these are equally permitted by the language, IMO, because “by
> validating the Applicant has the same name as the Domain Contact
> directly with the Domain Name Registrar” can mean a LOT of things.
>
>
>
> *From:* geoffk at apple.com [mailto:geoffk at apple.com <geoffk at apple.com>]
> *Sent:* Wednesday, January 3, 2018 2:54 PM
> *To:* Jeremy Rowley <jeremy.rowley at digicert.com>
> *Cc:* CA/Browser Forum Public Discussion List <public at cabforum.org>; Ryan
> Sleevi <sleevi at google.com>; Adriano Santoni <adriano.santoni at staff.aruba.
> it>
> *Subject:* Re: [cabfpub] Verification of Domain Contact and Domain
> Authorization Document
>
>
>
> It looks like we’re going to be removing 3.2.2.4.1, so this will be moot,
> but just to explain the interpretation, 3.2.2.4.1 says that what you are
> doing (this sentence is the entire description of the method, the rest of
> the section just limits its application) is "Confirming the Applicant's
> control over the FQDN by validating the Applicant is the Domain Contact
> directly with the Domain Name Registrar.”
>
>
>
> This is not a name match.  If the BRs wanted to say “by validating the
> Applicant has the same name as the Domain Contact”, they would say so.
> This is a one-and-the-same match, it uses the word “is”.  In the example
> below, the CA must ensure that “Google Inc., the Utah corporation” is the
> same one as shown in the WHOIS information, and all the WHOIS information
> is relevant in confirming this.
>
>
>
> Another important clarification is that if you use 3.2.2.1, it doesn’t
> just verify “the name of the applicant”; it says that "the CA SHALL
> verify the identity and address of the organization”, not just the name.
>  (Um… actually, if you read it closely, you might not verify the name at
> all, if you identify the organization in another way, maybe with some kind
> of ID number.  That’s probably a bug.)
>
>
>
> On 2 Jan 2018, at 8:47 pm, Jeremy Rowley <jeremy.rowley at digicert.com>
> wrote:
>
>
>
> I disagree. The requirements do not specify that.  All that is required is
> the name of the applicant was verified under 3.2.2.1 and that the register
> specify the domain contact is the applicant. If Google, Inc. is specified
> as the domain contact, no address matching is required.
>
>
>
> *From:* geoffk at apple.com [mailto:geoffk at apple.com <geoffk at apple.com>]
> *Sent:* Tuesday, January 2, 2018 4:34 PM
> *To:* Jeremy Rowley <jeremy.rowley at digicert.com>; CA/Browser Forum Public
> Discussion List <public at cabforum.org>
> *Cc:* Ryan Sleevi <sleevi at google.com>; Adriano Santoni <
> adriano.santoni at staff.aruba.it>
> *Subject:* Re: [cabfpub] Verification of Domain Contact and Domain
> Authorization Document
>
>
>
>
>
>
>
> On Dec 22, 2017, at 12:09 PM, Jeremy Rowley via Public <
> public at cabforum.org> wrote:
>
>
>
> The attack vector is easier than that.
>
>    1. I use very stringent processes to verify that Google, Inc. is a
>    legit company in Utah.
>    2. I verify that Jeremy did indeed incorporate Google, Inc.
>    3. I call Jeremy at the phone listed for Google, Inc., the Utah
>    corporation
>    4. The domain information shows Google, Inc. as owning google.com
>    5. Certificate issues.
>
>
>
> Obviously this would be caught in every CA’s high risk checks, but the
> point remains valid. Regardless of the expertise and thoroughness of the
> org check, the specs lack any time between the verified org and the actual
> domain because orgs are not unique on a global basis.
>
>
>
>
>
> For item 4, you have to verify that “the Applicant is the Domain
> Contact”.  Obviously it’s insufficient to just compare names—you must
> verify every element of the WHOIS contact matches the Applicant, that’s
> typically name, postal address, phone number, and e-mail.
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20180104/82e20520/attachment.html>