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

Fri Jan 19 17:08:38 UTC 2018

Are you saying you actually use method #5?  I keep asking CAs, and I have
yet to hear from one that actually uses method #5.  Most of the concern
seems to be around method #1.

-Tim

From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Entschew,
Enrico via Public
Sent: Friday, January 19, 2018 9:48 AM
To: 'Mads Egil Henriksveen' <Mads.Henriksveen at buypass.no>; 'CA/Browser Forum
Public Discussion List' <public at cabforum.org>
Subject: Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain
Authorization Document

Hi all,

D-TRUST fully supports the ongoing discussion on improving BR section
3.2.2.4.1 and 3.2.2.4.5. In our opinion all options on improving the methods
need to be taken into account. Only if there is no way of optimizing the
procedure in order to prohibit potential misissuance scenarios based on this
procedure it should be entirely removed.

Both methods are extensively used by CA/B-Forum members. A removal of the
validation methods would cause serious consequences for CA operations and
also impact existing customers. These impact needs to be evaluated first.

To get a good and secure solution, we suggest to assess the results of the
Validation WG during the next face to face meeting and prepare a (probably
modified) ballot afterwards.

Regards

Enrico

Von: Public [mailto:public-bounces at cabforum.org] Im Auftrag von Mads Egil
Henriksveen via Public
Gesendet: Freitag, 19. Januar 2018 07:52
An: Tim Hollebeek; CA/Browser Forum Public Discussion List; Bruce Morton;
Jeremy Rowley
Betreff: Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain
Authorization Document

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:public-bounces at cabforum.org] On Behalf Of Tim Hollebeek
via Public
Sent: onsdag 17. januar 2018 00:13
To: Tim Hollebeek <tim.hollebeek at digicert.com
<mailto:tim.hollebeek at digicert.com> >; CA/Browser Forum Public Discussion
List <public at cabforum.org <mailto:public at cabforum.org> >; Bruce Morton
<Bruce.Morton at entrustdatacard.com <mailto:Bruce.Morton at entrustdatacard.com>
>; Jeremy Rowley <jeremy.rowley at digicert.com
<mailto:jeremy.rowley at digicert.com> >
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:public-bounces at cabforum.org] On Behalf Of Tim Hollebeek
via Public
Sent: Tuesday, January 16, 2018 3:55 PM
To: Bruce Morton <Bruce.Morton at entrustdatacard.com
<mailto:Bruce.Morton at entrustdatacard.com> >; CA/Browser Forum Public
Discussion List <public at cabforum.org <mailto:public at cabforum.org> >; Jeremy
Rowley <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com> >
Subject: Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain
Authorization Document

Ok, thanks for the update.

-Tim

From: Bruce Morton [mailto:Bruce.Morton at entrustdatacard.com] 
Sent: Tuesday, January 16, 2018 3:43 PM
To: Tim Hollebeek <tim.hollebeek at digicert.com
<mailto:tim.hollebeek at digicert.com> >; CA/Browser Forum Public Discussion
List <public at cabforum.org <mailto:public at cabforum.org> >; Jeremy Rowley
<jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com> >
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:tim.hollebeek at digicert.com] 
Sent: January 16, 2018 10:41 AM
To: Bruce Morton <Bruce.Morton at entrustdatacard.com
<mailto:Bruce.Morton at entrustdatacard.com> >; CA/Browser Forum Public
Discussion List <public at cabforum.org <mailto:public at cabforum.org> >; Jeremy
Rowley <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com> >
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:public-bounces at cabforum.org] On Behalf Of Bruce Morton
via Public
Sent: Monday, January 15, 2018 9:20 AM
To: Jeremy Rowley <jeremy.rowley at digicert.com
<mailto:jeremy.rowley at digicert.com> >; CA/Browser Forum Public Discussion
List <public at cabforum.org <mailto:public at cabforum.org> >
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:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley
via Public
Sent: December 19, 2017 4:30 PM
To: CA/Browser Forum Public Discussion List <public at cabforum.org
<mailto:public at cabforum.org> >
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180119/2ee183f1/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180119/2ee183f1/attachment-0003.p7s>