Ryan mentioned WoSign/StartCom and 360, so I like to say some words. First, I think your idea is not a proper metaphor because 360 browser can't compare to Google browser, Google browser have absolutely strong market share to say YES/NO to all CAs, but I am sure not to Google CA.
Second, I think Google to be a global public CA is a wrong decision, this is the same situation that one person is the athlete and the judge, how to guarantee the fair? This two business have conflict of interest. Third, your comparison of Apple and Microsoft is also not correct, they use its own CA system for their own system use only, not for public, not to be a global public CA like Google. So, I think accepting Google root to Mozilla trust store don't benefit for anyone except Google only, not for the Internet security community, not for the CA industry and not for end users. Ryan, thank you for still remembering WoSign. Best Regards, Richard Wang -------- Original message -------- From: Ryan Sleevi via dev-security-policy Received: 2018-09-26 14:48:28 To: Jeremy Rowley 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> 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. _______________________________________________ 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
