Trimming recipients due to moderation.
-Tim From: Tim Hollebeek Sent: Thursday, August 30, 2018 8:12 AM To: 'Richard Barnes' <r...@ipv.sx>; Salz, Rich <rs...@akamai.com> Cc: Alexey Melnikov <aamelni...@fastmail.fm>; draft-ietf-acme-a...@ietf.org; IETF ACME <acme@ietf.org>; Daniel McCarney <c...@letsencrypt.org>; Yoav Nir <ynir.i...@gmail.com>; The IESG <i...@ietf.org>; <acme-cha...@ietf.org> <acme-cha...@ietf.org>; Alexey Melnikov <alexey.melni...@isode.com> Subject: RE: [Acme] Alexey Melnikov's No Objection on draft-ietf-acme-acme-14: (with COMMENT) For what it’s worth, there’s a discussion going on in the validation working group right now about how redirects should be handled. The most likely outcome is either pretty severe restrictions around redirects, or completely disallowing them. In the interest of openness, CAs were asked to disclose their current redirect behavior as a basis for a discussion about what the requirements should be. Two CAs have done so. Others are strongly encouraged to do so. There is no explicit text allowing them, so it could be argued that the BRs currently don’t allow following redirects. On the other hand, redirects are part of HTTP, so the argument can also be made that “retrieving a web page” can involve arbitrary redirects, including potentially things like meta refresh and javascript. The fact that such a diverse range of interpretations are possible is something we’d love to fix. In particular, non-HTTP redirects that involve parsing page content introduce a great deal of complexity and risk into the validation process, and I’d like to clarify that that definitely isn’t allowed. Redirects to a location outside of the domain being validated are viewed with particular suspicion by many, including me. Redirects within the same domain seem less problematic, and indeed useful for handling large numbers of domains. Though it’s not clear this solves a use case that is not already handled by the ability to validate and Authorization Domain Name and use it for subdomains. The main reason to allow redirects within a domain is if there is a unilateral redirect from example.com to www.example.com <http://www.example.com> , which is of course incredibly common. It seems one should be able to validate example.com using that redirect. At least one large CA supports the “no redirects at all” position. -Tim From: Acme <acme-boun...@ietf.org <mailto:acme-boun...@ietf.org> > On Behalf Of Richard Barnes Sent: Wednesday, August 29, 2018 7:10 PM To: Salz, Rich <rs...@akamai.com <mailto:rs...@akamai.com> > Cc: Alexey Melnikov <aamelni...@fastmail.fm <mailto:aamelni...@fastmail.fm> >; draft-ietf-acme-a...@ietf.org <mailto:draft-ietf-acme-a...@ietf.org> ; IETF ACME <acme@ietf.org <mailto:acme@ietf.org> >; Daniel McCarney <c...@letsencrypt.org <mailto:c...@letsencrypt.org> >; Yoav Nir <ynir.i...@gmail.com <mailto:ynir.i...@gmail.com> >; The IESG <i...@ietf.org <mailto:i...@ietf.org> >; <acme-cha...@ietf.org <mailto:acme-cha...@ietf.org> > <acme-cha...@ietf.org <mailto:acme-cha...@ietf.org> >; Alexey Melnikov <alexey.melni...@isode.com <mailto:alexey.melni...@isode.com> > Subject: Re: [Acme] Alexey Melnikov's No Objection on draft-ietf-acme-acme-14: (with COMMENT) 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 <mailto: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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
