Did you expect the genesis of Netscape to do anything else?

Hopefully we can do better in developing improved security technologies in the Jabber world...

Ian, a couple of brief comments: I apologize for not participating on the Mozilla security newsgroups recently; I've been involved in some other Mozilla volunteer work (not security related) and that plus work/family time has prevented my keeping up with the newsgroup. I see I missed a lot of (sometimes contentious) discussions, and regret I wasn't able to comment at the time.

There are three separate issues here:

1. The CA certificate policy. That's basically held up short of final adoption simply because Mitchell Baker and other folks at the Foundation (but mainly Mitchell) haven't had time to do final review on it. I'll ping Mitchell again on this, and if she doesn't have time in the short term I'll likely just adopt the new policy as an "interim" policy and go forward on that basis for now. (I've done this "interim policy" thing once before, and I have no problem doing it again if I need to.)

(Also, I've been stalled on CA-related work in general due to other demands on my time, so that's something I need to work on when I get time in the next few weeks.)

2. The Mozilla process for disclosing and fixing security vulnerabilities. That's basically the same process today as has existed for the past few years. Yes, there's a closed group that deals with such issues, and you can read my comments elsewhere for why that is; the major membership of that group is people who have a good track record of finding Mozilla vulnerabilities and cooperating with the project, Mozilla developers who can fix vulnerabilities, and Mozilla distributors (e.g., companies/organizations creating Linux distributions) that need to ship the fixed versions.

Almost all of the vulnerabilities with which the group deals have nothing to do with PKI, so I think your comment that "in their minds, security is synonymous with PKI" is misleading at best.

However I think it is fair to say that the security group dealing with vulnerabilities is first and foremost concerned with reacting to vulnerabilities narrowly defined. The group was not originally chartered and does not function to do forward-looking design and development of security-related features, including anti-phishing features. I agree that the project does need more central coordination of such security-related work; not having a single person to do that is a problem, one which the Mozilla Foundation needs to address. (And to my knowledge the Foundation knows it needs to address it, it's mainly a matter of finding the right person or persons for the job. And I should add that the person is almost certainly not going to be me.)

My personal opinion is that it is a mistake to think of the Mozilla security group (the group dealing with vulnerabilities) as the preferred forum for dealing with design and development of new security features. It has never filled that role in the past, and IMO will not do so in the future. It is true that a lot of the people in the group also do (or at least have done) development of new security features, but that's independent of the group itself.

The problem again is that the lines of communication regarding security design issues and the ways in which design and development decisions are made are not clear, and depend a lot on informal relationships among and with the various developers who are involved in the various parts of Mozilla/Firefox/Thunderbird. There was and is no overall intent to do stuff in "closed rooms", but in practice it is certainly not clear for people outside the process how and where to influence the process. Again, I agree that work needs to be done here to centralize and clarify things both within the project itself and to others outside the project.

3. The CA/browser vendor discussions. To clarify a couple of things: The CAs who initiated these discussions and who are involved in this are all traditional commercial CAs; I don't think CAcert.org was singled out for exclusion, the discussions exclude government-associated CAs, other non-profit CAs, indeed every CA that's not in the stated business of selling SSL certs to ecommerce businesses.

What is basically going on as I see it is that these traditional CAs are trying to make themselves relevant with regard to the phishing problem, along the lines of what we've publicly discussed in the Mozilla newsgroups: make CA branding more prominent, have different levels of certificates (including certs with significantly more subscriber vetting than is done today, and so on) and make distinctions between different types of certs in the browser UIs, and so on. There are conflicts between CAs as to exactly how to do that, and of course they need the browser vendors' assistance if such distinctions are actually to end up in the browser UI.

I personally don't see this as solving the phishing problem in and of itself, just as one more possibly useful approach among the various possibly useful approaches that have been proposed. I think it's perfectly appropriate for work in other areas to go forward, and I think the Mozilla project should consider implementing multiple approaches.

As a final comment, I'm sorry you've gotten discouraged your interactions with the Mozilla project in this area. As I've written to you before in other contexts, I think your concerns are valid in some areas and overstated in others. To the extent that I get involved in these issues, I will see what I can do to address the valid concerns of you and others.

Some supplimentry thoughts to go with Ian's on the CAcert Blog: http://blog.cacert.org/2005/07/81.html