First, I think everyone knows what CAs are supposed to do under Method 1, and the lack of misissuance reports means CAs are doing it right. Here’s how Method 1 starts now:
“Conforming the Applicant's control over the FQDN by validating the Applicant as the Domain Contact by verifying that: ***” “Applicant” is the person/company asking for a cert. Therefore the Applicant may or may not be the domain owner. This is especially important when the Applicant wants an OV or EV cert using Method 1, where the WhoIs Registrant information (organization name) must be matched against a third party data source, such as a QIIS (Hoover’s, etc.). CAs generally get the phone number used to verify the Applicant Representative is associated with the organization from the QIIS, so organization name matching is important. Domain Contact is ANY ONE of the following (not all of the information): The Domain Name Registrant, technical contact, -OR- administrative contract for the requested domain. So I could register applecares.com where Registrant is Apple, Inc. on Infinity Loop, but list my hacker email address and phone number in WhoIs. If we only require CAs to confirm the Applicant (me, a hacker, trying to get an OV cert that says O = Apple, Inc.) is also the Domain Contact (which can simply be my name and email as Admin Contact) – then I, as a hacker, could arguably get an OV cert showing O = Apple, Inc. It’s true I (hacker) own applecares.com, but I am not Apple, Inc. That’s why it seems more appropriate to change the first line to: “Conforming the Applicant's control over the FQDN by validating the Applicant as the Domain Name Registrant by verifying that:***” We can certainly discuss this further in the VWG – maybe the opening paragraph should be clarified even further, but I think the change from Domain Contact to Domain Name Registrant is probably good as an interim step. From: [email protected] [mailto:[email protected]] Sent: Friday, January 19, 2018 10:44 AM To: Kirk Hall <[email protected]> Cc: CA/Browser Forum Public Discussion List <[email protected]>; Mads Egil Henriksveen <[email protected]> Subject: Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain Authorization Document The ‘Domain Contact’ is not just a name. For example, for cabforum.org <http://cabforum.org> , it’s all of this data: Registrant Name: Domain Administrator Registrant Organization: Go Daddy Operating Company, LLC Registrant Street: 14455 N Hayden Rd Suite 219 Registrant City: Scottsdale Registrant State/Province: Arizona Registrant Postal Code: 85260 Registrant Country: US Registrant Phone: +1.4805058800 Registrant Phone Ext: Registrant Fax: +1.4805058844 Registrant Fax Ext: Registrant Email: [email protected] <mailto:[email protected]> It’s “self-reported”, but not by the Applicant; it’s reported by the actual domain name owner. This data is what has to be matched against the Applicant—you need to confirm that the Applicant will respond when contacted using this information. I’m not sure about limiting this to just the Registrant. The registrant is the ‘owner’ of the domain, but wouldn't the technical contact be likely to have control over the domain? (That’s almost the definition of who you put as the technical contact.) On Jan 19, 2018, at 10:33 AM, Kirk Hall <[email protected] <mailto:[email protected]> > wrote: Jeff - here are the three relevant definitions: Applicant: The natural person or Legal Entity that applies for (or seeks renewal of) a Certificate. Once the Certificate issues, the Applicant is referred to as the Subscriber. Domain Contact: The Domain Name Registrant, technical contact, or administrative contract (or the equivalent under a ccTLD) as listed in the WHOIS record of the Base Domain Name or in a DNS SOA record. Domain Name Registrant: Sometimes referred to as the “owner” of a Domain Name, but more properly the person(s) or entity(ies) registered with a Domain Name Registrar as having the right to control how a Domain Name is used, such as the natural person or Legal Entity that is listed as the “Registrant” by WHOIS or the Domain Name Registrar. "Domain Contact" is just the self-reported name in WhoIs -- so I think Domain Name Registrant is the party we are actually trying to verify as the Applicant. -----Original Message----- From: Public [mailto:[email protected]] On Behalf Of Geoff Keating via Public Sent: Friday, January 19, 2018 10:18 AM To: Mads Egil Henriksveen <[email protected] <mailto:[email protected]> >; CA/Browser Forum Public Discussion List <[email protected] <mailto:[email protected]> > Subject: Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain Authorization Document I think this proposed change actually makes 3.2.2.4.1 weaker. Previously it was necessary to validate that the Applicant and the Domain Contact were the same—some CAs might not have been doing this properly, but it was what the words said. Now you’re just validating that the Applicant has the same name and represents to a Q*IS that it has the same address. > On Jan 19, 2018, at 4:58 AM, Mads Egil Henriksveen via Public < > <mailto:[email protected]> [email protected]> wrote: > > Hi Gerv > > The current version 3.2.2.4.1 says: > ---- > 3.2.2.4.1 Validating the Applicant as a Domain Contact Confirming the > Applicant's control over the FQDN by validating the Applicant is the Domain > Contact directly with the Domain Name Registrar. > > 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 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 3. The CA is also the Domain Name Registrar, or > an Affiliate of the Registrar, of the Base Domain Name. > > 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. > ----- > > Our proposal concentrates on the first part, i.e. the following statement: >>> Confirming the Applicant's control over the FQDN by validating the >>> Applicant is the Domain Contact directly with the Domain Name Registrar. > > Is to be replaced with: > << Conforming the Applicant's control over the FQDN by validating the > Applicant as the Domain Name Registrant by verifying that: > << 1. The name of the Domain Name Registrant matches the Applicant's name AND > << 2. Additional information about the Domain Name Registrant in the WHOIS > meet the following requirements: > << i. The Registrant's postal address in the WHOIS belongs > to the Applicant. CAs MUST verify this by matching it with one of the > Applicant's addresses in: (a) a QGIS, QTIS, or QIIS; or (b) a Verified > Professional Letter. > << Note: Address details in the WHOIS are required to > use this option. Address details must include at a minimum the Country and > either Locality, State or Province. OR > << ii. The WHOIS contains the Registration (or similar) > Number assigned to the Applicant by the Incorporating or Registration Agency > in its Jurisdiction of Incorporation or Registration as appropriate. CAs MUST > verify this by matching the Registration Number in the WHOIS with the > Applicant's Registration Number in a QGIS or a QTIS. > > The first change is the use of Domain Name Registrant instead of Domain > Contact, i.e. the focus is on domain ownership. > > The proposal requires that the name of the Registrant (in WHOIS) matches 1) > the name of the Applicant AND either 2 i) the postal address of the > Registrant (in WHOIS) matches the postal address of the Applicant (in sources > accepted for EV validation) OR 2 ii) a Registration Number for the Registrant > (in WHOIS) matches the Registration Number of the Applicant (in a QGIS or > QTIS). > > The proposal addresses threats due to that organization names are not unique, > the combination of organization name and address or organization name and > registration number should be unique. It also removes ambiguities the current > language permits (according to Jeremy - see attachment). > > Regards > Mads > > -----Original Message----- > From: Public [ <mailto:[email protected]> > mailto:[email protected]] On Behalf Of Gervase > Markham via Public > Sent: fredag 19. januar 2018 10:29 > To: Mads Egil Henriksveen via Public < <mailto:[email protected]> > [email protected]> > Subject: Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and > Domain Authorization Document > > On 19/01/18 06:51, Mads Egil Henriksveen via Public wrote: >> Buypass, Entrust Datacard and GlobalSign have been working on some >> text to strengthen 3.2.2.4.1 instead of removing it - find the draft >> text below. The draft was discussed in the Validation Working Group >> meeting yesterday. We would like to offer this as an amendment to Ballot 218. > > Is it possible to provide a diff, e.g. by turning the new text into a Github > pull request, or some other mechanism? > > Once we have a diff, might it be possible for rationale to be provided for > each change? > > Gerv > _______________________________________________ > Public mailing list > <mailto:[email protected]> [email protected] > <https://cabforum.org/mailman/listinfo/public> > https://cabforum.org/mailman/listinfo/public > <Mail Attachment.eml>_______________________________________________ > Public mailing list > <mailto:[email protected]> [email protected] > <https://cabforum.org/mailman/listinfo/public> > https://cabforum.org/mailman/listinfo/public
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
