[cabf_validation] Pre-Ballot discussion on SC25: Define New HTTP Domain Validation Methods
Ryan Sleevi
sleevi at google.com
Mon Dec 23 10:54:07 MST 2019
Corey,
I think I agree regarding the limits here. That said, there's an element
that I think is useful for Subscriber/Applicants and interoperability here,
which may be useful in understanding if there's some minimum amount of
redirects that a CA MUST support. Do you think it makes sense to specify
this normatively for a floor, with a SHOULD for a ceiling regarding DoS?
CAs MUST be capable of following AT LEAST _xx_ redirects. CAs SHOULD take
steps to mitigate the possibility of redirect loops or excessive redirects
that may impair service.
On Mon, Dec 23, 2019 at 12:41 PM Corey Bonnell via Validation <
validation at cabforum.org> wrote:
> 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
>
>
>
>
> www.securetrust.com
>
>
> *2019 Global Compliance Intelligence Report*
> <https://securetrust.com/resources/library/documents/2019-global-compliance-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://github.com/cabforum/documents/.......
> <https://scanmail.trustwave.com/?c=4062&d=mZn73RJpZxKmoPwx6k-OGTuh-bUq0LoEQ1FYrf7sYA&s=5&u=https%3a%2f%2fgithub%2ecom%2fcabforum%2fdocuments%2f>
>
>
>
> 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
>
>
> _______________________________________________
> Validation mailing list
> Validation at cabforum.org
> https://cabforum.org/mailman/listinfo/validation
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20191223/3611d4a2/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/3611d4a2/attachment-0001.png>
More information about the Validation
mailing list