[cabf_validation] Analysis of Ben's latest draft for domain validation methods

[kirk_hall at trendmicro.com]

Ben, your latest draft of July 25 threw me (it looked so different from the July 2 draft and the current BRs), but I think I can track what you have done.  Maybe on the call tomorrow you can highlight where you have made substantive changes from your draft of July 2 (both attached).

Here is how I analyze your latest draft.  [Comments in red]  On tomorrow's call, can you walk us through it, including any changes you made to definitions?

*****

Proposed Revisions to Domain Validation Requirements

Amendment to Section 3.2.2.4 of CA/Browser Forum Baseline Requirements to clarify acceptable methods of validating domain control:

1)         Add the following definitions to Section 1.6:

Authorization Domain Name: The Domain Name used to obtain authorization for certificate issuance for a given FQDN.  By default, this is the Registered Domain for the FQDN or the FQDN itself.  The CA may derive an alternative Authorization Domain Name in the following ways:
- Removing the "*" label from a wildcard FQDN (see Section 3.2.2.6), or
- Using the name returned from a DNS CNAME request, or a chain of CNAME redirects

Random Value: A value specified by a CA to the Applicant that exhibits at least 128 bits of entropy.

Request Token: A value derived in a method specified by the CA, which uniquely identifies the Applicant.  For example, the CA may use as a Request Token a Random Value provided to the Applicant in a session where the Applicant is authenticated or the CA may derive the Request Token from the public key to be certified.

Secure Location:  A directory with a unique name [define] located within a well-known directory [define] and accessible at port 80 or 443 at an Authorization Domain Name in which an Applicant may post a Request Token.

Test Certificate: A Certificate which includes data that renders the Certificate unusable for use by an application software vendor or publicly trusted TLS server such as the inclusion of a critical extension that is not recognized by any known application software vendor or a certificate issued under a root certificate not subject to these Requirements.

2)         Section 3.2.2.4 of the CA/Browser Forum's Baseline Requirements is amended as follows:
...
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 and that certificate issuance is authorized.

The CA's method of obtaining confirmation or authorization of certificate issuance SHALL include security measures sufficient to prevent a third party (i.e. who is not the Domain Name Registrant or who does not have control over the FQDN) from obtaining a certificate.

Where confirmation is sought by email and an automated process for recording the successful response is used, such as the provision of a hyper-link in an email, the CA MUST use a value that is unpredictable and previously unknown to the applicant  in the email and verify that the value is also present in the response. The CA MUST NOT rely on a Random Value, Request Token or Test Certificate generated more than 14 days prior to completion of the verification under this section.

Acceptable methods for a CA to confirm domain registration (or control) and authorization are as follows:

(1) Communicate with the Domain Name Registrant or Domain Name Registrar (or private, anonymous, or proxy registration service) for the FQDN, as listed in WHOIS, and confirm authorization of certificate issuance for the FQDN:  [Shouldn't this be its own separate confirmation method - WhoIs lookup?  This is old method #1]

a.   through an email communication to an email address created by pre-pending 'admin', 'administrator', 'webmaster', 'hostmaster', or 'postmaster' in the local part, followed by the at-sign ("@"), followed by an Authorization Domain Name; or  [old method #3)
b.   with the contact listed as the "registrant", "technical", or "administrative" contact in the WHOIS record for the Registered Domain Name;  [old method #2]

Note:  A Domain Authorization Document, which the CA previously obtained through a Reliable Method of Communication under a. or b., which establishes that the Domain Name Registrant has authorized the Applicant to obtain a certificate for the FQDN may be used to demonstrate authorization provided that the CA verifies that the WHOIS record still shows the same Domain Name Registrant as when the CA obtained the Domain Authorization Document; [Shouldn't this be a separate confirmation method?  It's old method #4]

OR

(2)   Having the Applicant demonstrate practical control over the requested FQDN by:

a. adding a file, filename, or directory containing a Random Value or a Request Token provided by the CA, provided that the Random Value or Request Token is posted to a Secure Location at an Authorization Domain Name for the FQDN in accordance with RFC 5785; or [old method #5]
b.   making a change to information in a DNS record for the Authorization Domain Name where the change is to insert a Random Value or Request Token; or [old method #6]
c.  requesting and then installing a Test Certificate issued by the CA on the FQDN which is accessed and then validated via https by the CA at one of the following ports: 443, .... [old method #9]

OR

(3)   Having the CA perform a DNS lookup for:

a. CNAME records for the requested FQDN at _______ , provided that the CA performs one of subsections 1 through 6 above (or also this subsection 7, iteratively if necessary), and uses the ____ that is determined thereby, yada yada; or [old method #7]
b.   A or AAAA records for the requested IP address, provided that the CA confirms control in accordance with procedures stated in section 3.2.2.5.  [old method #8]

Note: FQDNs may be listed in Subscriber Certificates using dNSNames in the subjectAltName extension or in Subordinate CA Certificates via dNSNames in permittedSubtrees within the Name Constraints extension. [New?]




<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/20150730/f897e32e/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Proposed Revisions to Domain Validation Requirements (7-25-2015).docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 14067 bytes
Desc: Proposed Revisions to Domain Validation Requirements
 (7-25-2015).docx
Url : https://cabforum.org/pipermail/validation/attachments/20150730/f897e32e/attachment-0002.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Domain Validation Revision Proposal - July 2 2015.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 24683 bytes
Desc: Domain Validation Revision Proposal - July 2 2015.docx
Url : https://cabforum.org/pipermail/validation/attachments/20150730/f897e32e/attachment-0003.bin