[cabfpub] ]RE: Ballot 194 - Effective Date of Ballot 193 Provisions is in the VOTING period (ends April 16)

[Eric Mill]

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 at 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-bounces at 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 at cabforum.org>
> *Cc:* Ryan Sleevi <sleevi at 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 at 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 at cabforum.org>
> wrote:
>
>
>
> This is the vote from Microsoft.
>
>
>
> *From:* Gordon Bock [mailto:gbock at microsoft.com <gbock at microsoft.com>]
> *Sent:* Thursday, April 13, 2017 8:46 AM
> *To:* Kirk Hall <Kirk.Hall at entrustdatacard.com>; CA/Browser Forum Public
> Discussion List <public at 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.Hall at entrustdatacard.com
> <Kirk.Hall at entrustdatacard.com>]
> *Sent:* Sunday, April 9, 2017 4:30 PM
> *To:* CA/Browser Forum Public Discussion List <public at 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/
> members/
>
>
>
> 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 at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>


-- 
konklone.com | @konklone <https://twitter.com/konklone>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170416/469f9c95/attachment-0003.html>