After 18 months, "laziness" and "lack of time" are euphemisms for "complete disinterest." What you seem to be saying here is "wait a little longer, things will change." I think that this is unhelpful as it encourages CA-Cert to continue dealing with MF when, if we're honest about it, CA-Cert would benefit from focusing their efforts elsewhere.
I know it's easy to believe that there's some sort of conspiracy (e.g., between the Mozilla Foundation and commercial CAs) to keep CAcert's certificate out of Firefox, etc., but I am not a party to such a conspiracy. You might say in return, "of course he'd say that, that's the way conspiracies work". I can only refer you to others who have had dealings with me -- including the people participating in this forum, any of whom you are welcome to email privately -- and they can give you their unvarnished opinions as to the extent to which you can trust me to speak the truth (at least as I see it).
Now, assuming that you're not totally discounting what I have to say, here are my personal views on the CAcert issue:
The basic problem is that CAcert is attempting something new and a lot of people find that disconcerting and potentially dangerous, because it doesn't necessarily fit into the traditional CA model that they're used to and have been working with for many years. There's also the issue that because in some ways CAcert is more transparent than a traditional commercial CA, people know more about CAcert-internal controversies and the like, and this further reinforces any concerns they might have already had.
Again, you may believe this or not, but even though I am designated by the Mozilla Foundation to handle the task of approving CAs for inclusion in Firefox, etc., I cannot simply arbitrarily dictate, "yes, CAcert should be included". The Mozilla project is not a top-down dictatorship where the Mozilla Foundation issues orders and everyone meekly obeys; it's also not like a company where the Mozilla Foundation can issue orders, fire anyone who disobeys, and hire new people to replace them. If the decision in question is controversial (as is this one) then we have to work through the controversy to try to build a rough consensus around some sort of position that's at least minimally acceptable to the people who care about the issue and have a stake in it.
(Historical note: We went through a analogous exercise trying to decide what sort of policy we should have with regard to disclosing security vulnerabilities. I and others were sympathetic to the "full disclosure" position, but we couldn't simply dictate such a policy, because there were key Mozilla developers and corporate sponsors who were viscerally opposed to full disclosure. Instead we had to engage in a long drawn-out effort to reach a compromise -- which eventually we did.)
I don't think it's any secret (based on my past postings to this group) that I am sympathetic to the idea of non-profit "community" CAs in general, because I don't think the traditional PKI approach has necessarily served typical users well (for various reasons I don't have time to go into right now), and I think alternative approaches deserve some consideration. Given that, how should I proceed with regard to non-traditional CAs in general and CAcert in particular? I can't just say "yes, let's include CAcert"; I have do things within the framework of some justifiable policy.
Here are some possibilities for such a policy, in rough chronological order of my having considered them:
1. We adopt a laissez-faire approach where we include certs for any CA that requests it, subject only to some minimal requirements (e.g., related to CA disclosure). This is similar to Ian Grigg's position on accepting self-signed certs and "opportunistic crytography". While I respect Ian's opinions (even when I disagree with him), I can tell you that this approach is a "non-starter" in the current environment, just as adopting a 100% full disclosure policy was a non-starter at the time that we were formulating the policy on handling Mozilla security vulnerabilities.
2. We don't have a laissez-faire approach, but instead try to come up with some reasonable set of criteria that we (the Mozilla Foundation and the project in general) can use to evaluate CAs. I tried this approach, but the problem was/is that we got bogged down trying to formulate such criteria, particularly trying to do it from scratch. So this is a non-starter as well.
3. We go the traditional PKI route, adopt the WebTrust for CAs criteria as our standard, and require formal WebTrust audits. This is the position I retreated to when it become clear that creating our own criteria wasn't working, and I had a growing backlog of CA requests to deal with.
4. We loosen up a little bit on the WebTrust requirement, and allow for "WebTrust-equivalent" audits. This is the Microsoft policy, and it's also the interim policy I'm currently applying.
5. We formalize the "WebTrust or equivalent audit" policy, and do so in such a way that it allows for the possibility that such audits may be done by people other than the usual suspects (e.g., E&Y, KPMG, etc.) This is the approach I'm working on right now, and it's the approach that's motivating David Ross to look at doing such an audit for CAcert. The chief obstacles remaining are nailing down the language for such a policy, and reaching at least a rough consensus on proceeding with it. (There's also the issue of getting the Mozilla Foundation to formally adopt it, but I think that will be relatively easy if there's a consensus around the proposed policy.)
So that's basically where things stand. Some of the delay in getting to this point has been my lack of time, but some has also been due to my having to go back to the drawing board multiple times in search of a workable approach.
A final point: CAcert is not being singled out in having its application be left in limbo; there are a number of CA requests that are still in the pending state -- and may remain there for a while -- because they either haven't undergone audits as required by the current interim policy, or because I haven't yet had the time to conclude whether their audits can be considered "WebTrust-equivalent" or not.
That's basically all I have to say at the moment; feel free to post to this forum if you have further questions or comments.
Frank
-- Frank Hecker [EMAIL PROTECTED] _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
