Eddy Nigg (StartCom Ltd.) wrote: > 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. <snip> > 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.
Maybe I'm missing something, but I don't think this situation is unique to KISA. I believe there are commercial CAs, including CAs already in our root list, that issue CA certs to independently operated CAs. 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. 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. 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. > 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). I evaluate requests according to the policy we have, not the policy you (or anyone else, including me for that matter) wish we had. As I've written before, if the policy doesn't address certain issues that arise in the context of individual CA requests, 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. If we want to change the policy in future, that's a separate discussion, and I believe it should be a general discussion that reflects a wider base of information about current CA practices. We've already had instances where we thought one CA was doing something problematic and considered singling them out for it, and it turned out that the practice(s) were not unique to the CA. Getting back to KISA, I did indeed look at what the LCAs were doing and what sort of regulatory and auditing regime they're subject to. I saw no issues there that would justify my rejecting KISA's request based on our current policy, whether that be the explicit requirements of the policy or the more implicit requirements related to protecting user security. I therefore plan to approve KISA's request as soon as the other issue gets resolved about the audit of KISA itself. > 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" Right, but that was for the purposes of discussing future policy changes, not for the purposes of evaluating the KISA request in particular. That's exactly why I started a separate thread. > 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. This is better addressed in the separate thread you started. >> 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. This is better responded to elsewhere as well. It's part of a more general discussion about the respective emphasis we should put on prevention of potential problems vs. detection of and response to actual problems. Frank -- Frank Hecker [EMAIL PROTECTED] _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
