So this is the third of my 3 sets of criticisms regarding the acquisition of the GlobalSign roots by Google Trust Services. I apologize for the significant delay between the first 2 sets and this one. Hopefully people in the forum still feel this discussion relevant going forward even though the matter is considered resolved.
Several of the comments I made regarding GlobalSign also apply to Google, especially the intermingling of the two brands. The implications of the confusion and uncertainty leading to an exploitable attack are just as applicable to Google as they are to GlobalSign. However, when you consider the stature of Google both on the Internet and in consumer products, the ramifications are more significant. Or, if you will, the attack surface is quite different than if GlobalSign were to purchase a root from, say, Symantec. I do fault Google for what I consider to be inadequate communication of the acquisition. This is not to say there's been no communication, just that I don't think it's enough, especially if you are not a CABF participant or don't keep up with Internet security news generally. Why not publish a message last October that regular folks on the Internet can understand? Why wait 3 months? Why expect people to dig through a CPS to find what should be readily available information? I would be interested in knowing why Google felt it necessary to purchase an existing root instead of, for example, pursuing a "new root" path along the lines of what Let's Encrypt did? All I could gather from the Google security blog is that they really want to be a root CA and to do it in a hurry. Why the need to do it quickly, especially given the risks (attack surface)? I also would like to know what the plan or expectation is regarding formal separation between the infrastructures of Google and GlobalSign. The overlap is an understandable necessity during the transition but nonetheless presents another opportunity for improper access, loss (leaking) of data, and perhaps other nefarious activities. And, does Google have a published policy regarding the information collected, stored, and analyzed when people access the CRL and OCSP distribution nodes? I do want to say I appreciate that someone with Ryan H.'s level of experience is involved in a transaction like this. There are undoubtedly many details to address that ensure a secure and proper transfer. I hope that someone on the GlobalSign side was equally experienced? The next time someone wants to purchase existing roots, the people involved might not have that same level of experience, and that should give everyone pause. Original Message From: Ryan Hurst via dev-security-policy Sent: Wednesday, March 8, 2017 12:02 PM To: mozilla-dev-security-pol...@lists.mozilla.org Reply To: Ryan Hurst Subject: Re: Google Trust Services roots > Jakob: An open question is how revocation and OCSP status for the > existing intermediaries issued by the acquired roots is handled. Google is responsible for producing CRLs for from these roots. We are also currently relying on the OCSP responder infrastructure of GlobalSign for this root but are In the process of migrating that inhouse. > Jakob: Does GTS sign regularly updated CRLs published at the (GlobalSign) > URLs > listed in the CRL URL extensions in the GlobalSign operated non-expired > intermediaries? At this time Google produces CRLs and works with GlobalSign to publish those CRLs. > Jakob: Hopefully these things are answered somewhere in the GTS CP/CPS for > the > acquired roots. This level of detail is not typically included in a CPS, for example, a service may change Which internet service provider or CDN service they use and not need update their CP/CPS. > Jakob: Any relying party seeing the existing root in a chain would see the > name GlobalSign in the Issuer DN and naturally look to GlobalSign's > website and CP/CPS for additional information in trying to decide if > the chain should be trusted. The GlobalSign CPS indicates that the R2 and R4 are no longer under their control. Additionally given the long term nature of CA keys, it is common for the DN not to accurately represent the organization that controls it. As I mentioned in an earlier response in the 90’s I created roots for a company called Valicert that has changed hands several times, additionally Verisign, now Symantec in this context has a long history of acquiring CAs and as such they have CA certificates with many different names within them. > Jakob: A relying party might assume, without detailed checks, that these > roots > are operated exclusively by GlobalSign in accordance with GlobalSign's > good reputation. As the former CTO of GlobalSign I love hearing about their good reputation ;) However I would say the CP/CPS is the authoritative document here and since GMO GlobalSign CP/CPS clearly states the keys are no longer in their control I believe this Should not be an issue. > Jakob: Thus a clear notice that these "GlobalSign roots" are no longer > operated by GlobalSign at any entrypoint where a casual relying party > might go to check who "GlobalSign R?" is would be appropriate. I would argue the CA’s CP/CPS’s are the authoritative documents here and would Satisfy this requirement. > Jakob: If possible, making Mozilla products present these as "Google", not > "GlobalSign" in short-form UIs (such as the certificate chain tree-like > display element). Similarly for other root programs (for example, the > Microsoft root program could change the "friendly name" of these). I agree with Jakob here, given the frequency in which roots change hands, it would make sense to have an ability to do this. Microsoft maintains this capability that is made available to the owner. There are some limitations relative to where this domain information is used, for example in the case of an EV certificate, if Google were to request Microsoft use this capability the EV badge would say verified by Google. This is because they display the root name for the EV badge. However, it is the subordinate CA in accordance with its CP/CPS that is responsible for vetting, as such the name displayed in this case should be GlobalSign. Despite these limitations, it may make sense in the case of Firefox to maintain a similar capability. _______________________________________________ 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
