[cabf_validation] Proposed replacement for Method 6

[Doug Beattie]

Hi Jacob,

 

There had been a long discussion about this ballot method and I just pulled the notes from that into this ballot for HTTP response codes (clearly got that wrong) and number of redirects, so this could certainly be changed.

*	If I’ll update it to say in the end you need a 2xx return code
*	10 redirects seems like a lot.  Can you tell how many redirects customers are actually using, because 10 seems like a lot.

 

Other than these 2 items, did you have some other suggestions for the ballot?  I wasn’t clear what you were getting at in your last paragraph and reference to ACME methods.

 

Thanks!

 

Doug

 

From: Jacob Hoffman-Andrews <jsha at letsencrypt.org> 
Sent: Thursday, July 18, 2019 3:57 PM
To: Doug Beattie <doug.beattie at globalsign.com>; CA/Browser Forum Validation WG List <validation at cabforum.org>
Subject: Re: [cabf_validation] Proposed replacement for Method 6

 

Hi Doug! Thanks for introducing this proposal. I'm definitely interested in narrowing the validation methods and specifying them more clearly.

 

On Thu, Jul 18, 2019 at 10:30 AM Doug Beattie via Validation <validation at cabforum.org <mailto:validation at cabforum.org> > wrote:

3.2.2.4.tbd Agreed-Upon Change to Website

Confirming the Applicant's control over the FQDN by verifying:

1.	that the Request Token or Random Value is contained in the content of a file, and 
2.	the entire Request Token or Random Value MUST NOT appear in the request used to retrieve the file, and 
3.	the CA must receive a successful HTTP response (meaning that no 2xx or 3xx response codes must be accepted).

Is 2xx a typo here? The whole 2xx range is considered "successful." And forbidding 3xx is a little confusing given the accomodation for redirects. I think the intent here is that if there are 3xx redirects, the redirects cannot themselves serve as proof - there eventually has to be a 2xx at the end of the redirect chain. Is that right?

 

The CA may follow only server-side redirects given:

*	A maximum of 1 redirect may be followed, and

Current Let's Encrypt validation policy is to follow up to 10 redirects <https://letsencrypt.org/docs/challenge-types/#http-01-challenge> . Limiting this to just 1 redirect would break some of our customers, so we'd be against it without a good security argument. What's the security justification for the limit of 1?

 

*	 
*	Redirect must be only to http or https, and
*	May be to a different Authorized Port

These seem like good additions.

 

By the way, this is reminding me that we always intended to give the ACME validation methods their own entries in this section once they were finalized, since the ACME methods are more fully-specified than the current methods. ACME is now RFC 8555 <https://tools.ietf.org/html/rfc8555> . What do you think of wrapping up that addition into this ballot? I'm happy to help draft.

Thanks,

Jacob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20190719/8eafbcc8/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/20190719/8eafbcc8/attachment-0001.p7s>