Frank, in order to continue the discussion below I really want to understand first
1.) If our stated goal is simply to facilitate the inclusion of as many CAs as possible 2.) If the principals guiding us are limited to the Mozilla CA policy only 3.) And if is, what we want, simply to provide just a process for inclusion of CAs If it's #1 then perhaps I'd better not comment anymore because I might be obstructing the goal If it's #2 but not #1, I'd like to know if and how we can modify and update the Mozilla CA policy so that it's up to the task for the current inclusion requests (including this one). If it's #3 or all of the above, lets not bother seriously with the policy and process anymore, since the process is currently flawed to a certain extend and the policy not up to the task it was assigned to. If however our goal is to provide and warrant a certain level, standard and quality of certificates issued by the CAs included in NSS on which the users of Mozilla software can rely on and on the principal that CAs have to conform to certain guidelines (and "spirit"), rules and principals on equal footing and if we want to provide a reasonable level of security and reliance, than I'm glad to provide my expertise and experience on the subject. For the meantime some answers below... Frank Hecker: > > Maybe I'm missing something, but I don't think this situation is unique > to KISA. This situation is unique in that, that KISA is a boot strapping CA only. There were and are other such CAs (which requested inclusion), most of them are commissioned by their respective governments to oversee the rules and laws of that country. These are their laws and each country handles it differently. _KISA is not a CA which is covered under the Mozilla CA policy_ and we'll have to define the term CA and what we understand with this term when discussing here. > I believe there are commercial CAs, including CAs already in > our root list, that issue CA certs to independently operated CAs. Of which this is only part of their CA business. In that respect I'd suggest that such CAs must have a policy and or clearly fall under the policies of the parent CA and be audited as part of the CA infrastructure and have a stipulation in that respect in the parent CA policy. > If I > recall correctly, this is what our IT department did when I worked at > Netscape, namely run a Netscape enterprise CA using an > internally-operated CA infrastructure, with a CA cert issued to Netscape > by an external commercial CA. > Not arguing with that, however Netscape was most likely in a unique position. But one "wrong" doesn't makes it a "right". You are speaking here about something which happened some ten years ago. Not that I see a problem with it per se, but it depends how this is handled by the parent CA and which conditions and definitions we attach in that respect to the Mozilla CA policy. Auditing of the full CA infrastructure, including external CAs is a requirement in order guaranty the integrity of our set of CAs in NSS. Otherwise this would effectively circumvent one of the basic requirements of the Mozilla policy (See my suggestions from above). > So I don't think this is a question of government CAs vs. non-government > CAs, or even "standard CAs" vs. "bootstrapping CAs", it's part of the > more general question of how to handle subordinate CAs. No, I don't agree. If the intermediate CAs are used within the CA infrastructure to which the policies and audits apply, then we don't need any additional stipulation for that (in the Mozilla CA policy). I call this a standard CA such as StartCom is. If the sole purpose of a CA is to bootstrap other CAs (for whatever reasons, being it for commercial reasons or being it to govern a certain law), then the sub ordinated CAs are really CAs and we need a definition and agreed rules about how we want to handle it. > As I said, I > think there are CAs operating today, including commercial CAs, that in > some contexts act like "standard CAs" issuing end-entity certs out of > their own infrastructure, and in other contexts act as "bootstrapping > CAs" enabling other organizations to operate their own CAs. I don't > believe that the distinction is as clear-cut as you suggest it is. > Correct and that's why we need to hold on for a moment and think about what we really want, what is sane and what we want to achieve with what we are doing here. At many organizations (including military, governments, companies and CAs) operations are stopped when a flaw is detected until a decision has been made about how to solve that flaw. You suggest however to pretend the flaw doesn't exist and continue as usual. Would you have been a air-force commander you would be putting your pilots at risk (just to give an example how this looks elsewhere :-) ) > > I evaluate requests according to the policy we have, not the policy you > (or anyone else, including me for that matter) wish we had. If the policy doesn't provide you with enough answers and definitions in order to make a clear decision, than it's perhaps your fault that you continue the process without fixing the policy. > As I've written before, if the policy doesn't address certain issues that > arise > in the context of individual CA requests, Then you should be guided by the stated goals and principals (which are not clear to me right now) and start to address the issues because they might come up again. > I am not going to hold up such > requests until we hash through all the details of changing the policy, > nor am I going to impose on the CAs making such requests new > requirements that go beyond the policy as it's written and as it's been > applied in the past. > Supposed a CA does something about which the policy doesn't provide answers, but which would effectively compromise the level of quality and security requirements of the CAs in NSS, than you would be acting irresponsible. For example auditing of CAs is a requirement by the policy, but as in this case, this requirement is effectively circumvented. Why should I agree to it? Lets get rid of this requirement and let the CAs save a few bucks then....either we require it or we don't. I'm completely against auditing by proxy and auditing where only the root CA is covered, but the real CA business is really elsewhere. -- 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
