On Sun, Apr 16, 2017 at 9:40 PM, Kirk Hall <kirk.h...@entrustdatacard.com> wrote:
> Eric, look again at the rule: > > > > *** All voting will take place via the Public Mail List. Votes not > submitted to the Public Mail List will not be considered valid, and will > not be counted for any purpose. > > > > In this case, Microsoft’s vote did take place “via the Public Mail List”. > It’s vote was submitted “to the Public Mail List”. > While maybe you could say it was "submitted to" the list (though I think that is questionable), it didn't take place "via" it. It took place via Kirk's inbox, which eventually then made it to the public list. > To be hyper technical, the Bylaw does not say the vote must APPEAR on the > list during the voting period (just that the vote must occur), and any > number of things can prevent a message to the Public list from being > forwarded – I have had my messages trapped or even disappear before. > If the mailing list software was screwing up, that'd be a bit different. However, this was straightforward user error on a significant vote by a long-time member. > I think it’s unfortunate that we are parsing the Bylaws so closely as this > – this has always been an informal organization, and getting hung up on > interpretations is a waste of time. > I understand and agree that it's unfortunate. I am just sharing my personal opinion as a non-voting member, but I think given all the effort that was just put into ensuring that the Bylaws describe a defensible and precise voting process, and given the clear plain language intent of the Bylaws, it's worth being a stickler and enforcing member discipline on something as fundamental as publicly attributable voting. -- Eric > > > *From:* Eric Mill [mailto:e...@konklone.com] > *Sent:* Sunday, April 16, 2017 6:17 PM > *To:* CA/Browser Forum Public Discussion List <public@cabforum.org> > *Cc:* Kirk Hall <kirk.h...@entrustdatacard.com> > > *Subject:* [EXTERNAL]Re: [cabfpub] ]RE: Ballot 194 - Effective Date of > Ballot 193 Provisions is in the VOTING period (ends April 16) > > > > I don't think Microsoft cast its vote correctly. Microsoft is aware of how > the CA/Browser Forum list works, and should have been able to cast a vote > from a subscribed member address before the deadline. I think this > obligation is especially apparent when their vote is likely to be a > tiebreaker. > > > > Peter's right that there's some greyness to the Bylaws, but I think a > plain reading of the text, and its clear intent to have votes be cast where > it is publicly attributable to the voter, supports this vote not being > validly cast. > > > > I'm sure it was a good faith error, but it would not be a good precedent > for votes to be counted which were only distributed to and reforwarded by > the Chair (or any other member). Unfortunately, since 1 browser vote is the > difference between success and failure, this probably points to needing a > revote. > > > > -- Eric > > > > On Sun, Apr 16, 2017 at 9:07 PM, Kirk Hall via Public <public@cabforum.org> > wrote: > > Ryan, it’s kind of unseemly for one browser to try to block the vote of > another browser. Google were the only Forum member to vote no on this > ballot – 20 CAs and 2 browsers voted yes. Clearly the consensus of the > members is in favor of this ballot, and technically Microsoft cast its vote > correctly, even if it was not forwarded by our server. I would suggest you > reconsider following this line. > > > > *From:* Public [mailto:public-boun...@cabforum.org] *On Behalf Of *Ryan > Sleevi via Public > *Sent:* Sunday, April 16, 2017 6:03 PM > *To:* CA/Browser Forum Public Discussion List <public@cabforum.org> > *Cc:* Ryan Sleevi <sle...@google.com> > *Subject:* [EXTERNAL]Re: [cabfpub] ]RE: Ballot 194 - Effective Date of > Ballot 193 Provisions is in the VOTING period (ends April 16) > > > > To that end, this was a concern raised nearly a year ago when discussing > what would become Ballot 174, with respect to Section 9.16.3 > > > > https://cabforum.org/pipermail/public/2016-April/007468.html and > https://cabforum.org/pipermail/public/2016-April/007480.html > > > > There is certainly precedent within the Forum that "posted" shall mean > available for access via the archives, as that can be objectively measured > and quantified. I do not believe we can reasonably argue that "posted" > shall mean sent to this address. It cannot be shown, for example, that > Microsoft did not block the posting on their end, thereby preventing proper > disclosure by preventing egress from their network. > > > > This is also not the first time in which the Chair has been the only > recipient of a message, and which the interpretation has resulted in some > concern. I will note Symantec's previous exclusions, posted only to Dean > (in his role as the previous chair), created uncertainty and ambiguity with > respect to whether they abided by the Bylaws. > > > > I would encourage you, for the avoidance of doubt and conflict, to > reconsider your position, as I do not believe it is supported by the > precedent, intent, or bylaws of the Forum. > > > > On Sun, Apr 16, 2017 at 8:57 PM, Peter Bowen via Public < > public@cabforum.org> wrote: > > Kirk, > > > > I suspect that the mailing list system rejected this email as Gordon is > not subscribed to the public mailing list. The bylaws say: "Votes not > submitted to the Public Mail List will not be considered valid, and will > not be counted for any purpose.” > > > > The bylaws do not appear to contemplate what happens if the vote is > _submitted_ to the mailing list but not accepted. In this case it was > copied to the chair, so you alone saw it. If Gordon had not explicitly > copied you, then it would not have been counted. As you were explicitly > copied, you received it. > > > > Given that the bylaws say "All voting will take place via the Public Mail > List”, and the mailing list archives allow verification of whether > the email was posted, I am leaning towards the view that this is not a > valid vote. However I can see how it is a grey area. > > > > Thanks, > > Peter > > > > > > > > On Apr 16, 2017, at 5:36 PM, Kirk Hall via Public <public@cabforum.org> > wrote: > > > > This is the vote from Microsoft. > > > > *From:* Gordon Bock [mailto:gb...@microsoft.com <gb...@microsoft.com>] > *Sent:* Thursday, April 13, 2017 8:46 AM > *To:* Kirk Hall <kirk.h...@entrustdatacard.com>; CA/Browser Forum Public > Discussion List <public@cabforum.org> > *Subject: *RE: Ballot 194 - Effective Date of Ballot 193 Provisions is in > the VOTING period (ends April 16) > > > > Microsoft votes ‘Yes’. > > > > Thanks, > > -Gordon > > > > *From:* Kirk Hall [mailto:kirk.h...@entrustdatacard.com > <kirk.h...@entrustdatacard.com>] > *Sent:* Sunday, April 9, 2017 4:30 PM > *To:* CA/Browser Forum Public Discussion List <public@cabforum.org> > *Subject:* Ballot 194 - Effective Date of Ballot 193 Provisions is in the > VOTING period (ends April 16) > > > > Reminder: Ballot 194 - Effective Date of Ballot 193 Provisions is in the > voting period (ends April 16) > > > > *Ballot 194 – Effective Date of Ballot 193 Provisions* > > > > *Purpose of Ballot:* Recent Ballot 193 reduced the maximum period for > certificates and for reuse of vetting data for DV and OV certificates from > 39 months to 825 days. The effective date for reducing the maximum > validity period of certificates was specified as March 1, 2018, but no > effective date was specified for when the reduction of the maximum period > for reuse of vetting data becomes effective. > > > > It was the intention of the authors of Ballot 193 that the effective date > for reducing the maximum period for reuse of vetting data under BR 4.2.1 > would also be March 1, 2018. This ballot is intended to clarify that > intention. The ballot also makes these changes retroactive to the > effective date of Ballot 193 so there is no gap period. > > > > Ballot 193 is in the Review Period (which will end on April 22, 2017), and > has not yet taken effect. Bylaw 2.3 states that Ballots should include a > “redline or comparison showing the set of changes from the Final Guideline > section(s) intended to become a Final Maintenance Guideline” and that > “[s]uch redline or comparison shall be made against the Final Guideline > section(s) as they exist at the time a ballot is proposed”. > > > > To avoid confusion, this Ballot will show the proposed changes to BR 4.2.1 > will be presented two ways: (1) a comparison of the changes to BR 4.2.1 as > it existed before Ballot 193 (which is as BR 4.2.1 exists at this time this > ballot is proposed), and also (2) a comparison of the changes to BR 4.2.1 > as it will exist after the Review Period for Ballot 193 is completed > (assuming no Exclusion Notices are filed). > > > > The following motion has been proposed by Chris Bailey of Entrust Datacard > and endorsed by Ben Wilson of DigiCert, and Wayne Thayer of GoDaddy to > introduce new Final Maintenance Guidelines for the "Baseline Requirements > Certificate Policy for the Issuance and Management of Publicly-Trusted > Certificates" (Baseline Requirements) and the "Guidelines for the Issuance > and Management of Extended Validation Certificates" (EV Guidelines). > > > > -- MOTION BEGINS -- > > > > *Ballot Section 1* > > > > BR 4.2.1 is amended to read as follows: > > > > *[Ballot amendments shown against BR 4.2.1 as it currently exists without > the changes adopted in Ballot 193]* > > > > *BR 4.2.1. Performing Identification and Authentication Functions* > > > > The certificate request MAY include all factual information about the > Applicant to be included in the Certificate, and such additional > information as is necessary for the CA to obtain from the Applicant in > order to comply with these Requirements and the CA’s Certificate Policy > and/or Certification Practice Statement. In cases where the certificate > request does not contain all the necessary information about the Applicant, > the CA SHALL obtain the remaining information from the Applicant or, having > obtained it from a reliable, independent, third‐party data source, > confirm it with the Applicant. The CA SHALL establish and follow a > documented procedure for verifying all data requested for inclusion in the > Certificate by the Applicant. > > > > Applicant information MUST include, but not be limited to, at least one > Fully‐Qualified Domain Name or IP address to be included in the > Certificate’s SubjectAltName extension. > > > > Section 6.3.2 limits the validity period of Subscriber Certificates. The > CA MAY use the documents and data provided in Section 3.2 to verify > certificate information, provided that*:* *the CA obtained the data or > document from a source specified under Section 3.2 no more than > thirty**‐**nine > (39) months prior to issuing the Certificate.* > > > > *(1) Prior to March 1, 2018, the CA obtained the data or document from a > source specified under Section 3.2 no more than 39 months prior to issuing > the Certificate; and* > > > > *(2) On or after March 1, 2018, the CA obtained the data or document from > a source specified under Section 3.2 no more than 825 days prior to issuing > the Certificate. * > > > > The CA SHALL develop, maintain, and implement documented procedures that > identify and require additional verification activity for High Risk > Certificate Requests prior to the Certificate’s approval, as reasonably > necessary to ensure that such requests are properly verified under these > Requirements. > > > > If a Delegated Third Party fulfills any of the CA’s obligations under this > section, the CA SHALL verify that the process used by the Delegated Third > Party to identify and further verify High Risk Certificate Requests > provides at least the same level of assurance as the CA’s own processes. > > > > > > *[Ballot amendments shown against BR 4.2.1 as it existed after Ballot 193 > was approved]* > > > > *BR 4.2.1. Performing Identification and Authentication Functions* > > > > The certificate request MAY include all factual information about the > Applicant to be included in the Certificate, and such additional > information as is necessary for the CA to obtain from the Applicant in > order to comply with these Requirements and the CA’s Certificate Policy > and/or Certification Practice Statement. In cases where the certificate > request does not contain all the necessary information about the Applicant, > the CA SHALL obtain the remaining information from the Applicant or, having > obtained it from a reliable, independent, third‐party data source, > confirm it with the Applicant. The CA SHALL establish and follow a > documented procedure for verifying all data requested for inclusion in the > Certificate by the Applicant. > > > > Applicant information MUST include, but not be limited to, at least one > Fully‐Qualified Domain Name or IP address to be included in the > Certificate’s SubjectAltName extension. > > > > Section 6.3.2 limits the validity period of Subscriber Certificates. The > CA MAY use the documents and data provided in Section 3.2 to verify > certificate information, provided that*:* *the CA obtained the data or > document from a source specified under Section 3.2 no more than 825 > days prior to issuing the Certificate.* > > > > *(1) Prior to March 1, 2018, the CA obtained the data or document from a > source specified under Section 3.2 no more than 39 months prior to issuing > the Certificate; and* > > > > *(2) On or after March 1, 2018, the CA obtained the data or document from > a source specified under Section 3.2 no more than 825 days prior to issuing > the Certificate. * > > > > The CA SHALL develop, maintain, and implement documented procedures that > identify and require additional verification activity for High Risk > Certificate Requests prior to the Certificate’s approval, as reasonably > necessary to ensure that such requests are properly verified under these > Requirements. > > > > If a Delegated Third Party fulfills any of the CA’s obligations under this > section, the CA SHALL verify that the process used by the Delegated Third > Party to identify and further verify High Risk Certificate Requests > provides at least the same level of assurance as the CA’s own processes. > > > > *Ballot Section 2* > > > > The provisions of Ballot Section 1 will be effective retroactive to the > effective date of Ballot 193. > > > > > > *--Motion Ends--* > > > > The procedure for approval of this Final Maintenance Guideline ballot is > as follows (exact start and end times may be adjusted to comply with > applicable Bylaws and IPR Agreement): > > > > BALLOT 194 > > Status: Final Maintenance Guideline > > Start time (22:00 UTC) > > End time (22:00 UTC) > > Discussion (7 to 14 days) > > April 2, 2017 > > April 9, 2017 > > Vote for approval (7 days) > > April 9, 2017 > > April 16, 2017 > > If vote approves ballot: Review Period (Chair to send Review Notice) (30 > days). > > If Exclusion Notice(s) filed, ballot approval is rescinded and PAG to be > created. > > If no Exclusion Notices filed, ballot becomes effective at end of Review > Period. > > Upon filing of Review Notice by Chair > > 30 days after filing of Review Notice by Chair > > > > From Bylaw 2.3: If the Draft Guideline Ballot is proposing a Final > Maintenance Guideline, such ballot will include a redline or comparison > showing the set of changes from the Final Guideline section(s) intended to > become a Final Maintenance Guideline, and need not include a copy of the > full set of guidelines. Such redline or comparison shall be made against > the Final Guideline section(s) as they exist at the time a ballot is > proposed, and need not take into consideration other ballots that may be > proposed subsequently, except as provided in Bylaw Section 2.3(j). > > > > Votes must be cast by posting an on-list reply to this thread on the > Public list. A vote in favor of the motion must indicate a clear 'yes' in > the response. A vote against must indicate a clear 'no' in the response. A > vote to abstain must indicate a clear 'abstain' in the response. Unclear > responses will not be counted. The latest vote received from any > representative of a voting member before the close of the voting period > will be counted. Voting members are listed here: https://cabforum.org/mem > bers/ > > > > In order for the motion to be adopted, two thirds or more of the votes > cast by members in the CA category and greater than 50% of the votes cast > by members in the browser category must be in favor. Quorum is shown on > CA/Browser Forum wiki. Under Bylaw 2.2(g), at least the required quorum > number must participate in the ballot for the ballot to be valid, either by > voting in favor, voting against, or abstaining. > > > > _______________________________________________ > Public mailing list > Public@cabforum.org > https://cabforum.org/mailman/listinfo/public > > > > > _______________________________________________ > Public mailing list > Public@cabforum.org > https://cabforum.org/mailman/listinfo/public > > > > > _______________________________________________ > Public mailing list > Public@cabforum.org > https://cabforum.org/mailman/listinfo/public > > > > > > -- > > konklone.com | @konklone <https://twitter.com/konklone> > -- konklone.com | @konklone <https://twitter.com/konklone>
_______________________________________________ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public