Eddy, thanks for your elaborate answer. I have only a few questions (I'm still learning... ;-) )
Eddy Nigg schrieb: > > 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. Can we say that it is neccessary (but not sufficient) to get included if you have "independent" sub-CAs that they are linked logically and legally to your root in a "sufficient" manner? Entities that are physically external seem to be quite common (Enterprise CAs) > The audit requirement is not a privilege, but a > condition. I agree with that. The Mozilla CA Certificate Policy is clear on that point. > 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. So it has to be explicitly stated in the audit report, or is it sufficient that it is covered in the CP/CPS and the auditor raises no objections? > 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. I agree with that, previously I thought: The auditor also monitors the operations of the root CA - not only the documents that describe how the operations are carried out, i.e. CP and CPS. During such an audit the presence of external sub-CAs would appall to the auditor, and he would object if this is considered wrong/dangerous. But I completely get your point that there is no ambiguity on that point if the external sub CAs are dealt with in the CP/CPS. (And ambiguity is not a good thing for trust...) > 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. GlobalSign offers a product that lets you operate your CA externally under one of their roots, so I guess these Sub CAs exist but are not linked directly to the root CA in question but are in fact subordinate root CAs further down the certificate chain. There seems to be no limit to the length of the certificate chain. 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. That would be indeed interesting. Thorsten _______________________________________________ dev-tech-crypto mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-crypto
