[Servercert-wg] Discussion Period Begins on Ballot SC43 Version 2: Clarify Acceptable Status Codes

Thu Apr 1 17:46:37 UTC 2021

Moving conversation over here to keep the voting thread just about voting.

In the voting thread, Dimitris has just noted that the "effective date" of
this change is only present in the Section 1.2.1 Revisions table:

> I just saw that the effective date of the acceptable status codes
(1-Jul-2021) was added to section 1.2.1 in the revisions table which is
incorrect. In my understanding this is not a place to add normative
requirements and besides, it only captures the effective date of the full
version of the document, not a specific requirement.

For me, this raises two questions:
1) For ballot authors, where are standards/requirements like this
documented? As someone relatively new to this community, the structure of
this ballot seemed reasonable to me: there are not currently any other
ballots in the pipeline which will be effective prior to the chosen date of
July 1, so simply noting "this document has changed, and that change will
go into effect on July 1" seems sufficient. How do we clearly document
ballot best practices and style guides?

2) For the community, why was this issue not raised during the discussion
period? The discussion period should not simply be a week-long waiting
period, with folks only reading the actual redline once voting begins. How
do we incentivize active review and discussion at the appropriate point in
the process?

These are of course interconnected -- perhaps other folks like myself did
read the ballot during the discussion period, but didn't realize there was
anything structurally wrong with it.

Thanks,
Aaron

On Tue, Mar 30, 2021 at 1:32 PM Ryan Sleevi via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> The semantics of 303 indicate that the new resource (referred to via the
> Location field) is not necessarily the same as the requested resource. The
> semantics/interpretation of that redirected-to-resource are left up to the
> user and user agent, while the goal with this was to ensure unambiguous
> semantics.
>
> From RFC 7231, Section 6.4.4 (Emphasis added)
>    The 303 (See Other) status code indicates that the server is
>    redirecting the user agent to a different resource, as indicated by a
>    URI in the Location header field, which is intended to provide an
>    indirect response to the original request.  A user agent can perform
>    a retrieval request targeting that URI (a GET or HEAD request if
>    using HTTP), which might also be redirected, and present the eventual
>    result as an answer to the original request.
>
> *Note that the new URI   in the Location header field is not considered
> equivalent to the   effective request URI.*
>
> On Tue, Mar 30, 2021 at 4:12 PM Bruce Morton via Servercert-wg <
> servercert-wg at cabforum.org> wrote:
>
>> Hi Niko,
>>
>>
>>
>> Our team believes that a single 303 redirect from http to https scheme
>> for the same fqdn should be acceptable. Is there a reason why 303 is not
>> allowed?
>>
>>
>>
>> Thanks, Bruce.
>>
>>
>>
>> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org> *On Behalf Of
>> *Niko Carpenter via Servercert-wg
>> *Sent:* Thursday, March 25, 2021 11:51 AM
>> *To:* CA/B Forum Server Certificate WG Public Discussion List <
>> servercert-wg at cabforum.org>
>> *Subject:* [EXTERNAL] [Servercert-wg] Discussion Period Begins on Ballot
>> SC43 Version 2: Clarify Acceptable Status Codes
>>
>>
>>
>> WARNING: This email originated outside of Entrust.
>> DO NOT CLICK links or attachments unless you trust the sender and know
>> the content is safe.
>> ------------------------------
>>
>> This begins the discussion period for ballot SC43 version 2: Clarify
>> Acceptable Status Codes. An effective date of July 1, 2021 was added in
>> this version.
>>
>>
>>
>> Purpose of Ballot:
>>
>>
>>
>> This ballot clarifies the allowed HTTP status codes used for following
>> redirects in domain validation methods 18 and 19, and specifies that the
>> target URI must come from the Location response header.
>>
>> In Section 3.2.2.4.18 and 3.2.2.4.19, it replaces
>>
>> "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 the following:
>>
>>
>>
>>   * "Redirects MUST be the result of a 301, 302, 307, or 308 HTTP status
>> code response."
>>
>>   * "Redirects MUST be to resource URLs contained in the Location HTTP
>> response header."
>>
>>
>>
>> The following motion has been proposed by Niko Carpenter of SecureTrust
>> and endorsed by Corey Bonnell of DigiCert and Ryan Sleevi of Google.
>>
>>
>>
>> --MOTION BEGINS--
>>
>>
>>
>> This ballot modifies the “Baseline Requirements for the Issuance and
>> Management of Publicly-Trusted Certificates” as defined in the following
>> redline, based on Version 1.7.3:
>>
>>
>>
>>
>> https://github.com/cabforum/servercert/compare/2b7720f7821764f0ea9d0d583ec5c61896a3f4cd..bd7915249a0360a28fe37b785c367d70645c7e8f
>> <https://urldefense.com/v3/__https:/github.com/cabforum/servercert/compare/2b7720f7821764f0ea9d0d583ec5c61896a3f4cd..bd7915249a0360a28fe37b785c367d70645c7e8f__;!!FJ-Y8qCqXTj2!KxKv-CtjQAa8iFbqK28UGadVW-RtBhLDI6KojNS-ZPHoM7hVPtd7V-VgBtC8mR0RQLM$>
>>
>>
>>
>> --MOTION ENDS--
>>
>>
>>
>> This ballot proposes a Final Maintenance Guideline.
>>
>>
>>
>> The procedure for approval of this ballot is as follows:
>>
>>
>>
>> Discussion (7+ days)
>>
>>
>>
>> Start Time: 11-March 2021 21:30 UTC
>>
>>
>>
>> End Time: 01-April 2021 16:00 UTC
>>
>>
>>
>> Vote for approval (7 days)
>>
>>
>>
>> Start Time: 01-April 2021 16:00 UTC
>>
>>
>>
>> End Time: 08-April 2021 16:00 UTC
>>
>>
>>
>>
>> *Niko Carpenter  *Software Engineer
>>
>> www.securetrust.com
>> <https://urldefense.com/v3/__http:/www.securetrust.com__;!!FJ-Y8qCqXTj2!KxKv-CtjQAa8iFbqK28UGadVW-RtBhLDI6KojNS-ZPHoM7hVPtd7V-VgBtC8q5c4vII$>
>>
>> *2020 Best PCI Compliance Provider Winner – Card Not Present Awards*
>>
>> 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.
>> _______________________________________________
>> Servercert-wg mailing list
>> Servercert-wg at cabforum.org
>> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20210401/482e5af7/attachment-0001.html>