> 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

Reply via email to