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

Thu Nov 7 11:46:56 UTC 2013

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

TURKTRUST Inc.

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   :  <mailto:atilla.biler at turktrust.com.tr>
atilla.biler at turktrust.com.tr 

Web      :  <http://www.turktrust.com.tr/> 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:  <mailto:public-bounces at cabforum.org> public-bounces at cabforum.org [
<mailto: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:  <mailto:ben at digicert.com> ben at digicert.com
Cc: CABFPub
Subject: Re: [cabfpub] Discussion Draft for Revisions to Bylaws

On Wed, Oct 16, 2013 at 11:12 AM, Ben Wilson < <mailto:ben at digicert.com>
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:  <mailto:public-bounces at cabforum.org> public-bounces at cabforum.org
[mailto: <mailto:public-bounces at cabforum.org> public-bounces at cabforum.org]
On Behalf Of Ryan Sleevi
Sent: Tuesday, October 15, 2013 5:46 PM
To:  <mailto:ben at digicert.com> ben at digicert.com
Cc: CABFPub
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 < <mailto:ben at digicert.com>
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.

Thanks,

Ben

_______________________________________________
Public mailing list
 <mailto:Public at cabforum.org> Public at cabforum.org
 <https://cabforum.org/mailman/listinfo/public>
https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20131107/0ed2745c/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CA-Browser Forum Bylaws 2nd Discussion Draft for v. 1.1.doc
Type: application/msword
Size: 279552 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20131107/0ed2745c/attachment-0002.doc>