[cabfpub] [EXTERNAL] Verification of Domain Contact and Domain Authorization Document

Geoff Keating geoffk at apple.com
Fri Jan 19 11:18:21 MST 2018


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 at 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-bounces at cabforum.org] On Behalf Of Gervase Markham via Public
> Sent: fredag 19. januar 2018 10:29
> To: Mads Egil Henriksveen via Public <public at 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 at cabforum.org
> https://cabforum.org/mailman/listinfo/public
> <Mail Attachment.eml>_______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3321 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/public/attachments/20180119/315cf186/attachment.p7s>


More information about the Public mailing list