[cabfpub] Ballot 110 - Motion to Adopt Version 1.1 of the Bylaws

Ben Wilson ben at digicert.com
Tue Jan 21 06:07:38 UTC 2014



I am still working on the revisions to  the proposed bylaws, but I’m still have trouble formulating the Forum’s approach to Invited Guests.  As the draft currently exists, no changes will be made in sections 1.1, 2.1(3), or 5.2 (although I strongly believe changes need to be made to improve these sections).  No major change is needed to section 2.2, other than to change a typo / incorrect reference that is legacy from the pre-bylaws voting rules (reference to “item 6” instead of “subparagraph (g)”), but I don’t see a problem with the minor clarifying language in that section.  Proposed Sections 3.1 and 3.2 are needed, as discussed during telephone calls and recent Face-to-Face meetings.   So, back to section 3.3, my current thought is that if could read:


“In accordance with the following notice procedure, a person may be invited to attend and/or participate as an Invited Guest during a Forum Teleconference or Forum Meeting in which such person’s expertise or participation will be of benefit to the Forum or a Forum Member:


(a)          at least five (5) days prior to the Teleconference or Meeting, the Chair will send notice to the Forum about a proposed Invited Guest;

(b)          the notice must set forth the relevance of the person’s participation and whether the Forum should waive the requirement that the Invited Guest sign the IPR Agreement, and if so, the reasons therefore; and

(c)          if no objection is made within 96 hours of such notice, the Chair may invite the person to attend as an Invited Guest.”





From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi
Sent: Friday, January 17, 2014 7:41 PM
To: Ben Wilson
Subject: Re: [cabfpub] Ballot 110 - Motion to Adopt Version 1.1 of the Bylaws




On Fri, Jan 17, 2014 at 6:26 PM, Ben Wilson <ben at digicert.com> wrote:


See my responses inline below.




From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi
Sent: Friday, January 17, 2014 5:37 PM
To: Ben Wilson
Subject: Re: [cabfpub] Ballot 110 - Motion to Adopt Version 1.1 of the Bylaws


While I realize it's not at ballot review period, a few thoughts, given the time constraints being operated in:


1) I'd prefer to not change the "Purpose of the Forum" (Section 1.1) at this time.


BTW:  That’s fine.  I just didn’t like the current wording because it was written as if we’d just finished version 1.0 of the EV Guidelines.


Yup. I'd love to see this iteratively refined, I just wouldn't want to hold up the IG aspects.



2) Section 2.1 ("authenticate digitally signed code") is still a much greater increase of scope of the work of the members. I'd prefer if we could leave that for broader discussion. While I'm aware of the "Code Signing WG" discussions, this change in definitions has the effective quality of allowing/encouraging vendors with no/limited stake in the SSL/TLS ecosystem to vote on changes to the BRs / EVGs, and vice versa. I'm sure you can recognize at it's face, that has some degree of undesirability, and effectively changes the "CA/Browser Forum" to the "CA/ISV Forum"


BTW:  I disagree that we’re calling it the “ISV” forum under the proposed language, but in any event I’m fine with reverting the title to “Browser Member”.  I also thought that the wording was sufficient to limit potential browser concerns, but here is a start on revised language that could make it a little more clear in its restrictions:


(3)       Browser Member: The member organization:

(A) manages a root store AND 

(B) is a major global provider of a hardware or software product that is: 

(i) used by the general public as a browser or computing platform, 

(ii) used to browse the Web securely or authenticate digitally signed code, AND 

(iii) able to verify the digital signatures on certificates used with the product (i.e. by processing the chain to a root certificate managed within the member’s root store). 


However, if browser members still have strong opposition to the proposed wording, or this alternative above, I’d rather delete it from the proposal now than have the ballot fail, but I would hope you could see the importance of it to CAs who must deal with public key stores.


I'd love to deal with this in a separate ballot, since it doesn't really tie to the Invited Guests discussion. I certainly can understand how it was originally part of a general clean-up, whereas now we're at a point of just trying to get a bylaws revision in place before the next F2F.



3) Why the removal of the transparency requirements in Section 5.2 for WGs? This is not at all desirable - although the modifications to Section 5.2(c) are.

BTW:  The current language requires that EVERYTHING (even things that are not currently being done, like the creation of agendas and minutes for working groups) be posted to the public list – for some people, the amount of email traffic on the public list is already bad.  Read Section 5.2(e) where “important” working group updates are addressed.  Otherwise, as the responsible executive interpreting the bylaws I will have to start telling everyone that they must prepare agendas and minutes and that all emails and every single interim draft, agenda and all minutes will now need to be posted to the public list, and then we’ll just eliminate the WG lists. 


I for one would welcome the enhanced transparency, and see it as a feature, even as I'm already deluged in e-mail.



4) Why are Invited Guests at the sole discretion of Chair/Vice-Chair, whereas Interested Parties go through Forum/WG consent? If anything, Invited Guests represent the greatest "threat" to members, in that they've not executed any IPR Agreement for any of the discussions they are present in.

BTW:  If someone represents such a threat, we just won’t invite them—problem solved.  However, we will likely run into situations where we value the input of someone, or we want their individual expertise, and for one reason or another they cannot sign the agreement in time (because of employment situation, legal advice, or whatever), then we will have to “pass” on having that person attend, and then maybe we’ll miss out on valuable information.  If we invite [fill-in-the-blank] as our “invited guest”, I want to have sufficient discretion on whether to require them to sign the IPR Agreement.  I would hope that attendees would we able to identify when an invited guest is trying to submarine us with some great idea (albeit contained in an undisclosed patent), and hopefully the Chair or Vice Chair, who we elect as our trusted representative will be smart enough to exercise his or her discretion appropriately.   If we do change this, then we’ll need something appropriate to take its place—I’m fine if someone comes up with a simplified voting process that can also accommodate last-minute guest speaker replacements, etc.

Thanks again for your comments.



When I used such a loaded term as "threat", I do not ascribe malicious intent. I simply mean that, for the members, every one of these IGs - and their contributions - does represent a threat to anything produced by a Standards Defining Organization or (as in the CA/B Forum's case) "similar" organizations. That is the unfortunate situation that we find ourselves in with respect to IPR.


I would definitely feel more comfortable seeing us put the same rigor as applied to members / associates, and simply present it to the Forum, especially when attendance-without-IPR-agreement is an entirely dangerous can of worms, no matter how well-intentioned or well-meaning the IG is. The further nuance is that an IG is, presumably, a natural person, whereas the IPR agreement is with legal persons - typically, corporations. The distinction is that no matter how good the IG is, they may be employed by an organization that does not share the same values, and thus that presents a 'risk'.


Anyways, I think these are the foundations of a series of good changes, I just think they will trigger a variable level of engagement, and for expediency, it might be best to just ballot the minimal set of changes for the F2F, and perhaps simultaneously ballot "the rest" for further discussion. Just $.02 from dealing with code and "minimal patches" / "one commit, one bug".



On Fri, Jan 17, 2014 at 3:49 PM, Ben Wilson <ben at digicert.com> wrote:

I am seeking two endorsers.


On 17 January 2014, Ben Wilson of DigiCert made the following motion, endorsed by _____ of _______ and ______ of __________:

–Motion Begins– 

Be it resolved that the CA / Browser Forum adopts the attached “CA-Browser Forum Bylaws v. 1.1- Draft for Ballot 110” as its Bylaws, effective as of 4 February 2014. 

–Motion Ends– 

The review period for this ballot shall commence at 2100 UTC on 20 January 2014 and will close at 2100 UTC on 27 January 2014. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2100 UTC on 3 February 2014. 


Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear ‘yes’ in the response. A vote against the ballot 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 more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently six (6) members– at least six members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid. 





Public mailing list
Public at cabforum.org



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140120/f538d823/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5453 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140120/f538d823/attachment-0001.p7s>

More information about the Public mailing list