I'm disputing the conclusion that is being drawn from Jake's concerns, rather than the concerns themselves. Primarily, I disagree with the conclusion that because Google owns a browser with dominant market share and - due to the substantial contributions they make here - because Google has considerable influence in this community, they should not be allowed to participate in our root program as a CA. Secondarily, I disagree that a Google employee should not be a peer of this module due to the potential for a conflict of interest.
Unpacking this conclusion in terms of policy it implies, I think the argument being made is that any root store operator should be excluded from membership in the Mozilla program as a CA, and any employee of a CA should be prohibited from being a module peer. The argument is that this will protect us from future conflicts of interest (there seems to be agreement that the concern is hypothetical at this point). My conclusion is that rather than creating somewhat arbitrary, exclusionary rules, we can and should instead rely on the openness and inclusiveness of our process to protect us from conflicts of interest. If Google attempts to gain preferential treatment for their CA from Mozilla, our community can and will identify it, reject it, and hold Mozilla accountable for acting in their best interest. On Wed, Sep 26, 2018 at 9:49 AM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Wed, Sep 26, 2018 at 12:04 PM Jeremy Rowley <jeremy.row...@digicert.com > > > wrote: > > > I also should also emphasize that I’m speaking as Jeremy Rowley, not as > > DigiCert. > > > > > > > > Note that I didn’t say Google controlled the policy. However, as a module > > peer, Google does have significant influence over the policy and what CAs > > are trusted by Mozilla. Although everyone can participate in Mozilla > > discussions publicly, it’s a fallacy to state that a general participant > > has similar sway or authority to a module peer. That’s the whole point of > > having a separate class for peers compared to us general public. With > > Google acting as a CA and module peer, you now have one CA heavily > > influencing who its competitors are, how its competitors operate, and > what > > its competitors can do. Although I personally find that you never misuse > > your power as a module peer, I can see how Jake has concerns that Google > > (as a CA) has very heavy influence over the platform that has > historically > > been the CA watchdog (Mozilla). > > > > Jeremy, I think this again deserves calling out, because this is > misrepresenting what module peership does, as well as the CA relationship. > > I linked you to the definition of Module Ownership, which highlights and > emphasizes that the module peer is simply a recognized helper. To the > extent there is any influence, it is through the public discussions here. > If your concern is that the title confers some special advantage, that's to > misread what module peer is. If your concern is that the participation - > which provides solid technical arguments as well as the policy alternatives > - is influential, then what you're arguing against is public participation. > > You're presenting these as factual, and that's misleading, so I'd like to > highlight what is actually entailed. > > > > The circumstances are different between the scenarios you describe with > > respect to the other browsers, as is market share. If Microsoft wants to > > change CAs (and they already use multiple), they can without impacting > > public perception. If Apple wants to use another CA, they can without > > people commenting how odd it is that Apple doesn’t use the Apple CA. With > > Google controlling the CA and the Google browser, all incentive to > > eliminate any misbehaving Google CA disappears for financial reasons, > > public perception, and because Google can control the messaging (through > > marketshare and influence over Mozilla policy). Note that there is > > historical precedent for Google treating Google special – i.e. the > > exclusion for Google in the Symantec distrust plan. Thus, I think Jake’s > > concerns should not be discarded so readily. > > > > I can understand and appreciate why you have this perspective. I disagree > that it's an accurate representation, and as shown by the previous message, > it does not have factual basis. I think it's misleading to suggest that the > concerns are being discarded, much like yours - they're being responded to > with supporting evidence and careful analysis. However, they do not hold > water, and while it would be ideal to convince you of this as well, it's > equally important to be transparent about it. > > Your argument above seems to boil down to "People would notice if Google > changed CAs, but not if Microsoft" - yet that's not supported (see, > example, the usage of Let's Encrypt by Google, or the former usage of > WoSign by Microsoft). Your argument about incentives entirely ignores the > incentives I just described to you previously - which look at public > perception, internet security, and ecosystem stability. Your argument about > influence over Mozilla policy has already been demonstrated as false and > misleading, but it seems you won't be convinced by that. And your > suggestion of special treatment ignores the facts of the situation (the > validation issues, the scoping of audits, that Apple and 2 other CAs were > also included in the exclusion), ignores the more significant special > treatment granted by other vendors (e.g. Apple's exclusion of a host of > mismanaged Symantec sub-CAs now under DigiCert's operational control), the > past precedent (e.g. the gradual distrust of WoSign/StartCom through > whitelists, of CNNIC through whitelists), and the public discussion > involved so entirely that it's entirely unfounded. > > So I think your continued suggestion that it's being discarded so readily > is, again, misleading and inaccurate. > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
