[cabf_validation] Proposed replacement for Method 6

[Jacob Hoffman-Andrews]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20190718/501ef029/attachment.html>