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]] On Behalf Of Gervase Markham
via Public
Sent: fredag 19. januar 2018 10:29
To: Mads Egil Henriksveen via Public <[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]
https://cabforum.org/mailman/listinfo/public
--- Begin Message ---
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: [email protected] [mailto:[email protected]]
Sent: Wednesday, January 3, 2018 2:54 PM
To: Jeremy Rowley <[email protected]>
Cc: CA/Browser Forum Public Discussion List <[email protected]>; Ryan Sleevi
<[email protected]>; Adriano Santoni <[email protected]>
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
<[email protected]<mailto:[email protected]>> 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: [email protected]<mailto:[email protected]> [mailto:[email protected]]
Sent: Tuesday, January 2, 2018 4:34 PM
To: Jeremy Rowley
<[email protected]<mailto:[email protected]>>; CA/Browser
Forum Public Discussion List <[email protected]<mailto:[email protected]>>
Cc: Ryan Sleevi <[email protected]<mailto:[email protected]>>; Adriano
Santoni <[email protected]<mailto:[email protected]>>
Subject: Re: [cabfpub] Verification of Domain Contact and Domain
Authorization Document
On Dec 22, 2017, at 12:09 PM, Jeremy Rowley via Public
<[email protected]<mailto:[email protected]>> 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<http://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.
smime.p7s
Description: smime.p7s
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
--- End Message ---
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
