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). 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. From: Ryan Sleevi <r...@sleevi.com> Sent: Wednesday, September 26, 2018 12:43 AM To: Jeremy Rowley <jeremy.row...@digicert.com> Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Google Trust Services Root Inclusion Request (While covered in https://wiki.mozilla.org/CA/Policy_Participants , I'm going to emphasize that this response is in a personal capacity) On Wed, Sep 26, 2018 at 12:10 AM Jeremy Rowley via dev-security-policy <dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> > wrote: Jake's concern is legit if you believe certain assumptions. Criticizing his rationale doesn't seem correct, especially since Google does indeed have a root store. Although not traditional, Google runs a store of blacklisted CAs (see Symantec), which is every bit as effective as controlling CA compliance and operation as the inclusion process. To be clear: Google does indeed operate root stores on a host of devices, including Android and ChromeOS, not to mention Google Cloud functionality. FACT: As a browser, Google already interprets the CA/Browser requirements in many ways via, intentionally or not. The Google's policies, and how Google implements Chrome are all closely watched by CAs and help dictate how we interpret the various requirements. This fact combined with the assumption that Google will never distrust itself jumps to a conclusion that Google will only interpreting the BRs in Google CA's best interests. Why wouldn't they? Google is a for profit company. Self-promotion is kind-of in the description. The problem with this assumption, or at least what logically follows, is that every Browser would behave the same, beneficient towards the CA(s) they use for services. For example, Microsoft operates a root program, yet is also trusted by Mozilla through the subordinate CAs provided through the Baltimore Cybertrust hierarchy, which is owned by... DigiCert. Similarly, Apple operates a root program, yet is also trusted by Mozilla through subordinate CAs provided through the GeoTrust hierarchy, which is owned by... DigiCert. Google operates a root program, yet is also trusted by Mozilla through... the acquisition of key material (from GlobalSign) and the operation of independent roots. If we accept this assumption as sound, then it seems the argument is that DigiCert can also never be distrusted, and interpretations will always be to the benefit of DigiCert, because to distrust DigiCert or take sanction would be to disrupt 'critical' services like Azure or iTunes. Alternatively, one could argue/make assumptions that by virtue of Google previously having operated a subordinate under the GeoTrust hierarchy (DigiCert, formerly Symantec), that they've demonstrated it's possible to operate as subordinate or root. They demonstrably took steps regarding the Symantec hierarchy, even as it was the basis for trust of Google services. In that model, if Google CA were to take actions detrimental to the ecosystem, Google may interpret the BRs in the Internet trust and stabilities best interests, distrust the Google CA, and force Google to transition to an alternative solution precisely to avoid the alternative. The problem here is these are all assumptions that rest on ignoring pertinent details. FACT: Google is a module peer in Mozilla NSS, which means Google has significant influence over BR interpretation, the penalties related to CA mis-issuance, and the requirements a CA has for operating within the space. This gives one CA a lot of influence over how Mozilla treats the other CAs. The change in paradigm means a reasonable person (like Jake) could be concerned with potential obfuscation of problems, a loss of policy enforcement, and various other nefarious acts. I think most of us Mozilla users see Mozilla as a watch-dog of the Internet so this combination of Browser-CA-module peer reasonably causes unease. Unfortunately, this FACT isn't correct - it doesn't reflect the Module Ownership Governance System, which is covered in https://www.mozilla.org/en-US/about/governance/policies/module-ownership/ . A peer isn't the decision maker - that rests with the Owner, particularly for matters of things like policy. We could discuss the semantics of Google vs Google Trust Services, but I fully acknowledge that it would go over about as well as WoSign vs StartCom vs Qihoo 360. We could discuss https://wiki.mozilla.org/CA/Policy_Participants and its set of disclosures, but I'm sure some people will find that unsatisfying. What is perhaps most relevant is to highlight the fact that these questions of interpretation - of BRs or policies - happen on the list, that the module owner is the decision maker, and that public participation is fully welcomed, whether peers or otherwise. In that model - of transparency - doesn't support the claims being presented here as 'fact', and instead highlights them as 'assumption's that they are.
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
