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] 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]> 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]>; CA/Browser Forum > Public Discussion List <[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 > > <[email protected] <mailto:[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 <[email protected] > > <mailto:[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 > > [email protected] <mailto:[email protected]> > > https://cabforum.org/mailman/listinfo/public > > <https://cabforum.org/mailman/listinfo/public> > > <Mail Attachment.eml>_______________________________________________ > > Public mailing list > > [email protected] <mailto:[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
