[cabfpub] Post-Ballot 110 Bylaw Issues

Tom Albertson tomalb at microsoft.com
Tue Jan 28 19:35:21 UTC 2014

I re-raise my proposal for alignment with existing definition in related standards, particularly “trust anchor managers” or TAMs.  See my email on 10/10/13 for a description – it has the identified issue of the Opera scenario, and how do they fit, but would seem to fit everyone else who currently participates.    I share Ryan’s concerns about scope of 3(B) as it relates to how we get defined.  We can discuss this in Santa Clara all together or see if ‘the browsers’ can agree to a simple definition (preferably over beers).  But I don’t see what wiping out existing WG listservs policy has to do with this issue.


From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson
Sent: Friday, January 24, 2014 3:02 PM
To: 'Ryan Sleevi'
Cc: 'CABFPub'
Subject: Re: [cabfpub] Post-Ballot 110 Bylaw Issues

Thanks, Ryan.  On the browser membership category, those of us who represent CAs may not have a full appreciation of all of the issues.  Therefore, would someone from the “browser” side of this organization be willing to propose a rework of that membership category and/or alternative categories and voting rules as you suggest?  Second, on the discussion of the current language in section 5.2, it would be nice to see if anyone has suggestions for improvements, if any.  Otherwise, we should just drop the issue and do as Wayne suggests and retire the EV and CS WG lists and start new ones that are public.
Thanks again,

From: Ryan Sleevi [mailto:sleevi at google.com]
Sent: Friday, January 24, 2014 3:05 PM
To: Ben Wilson
Subject: Re: [cabfpub] Post-Ballot 110 Bylaw Issues

On Fri, Jan 24, 2014 at 1:51 PM, Ben Wilson <ben at digicert.com<mailto:ben at digicert.com>> wrote:

For the currently pending Ballot 110 version of the Bylaws, we postponed changes to Section 2.1(a)(3) for more group discussion about the membership category of “Browser.”
We also postponed any changes to Section 5.2 for more discussions about transparency vs. security of working group lists--we have had discussions about whether existing WG mailing lists need to be shut down so that new ones can be started which are publicly accessible.  I mention an alternative solution below.

Also note that regardless of any changes we might make to the Browser membership category, we’re not going to rename our organization to something else.  Also, Iñigo’s email concerning Cisco this morning reminded me that Cisco had asked to become a member in the CA/Browser Forum.   I think Cisco fits better in the browser category than in the CA category even though they do manage a publicly trusted PKI – as do Google, Microsoft, and Apple.    However, the proposed edit to section 3.1(3) of the bylaws says:

(3)          Browser Category:  The member organization
(A) manages a root store and
(B) is a major global provider of a hardware or software product that is:
(i)  intended for use 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 that entity’s product by processing the chain to a root certificate managed by that entity’s root store.

I still have concerns with 3(B)(ii) and 3(B)(iii), as discussed previously.

I realize that the CA's themselves operate many services beyond just the provisioning of SSL/TLS certificates, and that this Forum thus may be an excellent venue for the discussions between independent software vendors with relations to these CAs and the CAs.

That said, I am concerned with the significant increase of scope of the Forum's work and how it affects many of the bylaws that were developed in consideration of Browsers and CAs.

If the Forum wishes to accept such members, I think a new membership category - with updates to the various policies regarding voting, etc - is better suited for this, because Browser seems to be both the wrong category and potentially detrimental to the requirements documents produced that govern SSL/TLS certificates.

The proposed language would also seem to exclude organizations like Opera, based on the criteria of 3(A), whereas the current 2.1(a)(3) permits them.

So, even under this proposed subsection (3)(B)(i) category definition, Cisco might not qualify because unless someone can clarify if Cisco provides a browser or computing platform – so additional wordsmithing may be necessary.  That being said, I’d suggest that if they want to, we allow Cisco to join the CA/B Forum in the interim as an Associate Member, upon their submission of a signed IPR Agreement.  Then, their membership status can change if our membership criteria in the bylaws change.


Also, to reignite the discussion on section 5.2, one of the arguments for amendment, in addition to the one I’ve made for administrative simplification, is that security sensitive discussions should be exempted from public disclosure – I think that means that certain email lists should not be required to be made public.  Does anyone disagree with the general proposition that the public disclosure of security measures weakens the effectiveness of those security measures?

Any security that maintains security through obscurity, is, generally speaking, a bad security platform.

I think our goal with the long discussions about transparency within the WG should be to keep as many communications as possible in the open. Discussion of mitigation is, in my opinion, not a security incident worthy event, and as such would better serve the public interests to keep discussions open.

Section 5.1 of the Bylaws currently provides that non-public discussions of the following may take place on the management list:
(d)          Security incidents if, in the opinion of the Members, discussion on the Public Mail List could reasonably be detrimental to the implementation of security measures by Members.
(f)           Matters which, in the opinion of the Members, require confidentiality.

So, there are working group discussions that should be allowed to take place confidentially without flooding the Management List (or the Public List).

Edits to sections 5.1 and 5.2 are needed to clarify our position on this.  Meanwhile, maybe we need to adopt an approach like we have for the management and public lists – i.e. two lists for each working group – one public and one private?  Then “Members have discretion about which mailing list they use, but are strongly encouraged to use the Public Mail List for [most] matters.”  And “[they] are strongly discouraged from posting the text of [non-public working group] list messages [publicly] without the permission of the author or commenter.”  This is consistent with the current approach of our bylaws.




Public mailing list
Public at cabforum.org<mailto:Public at cabforum.org>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140128/e7974840/attachment-0003.html>

More information about the Public mailing list