[cabf_validation] Proposed replacement for Method 6

Fri Jul 26 09:53:25 MST 2019

I’ve updated this initial draft (attached) to address the 2 points below (return codes and number of redirects).

Are there any other comments, or should I proceed with writing this up in the form of a ballot?  Are there any endorsers?

Doug

From: Doug Beattie 
Sent: Friday, July 19, 2019 10:32 AM
To: Ryan Sleevi <sleevi at google.com>; CA/Browser Forum Validation WG List <validation at cabforum.org>
Cc: Jacob Hoffman-Andrews <jsha at letsencrypt.org>
Subject: RE: [cabf_validation] Proposed replacement for Method 6

Ryan,

I have no concerns from a CA point of view and just took what was in the Validation Summit google doc and used that.  I might have been the one that entered that value because we currently support just one, but I have no issues with the method specifying more.

Are there any other items I should address before sending out an update and asking for endorsers?  The Validation Summit document had a few other items, and perhaps the most important is to determine if there are any security issues we want to address for those hosting companies that use shared IP addresses.

We didn’t ever get into details about the use of query strings on the security or on Cache-Control.

From: Ryan Sleevi <sleevi at google.com> 
Sent: Friday, July 19, 2019 9:47 AM
To: Doug Beattie <doug.beattie at globalsign.com>; CA/Browser Forum Validation WG List <validation at cabforum.org>
Cc: Jacob Hoffman-Andrews <jsha at letsencrypt.org>
Subject: Re: [cabf_validation] Proposed replacement for Method 6

Doug,

I'm not sure that there's a security reason to bound the number of redirects - just a question of how much processing is desired. The same is true, for example, when retrieving DNS records (which may go through multiple layers of CNAMEs).

Was there a specific concern you had? I wasn't sure if it was the processing overhead for CAs, which they can always reduce via their CP/CPS (although preferably, we'd look at minimum # of supported redirects to provide Applicants consistency across CAs), or if there was a security concern you had with respect to redirects.

On Fri, Jul 19, 2019 at 6:18 AM Doug Beattie via Validation <validation at cabforum.org <mailto:validation at cabforum.org> > wrote:

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 <mailto:jsha at letsencrypt.org> > 
Sent: Thursday, July 18, 2019 3:57 PM
To: Doug Beattie <doug.beattie at globalsign.com <mailto:doug.beattie at globalsign.com> >; CA/Browser Forum Validation WG List <validation at cabforum.org <mailto: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

_______________________________________________
Validation mailing list
Validation at cabforum.org <mailto:Validation at cabforum.org> 
https://cabforum.org/mailman/listinfo/validation

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20190726/077b5fa5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Replacement Method 6.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 17600 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20190726/077b5fa5/attachment-0001.docx>
-------------- 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/20190726/077b5fa5/attachment-0001.p7s>