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

Mike Reilly (WDG) Mike.Reilly at microsoft.com
Tue Jan 2 17:59:02 UTC 2018

All, Sorry for the delayed response as I was out on vacation.  I definitely support the points made by Wayne below, specifically that a “browser” member’s essential requirement is for the member to make independent trust decisions on every CA.   Our root store supports server authentication, client authentication, secure email, code signing, time stamping, encrypting file system, document signing, EV server authorization, EV code signing, OCSP signing with each of these root cert EKUs specifically called out in a formal contract between Microsoft and the CA.   Thanks, Mike

From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Wayne Thayer via Public
Sent: Wednesday, December 13, 2017 2:20 PM
To: Dean Coclin <dean.coclin at digicert.com>; CA/Browser Forum Public Discussion List <public at cabforum.org>
Subject: Re: [cabfpub] Browser eligibility in CABF in general (and Comodo specifically)

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.


On Mon, Dec 11, 2017 at 8:33 PM, Dean Coclin via Public <public at cabforum.org<mailto: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.


From: Public [mailto:public-bounces at cabforum.org<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<mailto:eric at konklone.com>>; CA/Browser Forum Public Discussion List <public at cabforum.org<mailto: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<mailto: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<mailto: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:

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<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.comodo.com%2Fhome%2Fbrowsers-toolbars%2Finternet-products.php&data=04%7C01%7CMike.Reilly%40microsoft.com%7Cf8ad604c27644767e8b808d54277ac20%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636488004174956548%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=vzKRzVEr5P78Jbi4oF9%2FoR0%2FmE3%2BBqUQaPphevIPy9I%3D&reserved=0>

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:


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<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkonklone.com&data=04%7C01%7CMike.Reilly%40microsoft.com%7Cf8ad604c27644767e8b808d54277ac20%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636488004174956548%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=DZznzEJTUMxq%2BwP1EfQqCssJHW2Q0XBDCH0ssxBT5Ko%3D&reserved=0> | @konklone<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fkonklone&data=04%7C01%7CMike.Reilly%40microsoft.com%7Cf8ad604c27644767e8b808d54277ac20%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636488004174956548%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=ImKVho1glKMyZKWi0BvkpB%2Fn2WaNTHYkqcPNiw88a0o%3D&reserved=0>

konklone.com<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkonklone.com&data=04%7C01%7CMike.Reilly%40microsoft.com%7Cf8ad604c27644767e8b808d54277ac20%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636488004174956548%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=DZznzEJTUMxq%2BwP1EfQqCssJHW2Q0XBDCH0ssxBT5Ko%3D&reserved=0> | @konklone<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fkonklone&data=04%7C01%7CMike.Reilly%40microsoft.com%7Cf8ad604c27644767e8b808d54277ac20%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636488004174956548%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=ImKVho1glKMyZKWi0BvkpB%2Fn2WaNTHYkqcPNiw88a0o%3D&reserved=0>

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

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/20180102/08320e75/attachment-0002.html>

More information about the Public mailing list