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

Mon Dec 23 10:41:07 MST 2019

Hello Validation WG,

Thank you Doug for putting this ballot together. This ballot will significantly improve the security properties of HTTP-based domain validation.

I have a concern about the requirement limiting the number of redirects to 10. I could not find any background information on where this requirement came from, and I’m unable to come up with rationale for why this is needed to improve the security properties of the method. If we assume that each redirection is an explicit delegation of authorization, then I don’t see how having 10 such delegations is acceptable but 11 (or more) is not.

If the purpose is to provide guidance to CAs on how to prevent DoS attacks (by following an infinite number of redirects), then I don’t think we need to explicitly mandate a limit, as there are a whole host of other ways to DoS a CA, so this is an incomplete mitigation. CAs need to have more comprehensive DoS countermeasures in place regardless of the requirement.

Unless I’m missing something, I think we should strike that requirement from the ballot.

Thanks,

Corey Bonnell 
Software Architect

 <http://www.securetrust.com/> www.securetrust.com

 <https://securetrust.com/resources/library/documents/2019-global-compliance-report/> 2019 Global Compliance Intelligence Report

From: Validation <validation-bounces at cabforum.org> On Behalf Of Doug Beattie via Validation
Sent: Thursday, December 19, 2019 10:37 AM
To: CA/Browser Forum Validation WG List <validation at cabforum.org>
Subject: Re: [cabf_validation] Pre-Ballot discussion on SC25: Define New HTTP Domain Validation Methods

This is where this ballot currently stands.  Are there any comments or can we proceed with this?

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: Update to CA/B 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

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.

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

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://scanmail.trustwave.com/?c=4062&d=mZn73RJpZxKmoPwx6k-OGTuh-bUq0LoEQ1FYrf7sYA&s=5&u=https%3a%2f%2fgithub%2ecom%2fcabforum%2fdocuments%2f> 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/20191223/a16bafbd/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 10027 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20191223/a16bafbd/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4947 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20191223/a16bafbd/attachment-0001.p7s>