On 10/02/2008 10:23 PM, Frank Hecker: > > Our goal here is to avoid having to evaluate lots and lots of > subordinate CAs, and instead have the roots take care of their own > subordinates and ensure they're compliant to policy. >
I'd like to pick this discussion up once again and evaluate what the goals of Mozilla and the Mozilla CA policy really are. Certainly the above is not the defined goal, but rather provide some reasonable assurance about the CAs included in NSS and Mozilla products and allow users to rely on - domain name control validation for web sites - email control validation for email - identity or organization validation for code signing - in case of EV, compliance to the EV guidelines - sound physical and logical security, controls, business continuity and other aspects as they are covered by the acceptable audit criterion Should any of the goals above not be that of Mozilla and its policy please speak up... > * Clear requirements for subordinate CAs for how information in > end-entity certs is to be verified, such that section 7 of the Mozilla > CA policy (http://www.mozilla.org/projects/security/certs/policy/) is > satisfied. I think this is implied by the policy itself, there is no need to add additional requirements. > > * Requirements for subordinate CAs in regards to whether or not > subordinate CAs are constrained to issue certificates only within > certain domains, and whether or not subordinate CAs can create their > own subordinates. I think this is implied by the above as well... > > * Audit requirements for subordinate CAs with regard to the frequency of > audits and who can/should perform them, as per sections 8, 9, and 10 of > the Mozilla CA policy. I really don't understand what's the fuss about having ANY CA to perform an audit or having been part of an audit (in case of wider PKI and signing scheme). With "CA" I mean including any entity which is physical and/or logical independent. Or is NSS just a football club or barbecue party..."bring as many friends with you, everybody is welcome"?! Or is NSS a Web-of-Trust scheme where members validate other members, aka PGP? Or shouldn't have any to-be-admitted CA undergone some vetting for their business practices? To make it clear about what we are talking.... - A CA should write and define a CA policy and publish a practice statement which is in conformance with the Mozilla CA Policy (see above). - A CA should implement its policy and engage with an acceptable auditor, perform the audit and have its business practices confirmed. That's about all what the Mozilla CA Policy calls for... In case of T-Systems and other CAs issuing sub-ordinate CA certificates to third party organizations, those infrastructures should be either part during the audit of the parent CA or the CA performs an audit itself. I really don't understand what the problem is to have the audit INCLUDE all CAs under its root - including the CAs which are located and operated elsewhere...or should I rather say, SPECIALLY when they are located and operated elsewhere they MUST be explicitly audited and confirmed?! (What's the difference anyway between the a root and sub-ordinate certificate in regards to security, controls and business practices) Well, if a CA can't provide that, I don't want to have to rely on them! Because it means that CAs will be included indirectly without ever having undergone an audit - never seen a third party auditor at their infrastructure and have their processes and controls reviewed. Auditing is a good thing generally, it reveals shortcomings and other deficiencies sometimes which allows the CA to improve their infrastructure, additionally it confirms the CAs practices. The fact that there are now some 40-50 CAs waiting for inclusion has nothing to do with the defined goals. Or perhaps quite the opposite! Not every CA knocking at Mozilla's doors must be included just because they asked for it. They need to prove that they comply to the policy and this can only be done by providing a CP/CPCS and auditing. Otherwise we should clearly define the goals differently and rewrite the Mozilla CA Policy. -- 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
