[cabfpub] Discussion Draft for Revisions to Bylaws

Wed Nov 6 16:04:01 MST 2013

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
Cc: CABFPub
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
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 <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
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20131106/2c68ed90/attachment-0001.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 : https://cabforum.org/pipermail/public/attachments/20131106/2c68ed90/attachment-0001.doc 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5453 bytes
Desc: not available
Url : https://cabforum.org/pipermail/public/attachments/20131106/2c68ed90/attachment-0001.bin 