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

Thu Nov 5 08:55:29 MST 2020

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
<mailto:NCarpenter at securetrust.com> >
Date: Monday, June 22, 2020 at 15:26
To: Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com> >
Cc: Tim Hollebeek <tim.hollebeek at digicert.com
<mailto:tim.hollebeek at digicert.com> >, CABforum3 <validation at cabforum.org
<mailto: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 <mailto:sleevi at google.com> >
Date: Monday, June 22, 2020 at 13:21
To: Niko Carpenter <NCarpenter at securetrust.com
<mailto:NCarpenter at securetrust.com> >
Cc: Tim Hollebeek <tim.hollebeek at digicert.com
<mailto:tim.hollebeek at digicert.com> >, Validation List
<validation at cabforum.org <mailto: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
<mailto:NCarpenter at securetrust.com> > wrote:

From: Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com> >
Date: Monday, June 22, 2020 at 12:35
To: Niko Carpenter <NCarpenter at securetrust.com
<mailto:NCarpenter at securetrust.com> >
Cc: Tim Hollebeek <tim.hollebeek at digicert.com
<mailto:tim.hollebeek at digicert.com> >, Validation List
<validation at cabforum.org <mailto: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
<mailto:tim.hollebeek at digicert.com> >
Date: Friday, April 24, 2020 at 15:55
To: Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com> >, Validation
List <validation at cabforum.org <mailto:validation at cabforum.org> >, Niko
Carpenter <NCarpenter at securetrust.com <mailto: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
<mailto: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
<mailto:NCarpenter at securetrust.com> >
Cc: CABforum3 <validation at cabforum.org <mailto: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
<mailto: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 < <mailto:sleevi at google.com> sleevi at google.com>
Date: Friday, April 24, 2020 at 12:10
To: Niko Carpenter < <mailto:NCarpenter at securetrust.com>
NCarpenter at securetrust.com>, Validation List <
<mailto:validation at cabforum.org> 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 <mailto: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 < <mailto:sleevi at google.com> sleevi at google.com>
Date: Friday, April 24, 2020 at 10:49
To: Niko Carpenter < <mailto:NCarpenter at securetrust.com>
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
<mailto: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 < <mailto:sleevi at google.com> sleevi at google.com>
Date: Thursday, April 23, 2020 at 12:02
To: Niko Carpenter < <mailto:NCarpenter at securetrust.com>
NCarpenter at securetrust.com>, Validation List <
<mailto:validation at cabforum.org> 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_bw3soodwo9BhdUDQsT8jtYKUiaIji31a
ulNlaWtg&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 <mailto: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 <mailto:Validation at cabforum.org> 
https://cabforum.org/mailman/listinfo/validation
<https://scanmail.trustwave.com/?c=4062&d=o_bw3soodwo9BhdUDQsT8jtYKUiaIji31f
j2aQXB4g&s=5&u=https%3a%2f%2fcabforum%2eorg%2fmailman%2flistinfo%2fvalidatio
n> 

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 <mailto:Validation at cabforum.org> 
https://cabforum.org/mailman/listinfo/validation
<https://scanmail.trustwave.com/?c=4062&d=o_bw3soodwo9BhdUDQsT8jtYKUiaIji31f
j2aQXB4g&s=5&u=https%3a%2f%2fcabforum%2eorg%2fmailman%2flistinfo%2fvalidatio
n> 

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/89678fff/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20201105/89678fff/attachment-0001.p7s>