> 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
