Hi Frank, I agree with everything you said below for regular, standard CAs. This is what the policy knew when it was written. There is a CA, they have a root and some intermediate CA certificates (according to the recommendations after all), they are one entity taking responsibility for their CA business and PKI and there is mostly one infrastructure in every respect. The policy was written with that in mind (at least that's what its "spirit" is and the definitions are mostly about, don't tell me otherwise because it doesn't exist). As you correctly pointed out, there are no definitions about sub-ordinate CAs which aren't really part directly of the CA infrastructure, because the policy wasn't defined with that in mind. This is why I agree with the assessment of yours below, but under this condition.
I don't agree, when the CA acts as a boot strapping CA, where the CAs under this root themselves are effectively independent CAs, companies and PKIs. In such a constellation I view the bootstrapping CA, which itself doesn't have its own CA business and doesn't actively issue EE certs, but merely bootstraps other CAs, simply non-existent. The real CAs are the ones with their infrastructure and their CA business and its them which should get audited and approved accordingly. Neither do I agree with it for cases where the CA lets other CAs operate independently and which weren't audit accordingly (external CAs which operate outside the CA infrastructure should be specifically included in the audit report and the CPS should explicitly state this as a requirement). It doesn't help that you point to the Mozilla CA policy which was written for regular, standard CAs (It does more or less good job in that). There are no definitions for cases such as these (or others which came up or will come up in the future). That's why you yourself felt the need to ask about how to define "Audit requirements for government CAs" and that's why I asked in a different post "What we want". And because no definition exists and the policy wasn't written for such cases, or because of the lack of such definitions, it doesn't makes it right to approve something we don't want. That's why I asked about "What we want". Do we want to assure a certain standard and quality for CAs which are shipped with NSS or is it something else? If it's something else, than you should tell us about it. If it's the former then either we have to define it in the policy or act accordingly and on a case to case basis with rules which make sense. I really want to know the guidelines about "What we want". What are the principals guiding us. Once we know that, we can take our arguments accordingly. Some more comments below.... Frank Hecker: > 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. > No, because we should define and make differences about what we view as a CA. KISA isn't a regular CA, it acts as a bootstrapping CA commissioned by the South Korean government to oversee the rules and laws of that country. In my point of view, this CA has nothing lost in NSS, because as to *my* definition, it is not a CA in terms we know it. > 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. > CAs which let other CAs operate under their root independently outside their own CA infrastructure, must provide an audit confirmation and require such audits as a requirement in the CP/CPS. This is what auditing is all about. > > My main thought is that our current policy does not explicitly address > either auditing of subordinate CAs or approval of subordinate CAs. Exactly! And it's also not needed for CAs which operate their intermediate CAs within their PKI. This is what they do and this is what their audits confirm. > > 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; Correct! However you didn't address government and boot strapping CAs either. Nor did you address cases when CAs are not operating within the audited infrastructure. Because there is no provision for it, it doesn't makes it right to approve such a CA, if our goal is to warrant a certain level and quality. > 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. > Which is however effectively circumventing the audit requirement itself. So why request to have CAs audited, if in effect this isn't done? Why is there an audit requirement in first place? What did you wanted to achieve with this requirement when you wrote the CA policy? Because you wanted to receive a confirmation and opinion about the CAs in questions and govern a certain control over the CAs in NSS or did you wanted it for other reasons? > 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. This is correct for regular, standard CAs. This is what we know, this is how the Mozilla CA policy was defined. > If it turns out later that there are security problems That point would be too late already, except that I don't believe that such actions would happened. I don't propose to reload every sub CA certificate. However when effectively the sub CAs are actually CAs, than the requirements for CA should be kept, exactly as the policy envisioned. -- Regards Signer: Eddy Nigg, StartCom Ltd. <http://www.startcom.org> Jabber: [EMAIL PROTECTED] <xmpp:[EMAIL PROTECTED]> Blog: Join the Revolution! <http://blog.startcom.org> Phone: +1.213.341.0390 _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
