On 10/02/2008 10:23 PM, Frank Hecker: > > Kathleen thinks, and I agree, that the best way to approach this both > with T-Systems and with other CAs in general is to ask the CA to update > the CP/CPS for the root to include language addressing the following: > > * 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. > > * 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. > > * 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.
It is basically a question of how those are audited. I'd suppose that a physical walk-through and evidence gathering at the premises of the sub-ordinate CAs must have taken place during auditing - and if needed shall be confirmed explicitly as such upon request by Mozilla by the auditor. This information isn't usually included in typical audit statements and we might need to ask for such a confirmation. It doesn't apply in case the sub-ordinate or cross-signed CA certificate is operated from within the root CA infrastructure and was audited as part of that PKI. The principal guiding us should be the audit requirements mentioned above and there shall be no CA included which hasn't undergone such an audit, being it as part of a root or in its own rights. A root shall not be included in case sub-ordinate CAs exist which haven't seen the face of an auditor at least once (not speaking about yearly re-auditing yet). Out of fairness, Mozilla requires a WebTurst or equivalent audit performed by CAs, which shouldn't be circumvented by cross-signing or sub-signing of CA certificates. > > 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. > Since the Mozilla CA policy clearly calls for auditing of the CA, I think that Mozilla will have to share the burden in cases the CAs in question haven't been part of such an audit and would like to apply in their own right. Not sure how many there will be, but in such a case it's simply a matter of implementing the policy. > P.S. One thing I asked for before at some point, and I'll re-ask now, is > a clear brief technical description on how root CAs would constrain > subordinates to issue EE certs only within certain domains, and also > prevent them from creating their own subordinates. I'd like to add this to > > https://wiki.mozilla.org/CA:Recommendations_for_Roots > > to provide some technical background for anyone interested. > I think path length should be 0 for such CAs. It's a requirement for the issuing CA certificate of EV certificates and makes sense also here. -- 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
