Here are my initial attempts at a policy and accompanying FAQ:
http://www.hecker.org/mozilla/certificate-policy/ http://www.hecker.org/mozilla/certificate-faq/
The FAQ is incomplete; I want to do a section on rationales behind the policy, but haven't had time to do a proper draft yet. However I can describe here some of my motivations and rationales for the policy approach I personally prefer; think of this as a first draft of the rationales FAQ:
* After doing a couple mozilla.org policies, I've decided I like to keep the policies themselves relatively short and general, and push detailed discussions into the FAQ. Hence the particular form I've chosen. For purposes of discussion you can consider the "policy" in toto to be the policy document itself supplemented by the guidance provided in the FAQ.
* As a public project we need a policy and associated decision process that is relatively transparent. However at the same time I don't want to over-specify things in the policy (see also above) and would prefer to leave some flexibility for the application of human judgement by whomever is charged with making the actual decisions (whom I'll refer to as the "evaluators" in the discussion below).
To take one example, at a high-level I think it's appropriate to take CA-related risks into account in making decisions, and at an intermediate-level (as specified in the FAQ) I think it's appropriate to evaluate how well CAs do in protecting signing keys and related material. However I don't think it is appropriate to mandate a specific approach to key protection; I prefer to defer to the evaluators' judgement.
* As I've previously mentioned in another post, I personally prefer a policy that evaluates not only CA-related risks and risk mitigation, but also potential benefits of including a CA's certificates.
Besides being a better approach in general IMO, I think such an approach is specifically suited to the situation the Mozilla project finds itself in: We have a lot of CAs whose certificates have been included as a matter of course in Mozilla based on their inclusion in Netscape 6 and 7, and IMO it's pretty unlikely that we're going to go back and give those CAs the same level of scrutiny we give new CAs.
IMO this is unlikely for three reasons: First, there are a lot of pre-existing CA certs, and we don't have a lot of resources to do CA vetting. I think most if not all attention will be focused on the more pressing issue of looking at new CAs. Second, if we do go back and vet already-included CAs, we have limited options for what we can do in the event we deem a particular CA to be problematic. As previously noted, it's difficult under the current scheme to "turn off" a CA cert except through the user's manual intervention. Finally, there are some CAs for which it would be very disruptive to users if we "turned off" their CA certs, given the large number of sites using their certs; so in practice I doubt anyone would ever seriously attempt to do this.
Given that in practice existing CAs are not going to have to go through the same process as new CAs, I believe it would be unfair on new CAs to impose strict requirements on them without at the same time formally considering the potential benefits of including those new CAs, and giving CAs a chance to make a positive case to us on why their certs should be included.
* One question that has been raised is why we shouldn't just defer to third-party judgements on CAs, e.g., WebTrust/AICPA, for legal reasons and also to take advantage of an already-defined and -operating process for CA vetting. First, IMO the legal argument is not nearly as compelling to me as others seem to find it, and as I mentioned in a previous post I have what I believe to be sound reasons for trying to do the right thing independent of specifically legal considerations.
Second, it is not clear to me that the goals embodied in the AICPA and similar evaluation processes overlap 100% with our goals in doing CA evaluation in the context of the Mozilla project. Therefore I think we should take AICPA, etc., endorsements into account, but not make them our sole criteria.
To expand on this point: Despite what people say about "Mozilla is now a real end user product", IMO Mozilla is fundamentally different than a commercial software product like IE or Outlook. It is in some sense an "experimental" product, not in the sense of being unfinished or bug-ridden, but in the sense that (IMO) one of the major goals of the project and product should be to help advance the state of the art of Internet technologies in general, including browsing and mail technologies in particular. I think this is to the ultimate benefit of Mozilla users, and I think Mozilla users should take this into account when deciding whether to use Mozilla or another alternative product.
Now in the case of PKI-based systems, my personal opinion is that the traditional approaches have in many ways favored the ideal at the expense of the real (I see this very much in some of the Federal PKI efforts I've been involved in), and have taken a very commerce-centric and legal-centric approach to the CA issue. I believe that these factors and related ones have arguably hindered both innovation in and adoption of more secure systems for the "ordinary" end user applications (browsing, email, etc.) that are at the heart of the Mozilla project.
Therefore I do not want to simply adopt wholesale or replicate existing CA evaluation criteria that come from this traditional approach, but would much prefer that we have a more flexible policy in deciding which CA certs to include in Mozilla, one that is more in tune with the nature of the project and its goals.
That's all my comments for now. Please respond with comments in this forum. Besides asking for comments, questions, objections, etc., on the actual policy issues, I'd also like a technical critique on the part of the FAQ that provides background information. My goal is for that part of the FAQ to give a solid grounding in the underlying issues for Mozilla users who are not that knowledgeable about PKIs and CAs, so that such users can understand what the policy discussions are actually about. (And of course if you want to contribute new questions and proposed answers for the FAQ I'd be more than happy to consider including them.)
Frank
-- Frank Hecker [EMAIL PROTECTED] _______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
