[cabf_validation] Question on use of Domain Authorization Document for domain vetting

Fri Aug 14 06:27:09 MST 2015

We don’t rely “solely” on a Domain Authorization Document, because in
nearly all cases you have to at least check with WHOIS to see who has
control over the domain.  I suppose that if you were trying to establish
control over one of the new gTLDs you might need to do it without checking
WHOIS and instead you’d need to rely on the agreements found here -
https://www.icann.org/resources/pages/registries/registries-agreements-en.
I don’t know if anyone has used that, but even in that case, you’re not
relying “solely”  on the DAD, because there is a public list of registry
agreements that you’re checking.

From: validation-bounces at cabforum.org
[mailto:validation-bounces at cabforum.org] On Behalf Of
kirk_hall at trendmicro.com
Sent: Thursday, August 13, 2015 1:46 PM
To: validation at cabforum.org
Subject: Re: [cabf_validation] Question on use of Domain Authorization
Document for domain vetting

Sorry - to clarify me request below about use of DADs:

Can you list some use cases for relying solely on a DAD for domain
authorization that are not already covered by validation methods 1-4 and 6,
which are:

1. Confirming the Applicant as the Domain Name Registrant directly with the
Domain Name Registrar;

2. Communicating directly with the Domain Name Registrant using an address,
email, or telephone

number provided by the Domain Name Registrar;

3. Communicating directly with the Domain Name Registrant using the contact
information listed in the

WHOIS record’s “registrant”, “technical”, or “administrative” field;

4. Communicating with the Domain’s administrator using an email address
created by pre‐pending

‘admin’, ‘administrator’, ‘webmaster’, ‘hostmaster’, or
‘postmaster’ in the local part, followed by the

at‐sign (“@”), followed by the Domain Name, which may be formed by
pruning zero or more

components from the requested FQDN;

6. Having the Applicant demonstrate practical control over the FQDN by
making an agreed‐upon

change to information found on an online Web page identified by a uniform
resource identifier

containing the FQDN; or

From: Kirk Hall (RD-US)
Sent: Thursday, August 13, 2015 11:17 AM
To: validation at cabforum.org <mailto:validation at cabforum.org>
Subject: Question on use of Domain Authorization Document for domain vetting

On the VWG call this morning, I mentioned that the current language for the
domain validation method using a Domain Authorization Document (DAD) is
extremely hard to understand, and suggested people let us know how they are
using DADs so we can improve the language.  There is no intention of
eliminating this method, just making the language better.

Here is current domain validation method #5 in BR 3.2.2.4:

3.2.2.4. Authorization by Domain Name Registrant

For each Fully‐Qualified Domain Name listed in a Certificate, the CA SHALL
confirm that, as of the date the Certificate was issued, the Applicant (or
the Applicant’s Parent Company, Subsidiary Company, or Affiliate,
collectively referred to as “Applicant” for the purposes of this section)
either is the Domain Name Registrant or has control over the FQDN by: ***

5. Relying upon a Domain Authorization Document;

Here is the definition of a DAD, parsed to show why it’s confusing today:

TEXT

COMMENTS

Domain Authorization Document:

A

Documentation provided by,

Documents the CA receives from someone else, or

B

or a CA’s documentation of a communication with,

A record created (and retained) by the CA of a communication (presumably
phone, maybe email or fax?) with a party listed in the next three rows

C

a Domain Name Registrar,

So a document from or recording a communication with a Registrar

D

the Domain Name Registrant,

So a document from or recording a communication with a Registrant - does
this imply it can only come a party that is listed as the Registrant in the
WhoIs registry for the domain?  It seems to say that.

I guess this might be used if the Registrant in WhoIs is Company A, and the
Applicant for the domain is Company B, and you get a letter from Company A
saying “I have licensed Company B to use my domain - it’s ok”.  Any other
uses?

E

or the person or entity listed in WHOIS as the Domain Name Registrant
(including any private, anonymous, or proxy registration service)

What’s the difference between “the Domain Name Registrant” in the prior
row, and “the person or entity listed in WHOIS as the Domain Name
Registrant” in this row?  Aren’t they the same?

Is the prior row trying to include the Applicant, even if the Applicant
isn’t listed as the Registrant in WhoIs?  It doesn’t read that way.

F

attesting to the authority of an Applicant to request a Certificate for a
specific Domain Namespace.

So the “documentation” is only a DAD if it attests to the authority of the
Applicant to use the domain.

Early in the call we discussed that a DAD has often been used when an
Applicant wants to show ownership or control of a long list of its domains,
and submits an attorney/accountant letter attesting that the Applicant owns
or controls the domains (which sufficient for vetting purposes).  The
attorney/accountant letter would be a DAD, and under method #5, that would
be sufficient to authenticate the domains.  But attorney/accountant letters
are probably going away.  So how else are CAs using DADs for domain
authentication?

I would mention that BR 3.3.1 allows vetting data to be used for 39 months
before revetting is required:

The CA MAY use the documents and data provided in Section 3.2 to verify
certificate information, provided that the CA obtained the data or document
from a source specified under Section 3.2 no more than thirty‐nine (39)
months prior to issuing the Certificate.

So if a CA has vetted a domain using one of Methods #1-4 or #6-7 on a given
date (and has a record of that in the file), the CA can reuse the same data
for the customer for later cert requests for the same domain - in my
opinion, there is no need to call the record of the first vetting a “DAD”
and then say “I’m relying on the DAD as method #5” the next time the same
customer asks for another cert for the same domain - the vetting has already
been done and is good for 39 months (and subsequent cert requests) under BR
3.3.1, and the CA does not need to pretend the vetting was repeated by
reference to a DAD containing results of the earlier vetting.

Does anyone have a specific use-case of current method #5 requiring a DAD
they can share (and where the DAD by itself is sufficient to complete the
vetting)?  If we can gather these use-cases, maybe we can improve the
language of this current vetting method so it can be understood.

TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential
and may be subject to copyright or other intellectual property protection.
If you are not the intended recipient, you are not authorized to use or
disclose this information, and we request that you notify us by reply mail
or
telephone and delete the original message from your mail system.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/validation/attachments/20150814/9dd3b14d/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4954 bytes
Desc: not available
Url : https://cabforum.org/pipermail/validation/attachments/20150814/9dd3b14d/attachment-0001.bin 