On 26/09/2018 09:43 πμ, Ryan Sleevi via dev-security-policy wrote: > (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.
I would like to add that based on previous experience, Google has built a firewall between the Chrome and the rest of the teams. And it seems that there is a special treatment by the Chrome team, but not the one stated. Google trying to set the example is more strict when it comes to their own services. For example, you can see the history behind freezing the google-run Aviator log. Even though other logs, such as the ones run by Venafi and the DigiCert, had single MMD violations and were not disqualified, Google decided to freeze Aviator. I think this is a clear indication that Google does not favor their own services. Regards, Fotis > > >> 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 > -- Fotis Loukos, PhD Director of Security Architecture SSL Corp e: fot...@ssl.com w: https://www.ssl.com _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
