Oh – I totally agree with you on the Google inclusion issue. Google meets the requirements for inclusion in Mozilla’s root policy so there’s no reason to exclude them. They have an audited CPS, support a community broader with certs than just Google, and have operated a CA without problems in the past. The discussion on Mozilla’s independence is important IMO where a) a Mozilla competitor as a module peer and b) having that same person also belong to a CA. There are legit concerns. Has any other CA served as a module owner? If not, why? I know Tim Hollebeek would be interested in being a peer. If he’s not permitted to be a peer, why not?
To be fair, separating out Ryan as a Google browser representative and Ryan as a module peer is…hard. Perhaps, he specifically is seen as more influential (from my point of view) than others simply because of his dual role. As I said before, Ryan’s a good module peer so I don’t disagree with your conclusion or any decision to keep him in that spot. But I think openness should include respectful conversation on the impact of influences, perceived or real, on the Mozilla direction. What might help alleviate concerns is to describe how you (as a module owner) are going to ensure that if Ryan is reviewing and approving code or CA policies, they won’t be unfairly biased towards google or against its competitors? Maybe that’s a bad question, but I’m spit-balling on how we can move past speculation to address concerns raised. From: Wayne Thayer <wtha...@mozilla.com> Sent: Wednesday, September 26, 2018 3:39 PM To: Ryan Sleevi <r...@sleevi.com> Cc: Jeremy Rowley <jeremy.row...@digicert.com>; mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: Google Trust Services Root Inclusion Request 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 <mailto:dev-security-policy@lists.mozilla.org> > wrote: On Wed, Sep 26, 2018 at 12:04 PM Jeremy Rowley <jeremy.row...@digicert.com <mailto: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 <mailto:dev-security-policy@lists.mozilla.org> https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
