<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Apple Color Emoji";
panose-1:0 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Cambria;
panose-1:2 4 5 3 5 4 6 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal>Looks great, I think it’s time to move forward with this.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>-Tim<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> Niko Carpenter <NCarpenter@securetrust.com> <br><b>Sent:</b> Wednesday, October 28, 2020 1:57 PM<br><b>To:</b> Ryan Sleevi <sleevi@google.com><br><b>Cc:</b> Tim Hollebeek <tim.hollebeek@digicert.com>; CABforum3 <validation@cabforum.org><br><b>Subject:</b> Re: [cabf_validation] Clarifying Acceptable Status Codes for Following Redirects in methods 18 and 19<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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:<o:p></o:p></p><p class=MsoNormal>If the CA follows redirects the following apply:<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>1. Redirects MUST be initiated at the HTTP protocol layer (e.g. using a 3xx status code).<o:p></o:p></p><p class=MsoNormal>2. Redirects MUST be the result of a 301, 302, 307, or 308 HTTP status code response.<o:p></o:p></p><p class=MsoNormal>3. Redirects MUST be to resource URLs contained in the Location HTTP response header.<o:p></o:p></p><p class=MsoNormal>4. Redirects MUST be to resource URLs with either the "http" or "https" scheme.<o:p></o:p></p><p class=MsoNormal>5. Redirects MUST be to resource URLs accessed via Authorized Ports.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><b><span style='font-size:12.0pt;font-family:"Arial",sans-serif;color:#008FC5'>Niko Carpenter <br></span></b><span style='font-size:10.5pt;font-family:"Arial",sans-serif;color:#59595B'>Software Engineer</span><o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='margin-bottom:12.0pt'><b><span style='font-size:12.0pt;color:black'>From: </span></b><span style='font-size:12.0pt;color:black'>Niko Carpenter <<a href="mailto:NCarpenter@securetrust.com">NCarpenter@securetrust.com</a>><br><b>Date: </b>Monday, June 22, 2020 at 15:26<br><b>To: </b>Ryan Sleevi <<a href="mailto:sleevi@google.com">sleevi@google.com</a>><br><b>Cc: </b>Tim Hollebeek <<a href="mailto:tim.hollebeek@digicert.com">tim.hollebeek@digicert.com</a>>, CABforum3 <<a href="mailto:validation@cabforum.org">validation@cabforum.org</a>><br><b>Subject: </b>Re: [cabf_validation] Clarifying Acceptable Status Codes for Following Redirects in methods 18 and 19<o:p></o:p></span></p></div><p class=MsoNormal><a name="_Hlk20486622">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.<o:p></o:p></a></p><p class=MsoNormal><span style='mso-bookmark:_Hlk20486622'> <o:p></o:p></span></p><p class=MsoNormal><span style='mso-bookmark:_Hlk20486622'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='mso-bookmark:_Hlk20486622'> <o:p></o:p></span></p><p class=MsoNormal><span style='mso-bookmark:_Hlk20486622'><b><span style='font-size:12.0pt;font-family:"Arial",sans-serif;color:#008FC5'>Niko Carpenter <br></span></b></span><span style='mso-bookmark:_Hlk20486622'></span><span style='font-size:10.5pt;font-family:"Arial",sans-serif;color:#59595B'>Software Engineer</span><o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:12.0pt;color:black'>From: </span></b><span style='font-size:12.0pt;color:black'>Ryan Sleevi <<a href="mailto:sleevi@google.com">sleevi@google.com</a>><br><b>Date: </b>Monday, June 22, 2020 at 13:21<br><b>To: </b>Niko Carpenter <<a href="mailto:NCarpenter@securetrust.com">NCarpenter@securetrust.com</a>><br><b>Cc: </b>Tim Hollebeek <<a href="mailto:tim.hollebeek@digicert.com">tim.hollebeek@digicert.com</a>>, Validation List <<a href="mailto:validation@cabforum.org">validation@cabforum.org</a>><br><b>Subject: </b>Re: [cabf_validation] Clarifying Acceptable Status Codes for Following Redirects in methods 18 and 19</span><o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><div><p class=MsoNormal>301, 302, 307, and 308, as the set seemed to represent the use case of unambiguously and explicitly indicating the URLs.<o:p></o:p></p></div><p class=MsoNormal> <o:p></o:p></p><div><div><p class=MsoNormal>On Mon, Jun 22, 2020 at 2:09 PM Niko Carpenter <<a href="mailto:NCarpenter@securetrust.com">NCarpenter@securetrust.com</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><div><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span style='font-size:12.0pt;color:black'>From: </span></b><span style='font-size:12.0pt;color:black'>Ryan Sleevi <<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>><br><b>Date: </b>Monday, June 22, 2020 at 12:35<br><b>To: </b>Niko Carpenter <<a href="mailto:NCarpenter@securetrust.com" target="_blank">NCarpenter@securetrust.com</a>><br><b>Cc: </b>Tim Hollebeek <<a href="mailto:tim.hollebeek@digicert.com" target="_blank">tim.hollebeek@digicert.com</a>>, Validation List <<a href="mailto:validation@cabforum.org" target="_blank">validation@cabforum.org</a>><br><b>Subject: </b>Re: [cabf_validation] Clarifying Acceptable Status Codes for Following Redirects in methods 18 and 19</span><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>>> 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.<o:p></o:p></p></div></div></blockquote><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>> 300 was in the set we didn't want though. Was there something I was overlooking?<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>> 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.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.5pt;font-family:"Apple Color Emoji",serif'>I'm not married to 300 being included. The main purpose of this change is to enumerate the status codes from a set whose s</span><span style='font-size:10.5pt;font-family:"Cambria",serif'>e</span><span style='font-size:10.5pt;font-family:"Apple Color Emoji",serif'>mantics 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.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt;margin-left:.5in;text-indent:.5in;line-height:14.0pt'><b><span style='font-size:12.0pt;font-family:"Arial",sans-serif;color:#008FC5'>Niko Carpenter <br></span></b><span style='font-size:10.5pt;font-family:"Arial",sans-serif;color:#59595B'>Software Engineer</span><o:p></o:p></p></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span style='font-size:12.0pt;color:black'>From: </span></b><span style='font-size:12.0pt;color:black'>Tim Hollebeek <<a href="mailto:tim.hollebeek@digicert.com" target="_blank">tim.hollebeek@digicert.com</a>><br><b>Date: </b>Friday, April 24, 2020 at 15:55<br><b>To: </b>Ryan Sleevi <<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>>, Validation List <<a href="mailto:validation@cabforum.org" target="_blank">validation@cabforum.org</a>>, Niko Carpenter <<a href="mailto:NCarpenter@securetrust.com" target="_blank">NCarpenter@securetrust.com</a>><br><b>Subject: </b>RE: [cabf_validation] Clarifying Acceptable Status Codes for Following Redirects in methods 18 and 19</span><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Thanks for starting the discussion, Niko.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>-Tim<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b>From:</b> Validation <<a href="mailto:validation-bounces@cabforum.org" target="_blank">validation-bounces@cabforum.org</a>> <b>On Behalf Of </b>Ryan Sleevi via Validation<br><b>Sent:</b> Friday, April 24, 2020 2:57 PM<br><b>To:</b> Niko Carpenter <<a href="mailto:NCarpenter@securetrust.com" target="_blank">NCarpenter@securetrust.com</a>><br><b>Cc:</b> CABforum3 <<a href="mailto:validation@cabforum.org" target="_blank">validation@cabforum.org</a>><br><b>Subject:</b> Re: [cabf_validation] Clarifying Acceptable Status Codes for Following Redirects in methods 18 and 19<o:p></o:p></p></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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)<o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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)<o:p></o:p></p></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Fri, Apr 24, 2020 at 2:50 PM Niko Carpenter <<a href="mailto:NCarpenter@securetrust.com" target="_blank">NCarpenter@securetrust.com</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><a name="m_873828918156317444_m_55218076836111286">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. </a><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt;margin-left:.5in;text-indent:.5in;line-height:14.0pt'><b><span style='font-size:12.0pt;font-family:"Arial",sans-serif;color:#008FC5'>Niko Carpenter <br></span></b><span style='font-size:10.5pt;font-family:"Arial",sans-serif;color:#59595B'>Software Engineer</span><o:p></o:p></p></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span style='font-size:12.0pt;color:black'>From: </span></b><span style='font-size:12.0pt;color:black'>Ryan Sleevi <</span><a href="mailto:sleevi@google.com" target="_blank"><span style='font-size:12.0pt'>sleevi@google.com</span></a><span style='font-size:12.0pt;color:black'>><br><b>Date: </b>Friday, April 24, 2020 at 12:10<br><b>To: </b>Niko Carpenter <</span><a href="mailto:NCarpenter@securetrust.com" target="_blank"><span style='font-size:12.0pt'>NCarpenter@securetrust.com</span></a><span style='font-size:12.0pt;color:black'>>, Validation List <</span><a href="mailto:validation@cabforum.org" target="_blank"><span style='font-size:12.0pt'>validation@cabforum.org</span></a><span style='font-size:12.0pt;color:black'>><br><b>Subject: </b>Re: [cabf_validation] Clarifying Acceptable Status Codes for Following Redirects in methods 18 and 19</span><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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.<o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Fri, Apr 24, 2020 at 12:53 PM Niko Carpenter via Validation <<a href="mailto:validation@cabforum.org" target="_blank">validation@cabforum.org</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt;margin-left:.5in;line-height:14.0pt'><b><span style='font-size:12.0pt;font-family:"Arial",sans-serif;color:#008FC5'>Niko Carpenter <br></span></b><span style='font-size:10.5pt;font-family:"Arial",sans-serif;color:#59595B'>Software Engineer </span><o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span style='font-size:12.0pt;color:black'>From: </span></b><span style='font-size:12.0pt;color:black'>Ryan Sleevi <</span><a href="mailto:sleevi@google.com" target="_blank"><span style='font-size:12.0pt'>sleevi@google.com</span></a><span style='font-size:12.0pt;color:black'>><br><b>Date: </b>Friday, April 24, 2020 at 10:49<br><b>To: </b>Niko Carpenter <</span><a href="mailto:NCarpenter@securetrust.com" target="_blank"><span style='font-size:12.0pt'>NCarpenter@securetrust.com</span></a><span style='font-size:12.0pt;color:black'>><br><b>Subject: </b>Re: [cabf_validation] Clarifying Acceptable Status Codes for Following Redirects in methods 18 and 19</span><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>How do you propose CAs handle 300?<o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Fri, Apr 24, 2020 at 11:44 AM Niko Carpenter <<a href="mailto:NCarpenter@securetrust.com" target="_blank">NCarpenter@securetrust.com</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>> 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.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>With<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>> 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.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt;margin-left:.5in;line-height:14.0pt'><b><span style='font-size:12.0pt;font-family:"Arial",sans-serif;color:#008FC5'>Niko Carpenter <br></span></b><span style='font-size:10.5pt;font-family:"Arial",sans-serif;color:#59595B'>Software Engineer </span><o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span style='font-size:12.0pt;color:black'>From: </span></b><span style='font-size:12.0pt;color:black'>Ryan Sleevi <</span><a href="mailto:sleevi@google.com" target="_blank"><span style='font-size:12.0pt'>sleevi@google.com</span></a><span style='font-size:12.0pt;color:black'>><br><b>Date: </b>Thursday, April 23, 2020 at 12:02<br><b>To: </b>Niko Carpenter <</span><a href="mailto:NCarpenter@securetrust.com" target="_blank"><span style='font-size:12.0pt'>NCarpenter@securetrust.com</span></a><span style='font-size:12.0pt;color:black'>>, Validation List <</span><a href="mailto:validation@cabforum.org" target="_blank"><span style='font-size:12.0pt'>validation@cabforum.org</span></a><span style='font-size:12.0pt;color:black'>><br><b>Subject: </b>Re: [cabf_validation] Clarifying Acceptable Status Codes for Following Redirects in methods 18 and 19</span><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Did you mean to reference <a href="https://scanmail.trustwave.com/?c=4062&d=o_bw3soodwo9BhdUDQsT8jtYKUiaIji31aulNlaWtg&s=5&u=https%3a%2f%2ftools%2eietf%2eorg%2fhtml%2frfc7538" target="_blank">https://tools.ietf.org/html/rfc7538</a> though? That's updated (in both the IANA registry and in the IETF) as being the standards-track version of 308.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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? <o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Thu, Apr 23, 2020 at 12:45 PM Niko Carpenter via Validation <<a href="mailto:validation@cabforum.org" target="_blank">validation@cabforum.org</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:7.0pt;margin-left:.5in;line-height:14.0pt'><b><span style='font-family:"Arial",sans-serif;color:#008FC5'>Niko Carpenter</span></b><o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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. <o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>_______________________________________________<br>Validation mailing list<br><a href="mailto:Validation@cabforum.org" target="_blank">Validation@cabforum.org</a><br><a href="https://scanmail.trustwave.com/?c=4062&d=o_bw3soodwo9BhdUDQsT8jtYKUiaIji31fj2aQXB4g&s=5&u=https%3a%2f%2fcabforum%2eorg%2fmailman%2flistinfo%2fvalidation" target="_blank">https://cabforum.org/mailman/listinfo/validation</a><o:p></o:p></p></blockquote></div></div></div></div></blockquote></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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. <o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>_______________________________________________<br>Validation mailing list<br><a href="mailto:Validation@cabforum.org" target="_blank">Validation@cabforum.org</a><br><a href="https://scanmail.trustwave.com/?c=4062&d=o_bw3soodwo9BhdUDQsT8jtYKUiaIji31fj2aQXB4g&s=5&u=https%3a%2f%2fcabforum%2eorg%2fmailman%2flistinfo%2fvalidation" target="_blank">https://cabforum.org/mailman/listinfo/validation</a><o:p></o:p></p></blockquote></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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. <o:p></o:p></p></div></blockquote></div></div></div></div></blockquote></div></div></div><p class=MsoNormal>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. <o:p></o:p></p></div></blockquote></div></div><p class=MsoNormal>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. <o:p></o:p></p></div></div></body></html>