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

[kirk_hall at trendmicro.com]

OK, you guys have educated me, and convinced me that current method #5 with Domain Authorization Documents does not need revision.  Thanks.
From: Cecilia Kam [mailto:Cecilia_Kam at symantec.com]
Sent: Friday, August 14, 2015 11:28 AM
To: Ben Wilson; Kirk Hall (RD-US); validation at cabforum.org
Subject: RE: [cabf_validation] Question on use of Domain Authorization Document for domain vetting

Along with what Ben is saying the Domain Authorization Document is not solely used but is for documenting our process of communication with the Registrar or Registrant until authorization is received.

From: validation-bounces at cabforum.org<mailto:validation-bounces at cabforum.org> [mailto:validation-bounces at cabforum.org] On Behalf Of Ben Wilson
Sent: Friday, August 14, 2015 06:27
To: kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com>; validation at cabforum.org<mailto:validation at cabforum.org>
Subject: Re: [cabf_validation] Question on use of Domain Authorization Document for domain vetting

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> [mailto:validation-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com>
Sent: Thursday, August 13, 2015 1:46 PM
To: validation at cabforum.org<mailto: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.




<table class="TM_EMAIL_NOTICE"><tr><td><pre>
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.
</pre></td></tr></table>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/validation/attachments/20150818/81cce180/attachment-0001.html