That data is correct as GoDaddy Registered the domain name.

If the Applicant is CA/Browser Forum and the Registrant is GoDaddy, then method 
1 will fail by design.

Bruce.

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Geoff Keating 
via Public
Sent: January 19, 2018 1:44 PM
To: Kirk Hall <kirk.h...@entrustdatacard.com>
Cc: CA/Browser Forum Public Discussion List <public@cabforum.org>
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: companyna...@godaddy.com<mailto:companyna...@godaddy.com>


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 
<kirk.h...@entrustdatacard.com<mailto:kirk.h...@entrustdatacard.com>> 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:public-boun...@cabforum.org] On Behalf Of Geoff Keating 
via Public
Sent: Friday, January 19, 2018 10:18 AM
To: Mads Egil Henriksveen 
<mads.henriksv...@buypass.no<mailto:mads.henriksv...@buypass.no>>; CA/Browser 
Forum Public Discussion List <public@cabforum.org<mailto:public@cabforum.org>>
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 
> <public@cabforum.org<mailto:public@cabforum.org>> 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:public-boun...@cabforum.org] On Behalf Of Gervase
> Markham via Public
> Sent: fredag 19. januar 2018 10:29
> To: Mads Egil Henriksveen via Public 
> <public@cabforum.org<mailto:public@cabforum.org>>
> 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
> Public@cabforum.org<mailto:Public@cabforum.org>
> https://cabforum.org/mailman/listinfo/public
> <Mail Attachment.eml>_______________________________________________
> Public mailing list
> Public@cabforum.org<mailto:Public@cabforum.org>
> https://cabforum.org/mailman/listinfo/public

_______________________________________________
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Reply via email to