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 <rs...@akamai.com> 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. > > >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
