By definition, a CPS is the authoritative document on what root certificates a CA operates and how they go about that operation. If the GlobalSign CPS has been updated to reflect the loss of their 2 roots, that's fine. Nobody is questioning that.
What is being questioned is whether updating the GlobalSign CPS is sufficient to address the needs, concerns, questions, or myriad other issues that are likely to come up in the minds of GlobalSign subscribers and relying parties--and, for that matter, Google's own subscribers and relying parties. To that, I think the answer must be: "no, it's not enough". Most people on the internet have never heard of a CPS and of those who have, few will have ever read one and fewer still will have read the GlobalSign CPS. It would be good if you could elaborate more on what steps Google will be taking to communicate to the general public that GlobalSign means GlobalSign except when it means Google and that sometimes Google will mean GlobalSign as well. On Wed, Mar 8, 2017 at 12:02 PM, Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > 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
