Hi
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.
We (and some other CAs as well) are concerned about the short transition period
in Ballot 218. In order to change systems, validation procedures etc. we
believe any transition period should be at least 10 weeks (as long as the
security risk exposed is low).
Regards
Mads
3.2.2.4.1 Validating the Applicant as a Domain Name Registrant
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.
Additionally, 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.
This revised version of BR 3.2.2.4.1 shall apply to domain validations
occurring on or after June 1, 2018.
From: Public [mailto:[email protected]] On Behalf Of Tim Hollebeek
via Public
Sent: onsdag 17. januar 2018 00:13
To: Tim Hollebeek <[email protected]>; CA/Browser Forum Public
Discussion List <[email protected]>; Bruce Morton
<[email protected]>; Jeremy Rowley <[email protected]>
Subject: Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain
Authorization Document
Also, whatever improvements you propose to 3.2.5 (which we might support), our
incident report covered a case of non-compliance with the current rules, so it
does not in any way demonstrate a weakness in the current rules.
It would be best not to confuse unrelated issues.
-Tim
From: Public [mailto:[email protected]] On Behalf Of Tim Hollebeek
via Public
Sent: Tuesday, January 16, 2018 3:55 PM
To: Bruce Morton
<[email protected]<mailto:[email protected]>>;
CA/Browser Forum Public Discussion List
<[email protected]<mailto:[email protected]>>; Jeremy Rowley
<[email protected]<mailto:[email protected]>>
Subject: Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain
Authorization Document
Ok, thanks for the update.
-Tim
From: Bruce Morton [mailto:[email protected]]
Sent: Tuesday, January 16, 2018 3:43 PM
To: Tim Hollebeek
<[email protected]<mailto:[email protected]>>; CA/Browser
Forum Public Discussion List <[email protected]<mailto:[email protected]>>;
Jeremy Rowley <[email protected]<mailto:[email protected]>>
Subject: RE: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain
Authorization Document
Hi Tim,
A few CAs are working on some text to improve 3.2.2.4.1. We also think that
3.2.5 needs to be improved which may also be an improvement to support your
incident report which discusses 3.2.5.
Hopefully text will be available for review in the next day or so.
Thanks, Bruce.
From: Tim Hollebeek [mailto:[email protected]]
Sent: January 16, 2018 10:41 AM
To: Bruce Morton
<[email protected]<mailto:[email protected]>>;
CA/Browser Forum Public Discussion List
<[email protected]<mailto:[email protected]>>; Jeremy Rowley
<[email protected]<mailto:[email protected]>>
Subject: RE: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain
Authorization Document
I was told you guys were going to be providing text that improved method 1. It
now sounds like you think method 1 was good for the last 20 years, and will
continue to be good for ... how long? Has your position changed?
-Tim
From: Public [mailto:[email protected]] On Behalf Of Bruce Morton via
Public
Sent: Monday, January 15, 2018 9:20 AM
To: Jeremy Rowley
<[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'm following up on the original message to remove validation methods 3.2.2.4.1
and 3.2.2.4.5.
We validate a large percentage of certificate requests using 3.2.2.4.1. It is
highly used with our enterprise clients and works great if you know your
customer. We would like to continue using this practice and are open to
updating the BRs to help ensure that the three step methodology using 3.2.2.1,
3.2.2.4.1 and 3.2.5 is sound.
As background method 3.2.2.4.1 is probably the oldest domain validation method
used. Until December 2017, I am not aware of any reported incidents. DigiCert
appears to be the first to report an incident. After rereading the message
below and reviewing the other messages, I cannot determine if any certificates
were mississued. It would be great to get more details or review an incident
report. This is important as we would like to correct the issues rather than
eliminating 3.2.2.4.1 items 1 an 2.
So here is a question for DigiCert: were you reporting certificate misissuance
using 3.2.2.4.1? If yes, will DigiCert be posting an Incident Report on the
Mozilla Dev Security Policy list using Mozilla's standard report form, as is
customary when reporting certificate misissuance?
We really need to understand the problem statement and review some real use
cases. We need to see how 3.2.2.4.1 was combined with 3.2.2.1 and 3.2.5. How
was the registrant verified? What Reliable Method of Communication was used?
We believe that:
- 3.2.2.1 can be used to securely identify the applicant
- 3.2.2.4.1 can be used to verify that the registrant is the applicant
or an affiliate of the applicant
- 3.2.5 can be securely used to verify that an employee of the
applicant has authorized the issuance of the certificate
We would like to continue to work with the Validation Working Group to find new
text to improve these processes.
Thanks, Bruce.
From: Public [mailto:[email protected]] On Behalf Of Jeremy Rowley
via Public
Sent: December 19, 2017 4:30 PM
To: CA/Browser Forum Public Discussion List
<[email protected]<mailto:[email protected]>>
Subject: [EXTERNAL][cabfpub] Verification of Domain Contact and Domain
Authorization Document
Hi all,
When reviewing the Symantec validation methods and the customers using each
method, I found an alarming number of customers verified under 3.2.2.4.1
(Verification of a Domain Contact) or 3.2.2.4.5 (Domain Authorization Document)
where the domain is not technically associated with the entity. These two
methods need improvement or removal as the way they are currently lacks
sufficient controls to associate the domain verification with the actual
certificate approver. I've had too many calls with customers explaining
re-verification where the domain holder didn't understand that a cert issued
for the domain. Although the organization verification was successfully
complete, the only tie between the domain and organization is a call to the
organization that happened within the last years to approve the account for
issuance. I wanted to bring it up here because I've always thought these
methods were less desirable than others. I think other large CAs use this
method quite a bit so I'm hoping to get clarity on why these methods are
permitted when the domain verification seems more "hand-wavy" than other
methods.
Method 3.2.2.4.1 permits a CA to issue a certificate if the certificate is an
EV or OV cert. With EV certificates, there is a call to a verified telephone
number that confirms the requester's affiliation with the organization. I can
see this method working for EV. For OV certificates, there is a reliable
method of communication that confirms the account holder as affiliated with the
organization. Unlike EV, for OV certs there is no tie between the requester
and their authority to request a certificate. Once the organization is
verified, the BRs permit auto-issuance for any domain that reflects an
affiliation with the verified entity for up to 825 days. There's no notice to
the domain contact that the certificate was requested or approved. Perhaps
this is sufficient as the account has been affiliated with the organization
through the reliable method of communication and because CT will soon become
mandatory.
Method 3.2.2.4.5 permits a CA to issue a certificate using a legal opinion
letter for the domain. Unfortunately the BRs lack clear requirements about how
the legal opinion letter is verified. If I want a cert for Google.com and the
CA is following the bare minimum, all I need to do is copy their letterhead and
sign the document. Magically, a certificate can issue. This method lacks a lot
of controls of method 1 because there is no requirement around verification of
the company. I can list as many domains in the letter as I'd like provided the
entity listed in the corresponding WHOIS's letterhead is used.
I'm looking to remove/fix both of these methods as both these methods lack the
necessary controls to ensure that the verification ties to the domain holder.
These methods probably should have been removed back when we passed 169/182.
Would anyone being willing to endorse a ballot killing these or making some
necessary improvements?
Jeremy
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
