[cabfpub] Verification of Domain Contact and Domain Authorization Document

Thu Jan 4 17:36:37 UTC 2018

This does not resolve the issues mentioned.

On Thu, Jan 4, 2018 at 7:47 AM, Mads Egil Henriksveen via Public <
public at cabforum.org> wrote:

> Removing method  1 is not the only way to solve this ambiguity, it could
> also be solved by changing the language of 3.2.2.4.1 into something like
> this (changes are redlined in attached document):
>
>
>
> *3.2.2.4.1 Validating the Applicant as a Domain Name Registrant*
>
> Confirming the Applicant's control over the FQDN by validating the
> Applicant is the Domain Name Registrant. 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, OR
> The Applicant identity and address must match the Domain Name Registrant.
>
> 2. The CA authenticates the Applicant's identity under EV Guidelines
> Section 11.2 and the agency of the Certificate Approver under EV Guidelines
> Section 11.8; OR
> The Applicant must be the same legal entity as the Domain Name Registrant
>
>
>
> Note: Once the FQDN has been validated using this method, the CA MAY also
> issue Certificates for other
>
> FQDNs that end with all the labels of the validated FQDN. This method is
> suitable for validating Wildcard
>
> Domain Names.
>
>
>
> This would also allow for using method 1 for the use cases I have
> identified.
>
>
>
> Regards
>
> Mads
>
>
>
> *From:* Public [mailto:public-bounces at cabforum.org] *On Behalf Of *Jeremy
> Rowley via Public
> *Sent:* onsdag 3. januar 2018 23:25
> *To:* geoffk at apple.com
> *Cc:* CA/Browser Forum Public Discussion List <public at cabforum.org>
> *Subject:* 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://lists.cabforum.org/pipermail/public/attachments/20180104/47e3063a/attachment-0003.html>