Yes – this is a conundrum that should be fixed. Issues with the mailing list 
could completely screw up a vote. Anyone controlling the mailing list could 
they effectively prevent voting if they decided to manage the mailing list in a 
way to prevent member messages from reaching the mailing list.

 

I don’t think the public archive should be/is controlling. None of the members 
check the archive to ensure their vote shows up on the list and the archives 
aren’t mentioned in the bylaws.

 

I’m not sure what happens in the current situation.  As Peter points, the 
bylaws say “Votes not submitted to the mailing list are not considered valid.” 
As this one was submitted to the mailing list, but rejected, it is valid?  
However, as Ryan pointed out “All votes take place via the Public Mail List”, 
which clearly did not happen. The penalty for votes that don’t take place via 
the public mailing list but are submitted to the public mailing list is not 
specified in the bylaws.   

 

What do other groups do in this circumstance? 

 

Jeremy

 

 

 

 

From: Public [mailto:[email protected]] On Behalf Of Peter Bowen via 
Public
Sent: Sunday, April 16, 2017 7:17 PM
To: CA/Browser Forum Public Discussion List <[email protected]>
Cc: Peter Bowen <[email protected]>
Subject: Re: [cabfpub] ]RE: Ballot 194 - Effective Date of Ballot 193 
Provisions is in the VOTING period (ends April 16)

 

Regardless of this outcome, I think it makes sense to clarify that only votes 
recorded in archives of the public mailing list are counted in the future.  We 
have open voting, so it is unfair to a proposition proponent or opponent if one 
side has information the other does not.  Alternatively we could look into a 
sealed vote system to avoid this in the future.

 

On Apr 16, 2017, at 6:07 PM, Kirk Hall via Public <[email protected] 
<mailto:[email protected]> > 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:[email protected]> 
mailto:[email protected]] On Behalf Of Ryan Sleevi via Public
Sent: Sunday, April 16, 2017 6:03 PM
To: CA/Browser Forum Public Discussion List < <mailto:[email protected]> 
[email protected]>
Cc: Ryan Sleevi < <mailto:[email protected]> [email protected]>
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> 
https://cabforum.org/pipermail/public/2016-April/007468.html and  
<https://cabforum.org/pipermail/public/2016-April/007480.html> 
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 < 
<mailto:[email protected]> [email protected]> 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 < 
<mailto:[email protected]> [email protected]> wrote:

 

This is the vote from Microsoft.

 

From: Gordon Bock [ <mailto:[email protected]> mailto:[email protected]] 
Sent: Thursday, April 13, 2017 8:46 AM
To: Kirk Hall < <mailto:[email protected]> 
[email protected]>; CA/Browser Forum Public Discussion List < 
<mailto:[email protected]> [email protected]>
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:[email protected]> 
mailto:[email protected]] 
Sent: Sunday, April 9, 2017 4:30 PM
To: CA/Browser Forum Public Discussion List < <mailto:[email protected]> 
[email protected]>
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/> 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
 <mailto:[email protected]> [email protected]
 <https://cabforum.org/mailman/listinfo/public> 
https://cabforum.org/mailman/listinfo/public

 


_______________________________________________
Public mailing list
 <mailto:[email protected]> [email protected]
 <https://cabforum.org/mailman/listinfo/public> 
https://cabforum.org/mailman/listinfo/public

 

_______________________________________________
Public mailing list
 <mailto:[email protected]> [email protected]
 <https://cabforum.org/mailman/listinfo/public> 
https://cabforum.org/mailman/listinfo/public

 

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public

Reply via email to