Eddy Nigg (StartCom Ltd.) wrote: > OK, so in that case KISA itself is becoming an auditor. Would KISA then > issue audit reports about the various CAs in question? What would be the > pros and cons of having each licensed CA approved instead of KISA as a > "wild card" CA for a whole country?
One major issue is that as a matter of policy we don't do inclusion of certs for subordinate CAs; we just approve and include roots. If we were to explicitly require evaluation and approval of subordinate CAs (leaving aside for the moment whether this is a good idea or not) then consistency would require that we do this for every CA, including commercial CAs. Consistency would also require that we do this for every subordinate CA in a root's hierarchy, no matter how far down in the hierarchy it was. For example, suppose for a given root CA R we evaluate and approve all of R's subordinate CAs S1 to Sn, and a given subordinate Si then issues multiple subordinate CA certs in turn, perhaps enterprise CAs operated by individual companies. By the same logic that prompted us to evaluate all of the root's subordinates for inclusion, we'd have to evaluate and approve all of the enterprise CAs as well. I personally think this is both unworkable and unnecessary, even if we were to restrict this to direct subordinates of roots. See also below. > KISA is a CA authorized and commissioned by the their government, > however the operating CAs are not government CAs, but regular CAs with > commercial interests etc. So this makes it a bit tricky I think...As I > proposed earlier already concerning independent CAs operating under a > unified CA root, but which are independent companies and the sole > purpose of the CA root is to act as an anchor, each CA should be audited > explicitly on its own or each CA should be at least explicitly > confirmed. Thoughts? My main thought is that our current policy does not explicitly address either auditing of subordinate CAs or approval of subordinate CAs. I have no problem with looking at overall audit-related issues as part of evaluating a root CA for inclusion. However to condition root approval on the exact details of how subordinates are audited (e.g., whether we prefer to see audits done by a third party vs. audits by the root CA itself) is IMO trying to stretch the policy too far. Yes, we have a general provision in the policy regarding not including roots where it "would cause undue risks to users' security". However as the person who wrote the language into the policy, I can tell you that it was not intended to condition overall root approval on our evaluation and approval of every aspect of how a CA hierarchy operated; it was rather intended to cover egregious security problems that might occur at a CA (as implied by the example violations I chose). I personally don't think having independent subordinate CAs be audited by the root CA (as opposed to by a third party) is an example of an egregious security problem sufficient for us to invoke this policy provision. Rather than trying to evaluate and approve an entire CA hierarchy up front (including all subordinate CAs), I think it is better to operate on an exception basis: We evaluate and approve roots, not individual subordinates. If it turns out later that there are security problems at a particular subordinate, and those problems are severe enough that we want to deny recognition of certificates issued by that subordinate, then from a technical point of view we have the ability to do so: We can pre-load in NSS the CA cert for that subordinate (and just that subordinate) and can mark it as untrusted. Frank -- Frank Hecker [EMAIL PROTECTED] _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
