Thorsten Becker: > In Bug #378882 Eddy Nigg directed me here because of a SubCA audit > question: He states that root CAs in mozilla NSS must "Not circumvent > the audit requirement set forth by the Mozilla CA policy. > This means that the CAs which belong to this PKI and are under this root > MUST > be part of the audit. CAs themselves can't be the auditors, otherwise > all CAs > will audit themselves." > > That was an answer to a questions to the requirements to T-Systems to > get their root accepted. I compared the practices of T-Systems to that > of GlobalSign, that offer a service to Enterprise CAs that allows the > Enterprise CAs to operate as SubCAs indepependently under the root of > GlobalSign: > http://eu.globalsign.com/pki/rootsign.htm > > According to the Info-Gathering-Document in Bug #406794, which covers > the renewal of the GlobalSign root, GlobalSign does just do what they > shouldn't do according to Eddys comment: They audit external SubCAs > themselves, as stated in the bug/info-gathering-document: > "[...] As a CA is then run by an enterprise, domains are not technically > restricted, however domains are contractually restricted. > > *GlobalSign* audits periodically as part of our own brand protection > program. [...]" [Emphasis added] > > So isn't GlobalSign doing something here that is very problematic? >
Hi Thorsten, Let me add a few things here in order to make it clear what I meant: The Mozilla CA policy requires auditing of the CA and its infrastructure. In the past there were various requests from CAs which don't issue themselves end user certificates, but issue (sub) CA certificates to entities external to them, both physical, logical and legal. Those CAs were not included if the audit didn't cover the issuing CAs for the obvious reason, that otherwise CAs acting as roots for the sole purpose of issuing CA certificates to others and therefore by transferring the responsibilities to third parties would circumvent the audit requirement. The audit requirement is not a privilege, but a condition. Now, to all of my knowledge, this condition has been applied at other inclusion and upgrade requests, most notably with Comodo just recently. CAs may issue subordinated CA certificates to third parties on a contractual basis, however the audit must cover those. This is made clear usually in the CP/CPS of the CA in such a way and the auditor has to confirm that. As a matter of fact, the auditor confirms the CA/CPS of the CA and if your CA policy doesn't have any requirements to the third parties, then the auditor doesn't have to confirm it either. It would be then very easy to found a "straw-CA" which conforms to its own policy and have that confirmed by the auditor, but the actual issuing CAs wouldn't have any requirements whatsoever. Effectively the issuing CAs would never see an auditor anywhere near them, nor would the controls (if any) and issuing procedures be ever confirmed by a third party. This goes counter to the audit requirement of the Mozilla CA policy. Concerning GlobalSign this problematic practice has been highlighted by Frank here: https://bugzilla.mozilla.org/show_bug.cgi?id=406794#c19 I don't remember the discussion of GlobalSign's request explicitly, but the entry at the pending page [1] states: "The first root has two subordinate CAs (for domain-validated and organizationally-validated certificates respectively) and the second root has one subordinate CA (for extended validation certificates). (There is also a valid chain from the EV subordinate to the first root via a cross-signing certificate.)" Apparently GlobalSign either doesn't have any externally operated CAs or they were part of the scope of the audit. In addition to that, this CA has been included previously and the request was to enable EV and replace the already included certificate with the same key, but longer life-time of the certificate. Most likely Frank can recall the considerations for approving this request. [1] http://www.mozilla.org/projects/security/certs/pending/#GlobalSign -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
