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

Fri Apr 24 11:50:47 MST 2020

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<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 <sleevi at google.com<mailto:sleevi at google.com>>
Date: Friday, April 24, 2020 at 10:49
To: 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

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 <sleevi at google.com<mailto:sleevi at google.com>>
Date: Thursday, April 23, 2020 at 12:02
To: Niko Carpenter <NCarpenter at securetrust.com<mailto:NCarpenter at securetrust.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

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=8p2j3j6Ke2nZbGINd-PWNTm9hcjAwzntrkbSAiPnwQ&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=8p2j3j6Ke2nZbGINd-PWNTm9hcjAwzntrhWBXXCwlQ&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<mailto:Validation at cabforum.org>
https://cabforum.org/mailman/listinfo/validation<https://scanmail.trustwave.com/?c=4062&d=8p2j3j6Ke2nZbGINd-PWNTm9hcjAwzntrhWBXXCwlQ&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://cabforum.org/pipermail/validation/attachments/20200424/b8345ca0/attachment-0001.html>