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

Mon Jun 22 10:35:01 MST 2020

On Mon, Jun 22, 2020 at 1:26 PM Niko Carpenter <NCarpenter at securetrust.com>
wrote:

> I made some changes to methods 18 and 19 regarding following redirects,
> and wanted to get everyone’s thoughts before putting them into a ballot.
>
>
>
> Here is the current text:
>
> > 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 an HTTP status code result
> within the 3xx Redirection class of status codes, as defined in RFC 7231,
> Section 6.4.
>
> > 3.         Redirects MUST be to resource URLs with either via the "http"
> or "https" scheme.
>
> > 4.         Redirects MUST be to resource URLs accessed via Authorized
> Ports.
>
>
>
> This is what the text will change to:
>
> > 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 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.

> > 3.         Redirects MUST be to resource URLs contained in the Location
> HTTP response header.
>
> > 4.         Redirects MUST be to resource URLs with either via the "http"
> or "https" scheme.
>
> > 5.         Redirects MUST be to resource URLs accessed via Authorized
> Ports.
>
>
>
>
> *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=v9Kj3rFGzhhZjrE4nOzolYLzrX5oaHx5624fC9rS3A&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=v9Kj3rFGzhhZjrE4nOzolYLzrX5oaHx56z1MVImFiA&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=v9Kj3rFGzhhZjrE4nOzolYLzrX5oaHx56z1MVImFiA&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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20200622/1ce403c9/attachment-0001.html>