[cabf_validation] Replacement for Domain Validation Method 6

[Doug Beattie]

This is for discussion before we turn into a full ballot since it's been a while since we discussed the set of changes.  If there isn't much to say then I will turn this into a formal ballot and put it out for final review and voting.



=============================



Ballot SCxx:  Replacement for Domain Validation Method 6 (Agreed-Upon Change to Website)



Purpose of Ballot:  This ballot creates a new Domain Validation method that is like Method 6 (Agreed-Upon Change to Website) but which more clearly specifies some of the details.  This ballot also sets an sunset date for using the current Method 6

The following motion has been proposed by Doug Beattie of GlobalSign and endorsed  by Jacob Hoffman-Andrews of Lets Encrypt and Bruce Morton of Entrust.



Conflicts with other ballots:

This ballot may conflict with:

*       Ballot SC23: Precertificates
*       Ballot SC24: Fall Cleanup

---MOTION BEGINS---



Update Section 1.6.1 to remove definition for "Required Website Content" as that define term is no longer being used.

Add a note to the end of 3.2.2.4.6

Note: CAs SHALL NOT perform validations using this method after 3 months from IPR review date.  Completed validations using this method SHALL continue to be valid for subsequent issuance per the applicable certificate data reuse periods.



Add Section 3.2.2.4.17



3.2.2.4.17 Agreed-Upon Change to Website v2

Confirming the Applicant's control over the FQDN by verifying that the Request Token or Random Value is contained in the contents of a file.

A.      The entire Request Token or Random Value MUST NOT appear in the request used to retrieve the file, and
B.      the CA MUST receive a successful HTTP response from the request (meaning a 2xx HTTP return code must be received).



The file containing the Request Token or Random Number SHALL:

1.      be located on an Authorization Domain Name, and
2.      be located under the "/.well-known/pki-validation" or ".well-known/acme-challenge/" directory, and
3.      be accessed via HTTP or HTTPS, and
4.      be accessed over an Authorized Port.

If the CA follows redirects, then the CA SHALL:

a.      follow only server side (3xx) redirects, and
b.      follow 10 or fewer redirects, and
c.      follow only HTTP and HTTPS redirects, and
d.      follow redirects only to Authorized Ports.



If a Random Value is used, then:

i.      the CA SHALL provide a Random Value unique to the certificate request and
ii.     the CA SHALL NOT use the Random Value after the longer of (i) 30 days or (ii) if the Applicant submitted the Certificate request, the timeframe permitted for reuse of validated information relevant to the Certificate (such as in Section 4.2.1 of these Guidelines or Section 11.14.3 of the EV Guidelines).



**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.



---MOTION ENDS---



*** WARNING ***: USE AT YOUR OWN RISK.  THE REDLINE BELOW IS NOT THE OFFICIAL VERSION OF THE CHANGES (CABF Bylaws, Section 2.4(a)):



A comparison of the changes can be found at:





The procedure for approval of this ballot is as follows:

Discussion (7+ days)

Start Time: November XX , 2019 9:30am Eastern

End Time: Not before November XX, 2019 9:30am Eastern



Vote for approval (7 days)



Start Time: TBD

End Time: TBD



-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 53278 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20191101/3be4ffba/attachment-0001.bin>