This does not resolve the issues mentioned. On Thu, Jan 4, 2018 at 7:47 AM, Mads Egil Henriksveen via Public < public@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-boun...@cabforum.org] *On Behalf Of *Jeremy > Rowley via Public > *Sent:* onsdag 3. januar 2018 23:25 > *To:* geo...@apple.com > *Cc:* CA/Browser Forum Public Discussion List <public@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:* geo...@apple.com [mailto:geo...@apple.com <geo...@apple.com>] > *Sent:* Wednesday, January 3, 2018 2:54 PM > *To:* Jeremy Rowley <jeremy.row...@digicert.com> > *Cc:* CA/Browser Forum Public Discussion List <public@cabforum.org>; Ryan > Sleevi <sle...@google.com>; Adriano Santoni <adriano.santoni@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.row...@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:* geo...@apple.com [mailto:geo...@apple.com <geo...@apple.com>] > *Sent:* Tuesday, January 2, 2018 4:34 PM > *To:* Jeremy Rowley <jeremy.row...@digicert.com>; CA/Browser Forum Public > Discussion List <public@cabforum.org> > *Cc:* Ryan Sleevi <sle...@google.com>; Adriano Santoni < > adriano.sant...@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@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@cabforum.org > https://cabforum.org/mailman/listinfo/public > >
_______________________________________________ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public