[cabf_validation] Proposed replacement for Method 6

[Ryan Sleevi]

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> 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>
> *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> 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
> https://cabforum.org/mailman/listinfo/validation
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20190719/b32f8161/attachment.html>