[cabfpub] Differentiating the participants - RE: Discussion Draft for Revisions to Bylaws

Ben Wilson ben at digicert.com
Thu Nov 7 13:39:49 UTC 2013


-------- Original message --------
From: "N. ATILLA BILER" <atilla.biler at turktrust.com.tr> 
Date: 11/07/2013  3:46 AM  (GMT-08:00) 
To: CAB FORUM PUB <public at cabforum.org> 
Subject: [cabfpub] Differentiating the participants - RE: Discussion Draft	for Revisions to Bylaws 
Dear Ben,
Related to the updated ByLaws, I have one comment and one point to be clarified more.
·         I think in item 5.5., Associate Members’ IPR responsibility should also be mentioned, although that requirement may be waived due to specific reasons according to item 3.1:
5.5          IPR policies
As a requirement for membership, Members must execute and return to the Chair the IPR Agreement attached as Exhibit A.
As a requirement for participation as an Interested Party, Interested Parties must execute and return the IPR Agreement to the Chair.
·         The four participation types mentioned in items 2 and 3 in the Bylaws explain the “Members” and “Invited Guests” quite explicitly and clearly without any doubt. Members may be one of the three (even the last one is divided into two) “Issuing CAs”, “Root CAs” or “Browsers/Platform Providers”. However, the distinguishing characteristics of “Associate Members” and “Interested Parties” are still vague for me. As far as I understand:
o   Associate Members are routine participants of F2F meetings, teleconferences and users of forum mail lists and forum wiki pages. They need to sign a special agreement with CAB Forum in addition to IPR. Voting is also limited for these. My question is, whether they are eligible for participating in the working groups of the Forum or not.
o   Interested Parties may participate in the F2F meetings only upon explicit invitation by the Forum Chair. Mainly participate in the working groups. Use the public mail list (not the management list). They cannot vote. My question is, what are the distinguishing factors and the differences in the criteria used to decide that an entity is an Associate Member or an Interested Party. Also, is it not possible to differentiate their way of participating more? For instance, an interested party may follow the public list but may not post to it directly without CAB Forum’s approval, and the like…
We may discuss these more on today’s teleconference.
I just wanted to share beforehand…
Best regards,
N. Atilla BILER
Business Development Manager
Address: Hollanda Cad. 696.Sok. No:7 Yildiz 06550 Cankaya / ANKARA - TURKEY
Phone  : +90 (312) 439 10 00
Mobile : +90 (530) 314 24 05
Fax         : +90 (312) 439 10 01
E-mail   : atilla.biler at turktrust.com.tr
Web      : www.turktrust.com.tr
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson
Sent: Thursday, November 07, 2013 1:04 AM
To: 'CABFPub'
Subject: Re: [cabfpub] Discussion Draft for Revisions to Bylaws
Here is another draft for review and discussion.
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi
Sent: Wednesday, October 16, 2013 12:27 PM
To: ben at digicert.com
Subject: Re: [cabfpub] Discussion Draft for Revisions to Bylaws

On Wed, Oct 16, 2013 at 11:12 AM, Ben Wilson <ben at digicert.com> wrote:
What about this?
(3)       Browser/OS Producer: The member organization is a major global provider of certificate-using software that depends upon certificates issued by multiple public CAs to support the secure use of its product by the general public.  Examples of certificate-using software includes web browsers, cryptolibraries, root stores, operating systems, computing platforms, software distribution systems, and products for digital document signing and publication.  [Expressly eligible for membership under this category are: Apple, Microsoft, Oracle, Google, Mozilla Foundation, Opera, Adobe, …]
Note that the previous definition focused on the SSL/TLS ecosystem. That we have a Code Signing WG under these definitions is a bit... weird.
This new definition, particularly with the inclusion of digital document signing/publication, seems to be a much broader scope for the CA/Browser Forum.
I'm not necessarily saying that's an intrinsically bad thing, but this goes back to a lot of the discussions about the charter of the group and the openness & transparency discussions. There were a number of parties that tried to argue for a narrow scope of membership, on the basis that the relationship was between the CAs & Browsers, primarily.
I'm not sure, for example, what impact document signing would have on browser vendors interested in SSL/TLS, but I'd be concerned if we were unable to improve the SSL/TLS ecosystem because of vendors who were not interested/opposed because of their other purposes.
I just want to make sure we're fully considering the implications of the proposal here. I appreciate the effort for wording, but given that it can massively open the scope, particularly with regards to voting and agreeing on things like Baseline Requirements (for SSL/TLS), I want to make sure we're organizationally prepared. I don't believe we're at that point yet.
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi
Sent: Tuesday, October 15, 2013 5:46 PM
To: ben at digicert.com
Subject: Re: [cabfpub] Discussion Draft for Revisions to Bylaws
As expressed previously, I do have concerns about the definition of browser.
For example, if I write a popular mobile application for Android and iOS that is downloaded by 10 million users, and which uses SSL/TLS to update an online leaderboard, it would appear that under the current definition of browser, I would qualify (and, presumably, as a voting-eligible member).
I realize that this is, perhaps, a challenging definition. For instance, we have organizations like Opera who have long participated and helped steer towards a more secure Internet, but which are in the process of transitioning away from operating a Root Store directly. Likewise, Google's participation has largely been made up of members from the Google Chrome team, even though the primary Root Programs are through Android and ChromeOS (as noted in the past, Chrome on Windows / Mac / Linux attempts to defer to a notion of a 'system' trust store). And on the other end, we have organizations like Oracle, for which operate a Root Program (for Java), which indirectly may be used towards the construction of either a Web Browser or any other number of applications.
However, I think it's best we balance the desire to be inclusive with the recognition of where the primary strength of this group lies in - the development of baseline policies that can reduce both the complexity of compliance to AND (hopefully) avoid any contradictory guidance between Browser Root Programs.
My fear is that an overly broad definition will destablize some of these efforts, bringing the industry back to a place it was 5 - 10 years ago - where each Root Program has an independent set of guidelines with limited commonality, and even weaker auditing frameworks.
Just food for thought, as I don't yet have particular language to propose to enhance this, but am left with a general unease at the current wording.

On Tue, Oct 15, 2013 at 4:23 PM, Ben Wilson <ben at digicert.com> wrote:
Here is a discussion draft for changes to the bylaws.  You’ll notice I haven’t edited any of the provisions related to Interested Parties because there are a few things to iron out there and maybe somebody else has some good suggestions.  I’ll post the Word version on the wiki in case anyone needs it.

Public mailing list
Public at cabforum.org

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

More information about the Public mailing list