‎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 

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 
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 

> 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 

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 mailing list

Reply via email to