Re: [Acme] Alexey Melnikov's No Objection on draft-ietf-acme-acme-14: (with COMMENT)

[Richard Barnes <[e-mail]>]

I noticed that we already had some text in the security considerations
about redirects, so I reverted to SHOULD and added a forward pointer.

> More limited forms of delegation can also lead to an unintended
> party gaining the ability to successfully complete a validation
> transaction. For example, suppose an ACME server follows HTTP
> redirects in HTTP validation and a website operator provisions a
> catch-all redirect rule that redirects requests for unknown
> resources to a different domain. Then the target of the redirect
> could use that to get a certificate through HTTP validation since
> the validation path will not be known to the primary server.

https://github.com/ietf-wg-acme/acme/pull/442/files#diff-8430e2aa241beb4ac49b252db20d4ee8R2492

Alexey: Can you live with this solution?  There is some residual interop
risk, but (1) that's kind of unavoidable given the uncertainty here, and
(2) redirects are an easy-ish thing to debug and adapt if there's a
mismatch.  And at least the reasoning is pretty well documented now.

--Richard

On Wed, Aug 29, 2018 at 12:55 PM Salz, Rich <[e-mail]> wrote:

> I read the link you posted, thanks.
>
>
>
> As long as we’re not breaking the HTTP spec, I agree that SHOULD seems to
> get the most interop.  As long as we’re getting signed reponses back, I
> don’t think it matters much where the redirect sends you.
>
>
>