[cabf_validation] Pre-Ballot discussion on SC25: Define New HTTP Domain Validation Methods

Fri Nov 8 12:20:30 MST 2019

I've incorporated comments from Ryan and Jacob and taken a first shot a
defining a new method for the ACME HTTP method.

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

Ballot SC25:  Define New HTTP Domain Validation Methods

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

Motivation:

Provide additional clarity around the Method 6 validation method and to
specify a new HTTP method that describes the ACME HTTP method defined in
section 8.3 of RFC 8555

---MOTION BEGINS---

Purpose of Ballot: Update to CAB Forum Baseline Requirements to:

*	Provide additional clarity around how http validation method should
be used by creating a new HTTP method and setting a sunset date for method 6
*	Define a method that is specific to the HTTP method defined in
section 8.3 of RFC 8555

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 MUST NOT perform validations using this method after 3 months from
IPR review date.  CAs may continue to use domains validated under this
method per the applicable certificate data reuse periods.

Add Sections 3.2.2.4.17 and 3.2.2.4.18

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. 

1.	The entire Request Token or Random Value MUST NOT appear in the
request used to retrieve the file, and
2.	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: 

1.	MUST be located on the Authorization Domain Name, and
2.	MUST be located under the "/.well-known/pki-validation" directory,
and
3.	MUST be retrieved via either the "http" or "https" scheme, and
4.	MUST be accessed over an Authorized Port.

If the CA follows redirects the following apply:

1.	Redirects MUST be initiated at the HTTP protocol layer (e.g. using a
3xx status code).
2.	Redirects MUST be the result of an HTTP status code result within
the 3xx Redirection class of status codes, as defined in RFC 7231, Section
6.4.
3.	CAs MUST NOT follow more than 10 redirects.
4.	Redirects MUST be to resource URLs with either via the "http" or
"https" scheme.
5.	Redirects MUST be to resource URLs accessed via Authorized Ports.

If a Random Value is used, then:

1.	The CA MUST provide a Random Value unique to the certificate
request.
2.	The Random Value MUST remain valid for use in a confirming response
for no more than 30 days from its creation. The CPS MAY specify a shorter
validity period for Random Values, in which case the CA MUST follow its CPS.

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

3.2.2.4.18 Agreed-Upon Change to Website - ACME

Confirming the Applicant's control over a FQDN by validating domain control
of the FQDN using the ACME HTTP Challenge method defined in section 8.3 of
RFC 8555. The following are additive requirements to RFC 8555.

The CA MUST receive a successful HTTP response from the request (meaning a
2xx HTTP return code must be received).

The token (as defined in RFC 855, section 8.3) MUST NOT be used for more
than 30 days from its creation. The CPS MAY specify a shorter validity
period for Random Values, in which case the CA MUST follow its CPS.

If the CA follows redirects:

1.	Redirects MUST be initiated at the HTTP protocol layer (e.g. using a
3xx status code).
2.	Redirects MUST be the result of an HTTP status code result within
the 3xx Redirection class of status codes, as defined in RFC 7231, Section
6.4.
3.	CAs MUST NOT follow more than 10 redirects.
4.	Redirects MUST be to resource URLs with either via the "http" or
"https" scheme.
5.	Redirects MUST be to resource URLs accessed via Authorized Ports.

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: 

https://github.com/cabforum/documents/.......

The procedure for approval of this ballot is as follows:

Discussion (7+ days)

Start Time: November , 2019 9:30am Eastern

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

Vote for approval (7 days)

Start Time: TBD

End Time: TBD

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20191108/eb1211db/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5701 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20191108/eb1211db/attachment-0001.p7s>