[cabf_validation] Clarifying Acceptable Status Codes for Following Redirects in methods 18 and 19

Thu Nov 5 09:53:59 MST 2020

Agreed

On Thu, Nov 5, 2020 at 10:55 AM Tim Hollebeek <tim.hollebeek at digicert.com>
wrote:

> Looks great, I think it’s time to move forward with this.
>
>
>
> -Tim
>
>
>
> *From:* Niko Carpenter <NCarpenter at securetrust.com>
> *Sent:* Wednesday, October 28, 2020 1:57 PM
> *To:* Ryan Sleevi <sleevi at google.com>
> *Cc:* Tim Hollebeek <tim.hollebeek at digicert.com>; CABforum3 <
> validation at cabforum.org>
> *Subject:* Re: [cabf_validation] Clarifying Acceptable Status Codes for
> Following Redirects in methods 18 and 19
>
>
>
> Circling back on this, I think it makes most sense to allow only 301, 302,
> 307, and 308 status codes. Given that, methods 18 and 19 would contain the
> following:
>
> If the CA follows redirects the following apply:
>
>
>
> 1.            Redirects MUST be initiated at the HTTP protocol layer (e.g.
> using a 3xx status code).
>
> 2.            Redirects MUST be the result of a 301, 302, 307, or 308 HTTP
> status code response.
>
> 3.            Redirects MUST be to resource URLs contained in the Location
> HTTP response header.
>
> 4.            Redirects MUST be to resource URLs with either the "http" or
> "https" scheme.
>
> 5.            Redirects MUST be to resource URLs accessed via Authorized
> Ports.
>
>
>
> My initial thought was to allow 300 and 303, since we’d be restricting the
> target URI to the Location header, but leaving them out seems more straight
> forward. How does this look to everyone?
>
>
>
>
> *Niko Carpenter *Software Engineer
>
>
>
> *From: *Niko Carpenter <NCarpenter at securetrust.com>
> *Date: *Monday, June 22, 2020 at 15:26
> *To: *Ryan Sleevi <sleevi at google.com>
> *Cc: *Tim Hollebeek <tim.hollebeek at digicert.com>, CABforum3 <
> validation at cabforum.org>
> *Subject: *Re: [cabf_validation] Clarifying Acceptable Status Codes for
> Following Redirects in methods 18 and 19
>
> RFC 7231, section 6.4, says that the Location header SHOULD be present for
> status codes 301, 302, and 307; RFC 7238 says the same about status code
> 308. By stating that the target URI MUST come from the Location header, we
> disallow following redirects by parsing the response body. At the same
> time, content-aware decisions are eliminated for status code 300, because
> the Location header only states the server’s preferred choice. If there is
> no preferred choice, this header will not be present, and the redirect
> cannot be followed.
>
>
>
> There is the separate issue that 300 and 303 redirects are not intended to
> represent the original resource. I’m not sure how this could be exploited
> in any way, but I can see why some might want to exclude them for this
> reason.
>
>
>
>
> *Niko Carpenter *Software Engineer
>
>
>
> *From: *Ryan Sleevi <sleevi at google.com>
> *Date: *Monday, June 22, 2020 at 13:21
> *To: *Niko Carpenter <NCarpenter at securetrust.com>
> *Cc: *Tim Hollebeek <tim.hollebeek at digicert.com>, Validation List <
> validation at cabforum.org>
> *Subject: *Re: [cabf_validation] Clarifying Acceptable Status Codes for
> Following Redirects in methods 18 and 19
>
>
>
> Right, but the issue with 300 is that it required CAs to make
> content-aware decisions about the acceptable resource to dereference, and
> that is the issue that's trying to be avoided here, because that leads to
> ambiguities again.
>
>
>
> 301, 302, 307, and 308, as the set seemed to represent the use case of
> unambiguously and explicitly indicating the URLs.
>
>
>
> On Mon, Jun 22, 2020 at 2:09 PM Niko Carpenter <NCarpenter at securetrust.com>
> wrote:
>
> *From: *Ryan Sleevi <sleevi at google.com>
> *Date: *Monday, June 22, 2020 at 12:35
> *To: *Niko Carpenter <NCarpenter at securetrust.com>
> *Cc: *Tim Hollebeek <tim.hollebeek at digicert.com>, Validation List <
> validation at cabforum.org>
> *Subject: *Re: [cabf_validation] Clarifying Acceptable Status Codes for
> Following Redirects in methods 18 and 19
>
>
>
> >> 2.         Redirects MUST be the result of a 300, 301, 302, 303, 307,
> or 308 HTTP status code response. Other status codes MUST NOT be treated as
> being equivalent to the 300 status code.
>
>
>
> > 300 was in the set we didn't want though. Was there something I was
> overlooking?
>
>
>
> > If we exclude 300, the necessity of the second clause also disappears.
> If other status codes were treated equivalent to 300, it'd fall out as not
> permitted.
>
>
>
> I'm not married to 300 being included. The main purpose of this change is
> to enumerate the status codes from a set whose semantics we understand,
> while also preventing clients from parsing response bodies. By specifying
> that the target URI must come from the Location header, I don't see why 300
> and 303 should be excluded from this list. If the goal is to only include
> status codes that explicitly refer to that same resource at a different
> URI, then we should exclude both 300 and 303.
>
>
>
>
>
>
> *Niko Carpenter *Software Engineer
>
>
>
> *From: *Tim Hollebeek <tim.hollebeek at digicert.com>
> *Date: *Friday, April 24, 2020 at 15:55
> *To: *Ryan Sleevi <sleevi at google.com>, Validation List <
> validation at cabforum.org>, Niko Carpenter <NCarpenter at securetrust.com>
> *Subject: *RE: [cabf_validation] Clarifying Acceptable Status Codes for
> Following Redirects in methods 18 and 19
>
>
>
> Well, this isn’t a spring cleanup thing.  Though it would be a good
> ballot.  I’d be more than happy to support getting rid of 300; getting down
> to an explicit list of codes whose semantics we have analyzed and approved
> would be even better.
>
>
>
> Thanks for starting the discussion, Niko.
>
>
>
> -Tim
>
>
>
> *From:* Validation <validation-bounces at cabforum.org> *On Behalf Of *Ryan
> Sleevi via Validation
> *Sent:* Friday, April 24, 2020 2:57 PM
> *To:* Niko Carpenter <NCarpenter at securetrust.com>
> *Cc:* CABforum3 <validation at cabforum.org>
> *Subject:* Re: [cabf_validation] Clarifying Acceptable Status Codes for
> Following Redirects in methods 18 and 19
>
>
>
> I don't disagree that it'd be a normative change, for sure. But adding the
> entire IANA registry is sort of like the "any other method", and much of
> the discussion in the validation WG was about concerns of using
> content-aware redirects (which, functionally, 300 is, as it's dependent
> upon the UA/client understanding the media type)
>
>
>
> Definitely, more feedback from more CAs would be good here. For example,
> 303 is not entirely unreasonable, but I think it'd have to be coupled with
> a more normative protocol descriptor ala ACME to evaluate.
>
>
>
> And with 308, we have to make sure the client actually understands 308
> semantics, so that it doesn't fall back into a 300-style content-aware
> parse (for which the canonical example is a meta-refresh, which folks
> understandably wanted to prohibit)
>
>
>
> On Fri, Apr 24, 2020 at 2:50 PM Niko Carpenter <NCarpenter at securetrust.com>
> wrote:
>
> I’m not opposed to restricting redirects to the 301, 302, 307, and 308
> status codes. However, doing so would be a normative change, since 300 and
> 303 are not currently disallowed. Some Cas might already be following them,
> if they are relying on an HTTP client library to handle redirects in the
> manner described in RFC 7231, Section 6.4.
>
>
>
>
> *Niko Carpenter *Software Engineer
>
>
>
> *From: *Ryan Sleevi <sleevi at google.com>
> *Date: *Friday, April 24, 2020 at 12:10
> *To: *Niko Carpenter <NCarpenter at securetrust.com>, Validation List <
> validation at cabforum.org>
> *Subject: *Re: [cabf_validation] Clarifying Acceptable Status Codes for
> Following Redirects in methods 18 and 19
>
>
>
> Right, that's why I proposed 301, 302, 307, and 308. The motivation for
> that is basically covered in RFC 7538 Section 1, and what you reach when
> you go through 7231: 305 / 306 are retired, and 300 requires parsing the
> body to semantically extract which choice.
>
>
>
> On Fri, Apr 24, 2020 at 12:53 PM Niko Carpenter via Validation <
> validation at cabforum.org> wrote:
>
> While I don’t think it’s worth calling out specifically in the BRs, CAs
> definitely should not be parsing response bodies to discern redirect URLs.
>
>
>
>
> *Niko Carpenter *Software Engineer
>
>
>
> *From: *Ryan Sleevi <sleevi at google.com>
> *Date: *Friday, April 24, 2020 at 10:49
> *To: *Niko Carpenter <NCarpenter at securetrust.com>
> *Subject: *Re: [cabf_validation] Clarifying Acceptable Status Codes for
> Following Redirects in methods 18 and 19
>
>
>
> How do you propose CAs handle 300?
>
>
>
> On Fri, Apr 24, 2020 at 11:44 AM Niko Carpenter <
> NCarpenter at securetrust.com> wrote:
>
> I think it would be best to reference the IANA registry, so that we don’t
> need to draft a new ballot if a new status code is created. I propose
> replacing the following
>
>
>
> > Redirects MUST be the result of an HTTP status code result within the
> 3xx Redirection class of status codes, as defined in RFC 7231, Section 6.4.
>
>
>
> With
>
>
>
> > Redirects MUST be the result of an HTTP status code result within the
> 3xx Redirection class of status codes, as registered in the IANA HTTP
> Status Code Registry.
>
>
>
>
>
>
> *Niko Carpenter *Software Engineer
>
>
>
> *From: *Ryan Sleevi <sleevi at google.com>
> *Date: *Thursday, April 23, 2020 at 12:02
> *To: *Niko Carpenter <NCarpenter at securetrust.com>, Validation List <
> validation at cabforum.org>
> *Subject: *Re: [cabf_validation] Clarifying Acceptable Status Codes for
> Following Redirects in methods 18 and 19
>
>
>
> To clarify: The "intention" aspect is because the status codes in 6.4 are
> used to establish a new IANA registry (in Section 8.2 of RFC 7231), which
> RFC 7238, Section 6 then updates.
>
>
>
> Did you mean to reference https://tools.ietf.org/html/rfc7538
> <https://scanmail.trustwave.com/?c=4062&d=o_bw3soodwo9BhdUDQsT8jtYKUiaIji31aulNlaWtg&s=5&u=https%3a%2f%2ftools%2eietf%2eorg%2fhtml%2frfc7538> though?
> That's updated (in both the IANA registry and in the IETF) as being the
> standards-track version of 308.
>
>
>
> Are you thinking it's better to clarify that 301, 302, 307, and 308 are
> permitted, or to reference the IANA registry so that 300 and 303 are also
> permitted?
>
>
>
> On Thu, Apr 23, 2020 at 12:45 PM Niko Carpenter via Validation <
> validation at cabforum.org> wrote:
>
> Methods 3.3.2.4.18 and 3.2.2.4.19, added in ballot SC25, say "Redirects
> MUST be the result of an HTTP status code result within the 3xx Redirection
> class of status codes, as defined in RFC 7231, Section 6.4." While I
> believe the intention was that following a 308 redirect should be
> acceptable, RFC 7231 does not define it.  Instead, it mentions, in section
> 6.4.7, that it is defined in RFC 7238. I think we should clarify that
> following a 308 redirect is acceptable in a new ballot, or the spring
> cleanup ballot.
>
>
>
> *Niko Carpenter*
>
> This transmission may contain information that is privileged,
> confidential, and/or exempt from disclosure under applicable law. If you
> are not the intended recipient, you are hereby notified that any
> disclosure, copying, distribution, or use of the information contained
> herein (including any reliance thereon) is STRICTLY PROHIBITED. If you
> received this transmission in error, please immediately contact the sender
> and destroy the material in its entirety, whether in electronic or hard
> copy format.
>
> _______________________________________________
> Validation mailing list
> Validation at cabforum.org
> https://cabforum.org/mailman/listinfo/validation
> <https://scanmail.trustwave.com/?c=4062&d=o_bw3soodwo9BhdUDQsT8jtYKUiaIji31fj2aQXB4g&s=5&u=https%3a%2f%2fcabforum%2eorg%2fmailman%2flistinfo%2fvalidation>
>
> This transmission may contain information that is privileged,
> confidential, and/or exempt from disclosure under applicable law. If you
> are not the intended recipient, you are hereby notified that any
> disclosure, copying, distribution, or use of the information contained
> herein (including any reliance thereon) is STRICTLY PROHIBITED. If you
> received this transmission in error, please immediately contact the sender
> and destroy the material in its entirety, whether in electronic or hard
> copy format.
>
> _______________________________________________
> Validation mailing list
> Validation at cabforum.org
> https://cabforum.org/mailman/listinfo/validation
> <https://scanmail.trustwave.com/?c=4062&d=o_bw3soodwo9BhdUDQsT8jtYKUiaIji31fj2aQXB4g&s=5&u=https%3a%2f%2fcabforum%2eorg%2fmailman%2flistinfo%2fvalidation>
>
> This transmission may contain information that is privileged,
> confidential, and/or exempt from disclosure under applicable law. If you
> are not the intended recipient, you are hereby notified that any
> disclosure, copying, distribution, or use of the information contained
> herein (including any reliance thereon) is STRICTLY PROHIBITED. If you
> received this transmission in error, please immediately contact the sender
> and destroy the material in its entirety, whether in electronic or hard
> copy format.
>
> This transmission may contain information that is privileged,
> confidential, and/or exempt from disclosure under applicable law. If you
> are not the intended recipient, you are hereby notified that any
> disclosure, copying, distribution, or use of the information contained
> herein (including any reliance thereon) is STRICTLY PROHIBITED. If you
> received this transmission in error, please immediately contact the sender
> and destroy the material in its entirety, whether in electronic or hard
> copy format.
>
> This transmission may contain information that is privileged,
> confidential, and/or exempt from disclosure under applicable law. If you
> are not the intended recipient, you are hereby notified that any
> disclosure, copying, distribution, or use of the information contained
> herein (including any reliance thereon) is STRICTLY PROHIBITED. If you
> received this transmission in error, please immediately contact the sender
> and destroy the material in its entirety, whether in electronic or hard
> copy format.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20201105/8aa7f5d8/attachment-0001.html>