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

Mon Jun 22 11:20:43 MST 2020

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=7uvw3lpSQS5VjVw4EdW6XwQqhG1ZbO-KncWA0_WuLQ&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=7uvw3lpSQS5VjVw4EdW6XwQqhG1ZbO-KnZbTjKb5eQ&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=7uvw3lpSQS5VjVw4EdW6XwQqhG1ZbO-KnZbTjKb5eQ&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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20200622/9ecff4bb/attachment-0001.html>