[cabfpub] Browser eligibility in CABF in general (and Comodo specifically)

Wayne Thayer wthayer at mozilla.com
Wed Dec 13 22:19:30 UTC 2017


This is indeed a difficult problem. Mozilla would like the membership
criteria for browsers to reflect the role of making CA trust decisions
while remaining as open and inclusive as possible. The existing rule has
been in place for many years and hasn’t been abused. Note that Comodo
launched their browser years ago, but did not join as a browser until the
CA business was spun off. We do however, share Ryan’s concern that the
current rule may well lead to an outcome in which the CAB Forum loses
influence. Having many browser members will likely make it more difficult
to agree on new policies, and that in turn will drive root store operators
to use their power to unilaterally implement policies more frequently. In
other words, we can foresee a return to the situation that existed before
the CAB Forum was established.

We are not of the opinion that this is a neutral outcome; we believe the
CAB Forum as currently structured benefits all parties.
- CAs benefit by having one consistent policy to follow, and from the
patent protections granted when those policies are enacted by the Forum.
- Users benefit when browsers work together to enforce consistent policies,
and when auditors verify those policies.
- Browsers benefit from collaboration which produces better policies and in
turn drives up quality in the industry.

This issue can be resolved with an update to the browser membership rules.
As Ryan noted, market share isn’t a good solution. The essential
requirement is for the member to make independent trust decisions on every
CA. This can happen by:
- operating a Certificate Authority program that requires some vetting
before every root is accepted to their program, or;
- requiring each CA to enter into a contractual relationship with the root
store operator before their roots are added to the root store.

While these requirements likely need some fine tuning, we believe they
capture the main characteristic we should look for in a CAB Forum browser
member. With the governance reform work nearing completion, we’d like to
see these new criteria adopted as part of the Server Certificate Working
Group charter.

Wayne

On Mon, Dec 11, 2017 at 8:33 PM, Dean Coclin via Public <public at cabforum.org
> wrote:

> To specifically answer Eric’s original point, the Forum followed its
> bylaws (to the letter) in admitting Comodo browser as a member. There was
> no gray area there and there was no special consideration made, just as
> none has been made in admitting any CA, Associate member or Interested
> Party. They applied, were told to provide the specific info requested by
> the bylaws, and once that was reviewed, admitted.
>
>
>
> Now the point you raise (regarding running a root store) could be
> something to be discussed at a meeting and all you need to do is have the
> chair add it to the agenda. If there’s enough interest, this could
> eventually lead to a change to the current bylaws.
>
>
>
> I should also point out that the Governance Reform Working Group is
> currently working on revised bylaws which, because of different types of
> members contemplated, would divide into two different definitions: Issuers
> of Certificates and Consumers of Certificates (or something to that
> affect). Issuer is pretty clear (CAs). Browser is being changed to
> “consumer” since the Forum will likely take on other types of certificates
> (i.e. SMIME, Code Signing, etc) where browsers don’t necessarily play a
> role but applications that “consume” such certificates do. Those
> applications may not necessarily run a root store.
>
>
>
> Given that the new bylaws will allow for distinct working groups with
> their own member definitions, the TLS working group can define their own
> rules for who can be an issuer and a consumer.
>
>
>
> Dean
>
>
>
> *From:* Public [mailto:public-bounces at cabforum.org] *On Behalf Of *Ryan
> Sleevi via Public
> *Sent:* Monday, December 11, 2017 11:12 AM
> *To:* Eric Mill <eric at konklone.com>; CA/Browser Forum Public Discussion
> List <public at cabforum.org>
> *Subject:* Re: [cabfpub] Browser eligibility in CABF in general (and
> Comodo specifically)
>
>
>
> Hi Eric,
>
>
>
> I really appreciate you raising this point. I, too, am torn about this
> issue, and have been on the record expressing concerns going back for
> several years. To the extent the CA/Browser Forum serves to facilitate open
> communication between CAs and the Root Stores they participate in, there is
> ostensibly some benefit in having as many root stores present. Google,
> representing ChromeOS and Android, Apple representing macOS, iOS and
> watchOS, Microsoft representing Windows (and all the various products
> running Windows kernel or CryptoAPI, such as XBox), and Mozilla
> representing Firefox all represent potential points of friction for a CA
> that wishes to be ubiquitously trusted and ensure that there are no
> conflicting requirements.
>
>
>
> Yet, at the same time, it's questionable whether or not Comodo runs a root
> store, it's questionable whether there has ever been friction in CAs
> communicating with Comodo for purposes of trust in their browser-based
> products, and it's questionable whether the bar should be such that any
> Chromium-derived or Firefox-derived browser should qualify, for the reasons
> you mention. I think a natural consequence of both Comodo's participation
> specifically and the potential membership under the Bylaws is that we will
> increasingly see the Forum become less relevant as the place for agreeing
> upon common baselines, and more as a place purely for discussion around
> trends in the industry. That's not to say I don't anticipate there being
> some updates to the Forum's documents - when it aligns with both browsers
> and CAs interests - but I suspect that increasingly, the forward-thinking
> moves towards security will happen outside the Forum, through the
> respective root programs.
>
>
>
> I, too, don't have good suggestions on how to solve the membership
> problem. On the one hand, having a Forum for discussion, with the IP
> protections some members desire, serves as a great benefit for the
> community. It allows browsers to solicit CAs' feedback about upcoming or
> planned policy changes, and allows for collaboration among browsers to
> avoid conflicting requirements. Having an open membership - including that
> of interested parties - helps provide robust discussion. Yet on the other
> hand, the voting structure of the Forum, coupled with the misguided notion
> that the Forum 'leads' rather than follows the browser/root store members'
> program changes, lead to the situation you point out. Attempting to resolve
> that via excluding participation may not be ideal - although notably,
> Comodo could have joined as an Interested Party. Proportional voting might
> be more reflective of the dynamic and purpose of the Forum, if we want to
> still maintain documents going forward, but in order to achieve that, one
> must have a good definition of the issue.
>
>
>
> For example, one could measure by end-user browser share, but finding an
> appropriate measure of that can vary (for example, installations). Further,
> it can incentivize certain OS vendors to restrict and/or block competition
> from other browsers on their platforms, whether through outright policies
> or through making it exceptionally difficult to change the browser, even
> more than they do today. Alternatives, such as measuring on 'number of
> pages loaded' or 'connections made' are complicated - after all, cURL, as
> the most popular library on billions of devices, may want to be
> represented, although they alternatively use the OS store (if the
> SecureTransport/SChannel backend), a user-supplied store (most frequently,
> the Mozilla store), or a vendor-specific store (in the case of the Wii U,
> Switch, PS3 or PS4, for example). How to defer that representation?
>
>
>
> I note I didn't really offer any solutions - Comodo's joining as a browser
> may very well herald the start of the decline of the Forum's relevance as
> an SDO, and more into what it originally served as - a Forum for browser
> members to explore changes and deconflict them, but without waiting for or
> needing the approval of CA members or other browsers. And I don't think
> that's necessarily a bad thing, especially for users that care about
> security and benefit from browsers that are able to do the right thing.
>
>
>
> On Sun, Dec 10, 2017 at 11:21 PM, Eric Mill via Public <
> public at cabforum.org> wrote:
>
> Does no one have thoughts on this?
>
>
>
> I can understand how CAs and Browsers both might find it difficult to
> discuss this aspect of the Forum in their official capacities. Perhaps
> there are other Interested Parties on the list with an opinion?
>
>
>
> -- Eric
>
>
>
> On Sun, Dec 3, 2017 at 8:52 PM, Eric Mill <eric at konklone.com> wrote:
>
> I saw on the draft agenda, sent around on the 27th for last week's call,
> included "Membership Application of Comodo Security Solutions, Inc. (as a
> browser)".
>
>
>
> I know it will take some time for the minutes of the call to be posted
> with the result of Comodo's application, but this seemed like a significant
> application that merits public discussion.
>
>
>
> The Bylaws don't apply any rules about market share or other indicators of
> significance to the marketplace:
>
> https://cabforum.org/wp-content/uploads/CA-Browser-Forum-Bylaws-v.-1.7.pdf
>
>
>
> The entirety of the eligibility clause for Browsers states: "The member
> organization produces a software product intended for use by the general
> public for browsing the Web securely."
>
>
>
> The CA eligibility clause is significantly more constrained, in particular
> in that the certificates have to be recognized by Browser members. However,
> this makes the set of Browser members even more important in determining
> eligibility of CAs.
>
>
>
> Comodo appears to publish two browsers, Dragon and IceDragon, based on
> Chromium and Firefox, respectively: https://www.comodo.com/home/
> browsers-toolbars/internet-products.php
>
>
>
> They don't appear to operate a root program or exercise independent
> discretion about what CAs are trusted on their platform in any visible way,
> they've never participated as a browser in any significant public
> conversations about the Web PKI that I've seen, and their market share
> appears to be negligible from all available public data.
>
>
>
> But the Bylaws would seem to allow Comodo to join as a browser, which I
> think would significantly undermine the entire point of the Forum -- as
> well as potentially open a floodgate of applications from more marginal or
> almost-fictional browsers.
>
>
>
> For a quick glance at how many browsers theoretically could join the Forum
> under the current bylaws, a long list of them can be in these daily-updated
> feeds of browsers (as their user agent appears in Google Analytics) that
> have at least 10 visits over 90 days to government properties:
>
>
>
> https://analytics.usa.gov/data/live/browsers.csv
>
> https://analytics.usa.gov/data/live/browsers.json
>
>
>
> Market share may or may not be the right threshold, and I don't have some
> specific text to suggest off the top of my head -- but it does feel like a
> discussion is merited about whether the Bylaws around browser eligibility
> adequately capture the intent of the Forum.
>
>
>
> -- Eric
>
>
>
> --
>
> konklone.com | @konklone <https://twitter.com/konklone>
>
>
>
>
>
> --
>
> konklone.com | @konklone <https://twitter.com/konklone>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20171213/2eeca85a/attachment-0003.html>


More information about the Public mailing list