During the year 2005 the Mozilla CA policy was defined, mostly as a result of CAcert's request to have their CA root shipped with NSS and I remember the initial drafts, which were published at Franks personal web site very good. This was a process I closely followed from the sidelines since it had quite some relevance for the StartCom CA which I just founded back then and its operations I still directly oversee today.
The Mozilla CA policy was the first published policy by a software vendor which included some detailed requirements, specially ones seemed to be important at that time. Other vendors had very vague requirements, mainly that of a WebTrust audit, some had none. And in that respect Mozilla lead the way for all other vendors, as today Microsoft and even Opera have policies with specific requirements. One of the more important aspects of the new Mozilla CA policy was the definition of alternative auditors beyond WebTrust accredited ones and effectively removing the WebTrust tax for CAs (Also a concession to CAcert, which however also poses some risks). The accepted criterion remained the same ones which were and still are considered industry standard. Additionally some specific requirements and some recommendations were included. Thanks to Frank's pragmatism and willingness to facilitate the inclusion of CAcert, StartCom took this opportunity with both hands by closely following the requirements and recommendations of the evolving policy. During the years 2006-2007 the EV criteria evolved with the support of some major CAs and browser vendors, which Mozilla eventually adopted and voted in favor. There are perhaps multiple reasons for the creation of the EV criteria and each party is supporting it for its own reasons. Since the creation of Firefox, the handling of SSL certificates by the various Mozilla softwares (browsers, suites, mail etc) had hardly changed and remained mostly static. But the development for Firefox 3 introduced suddenly many changes, most likely due to the arrival of the EV criteria, but also for the desire to improve security and online experience of its users. Firefox 3 looks differently at SSL errors and the UI changed in many ways (not to mention many improvements in the NSS library itself). With very little tolerance and rigorous checking of SSL secured sites, Firefox 3 is going to be a great improvement after years of stagnation. But our Mozilla policy hasn't kept pace with the developments of the CA industry and that of its browser, except the addition of the EV criteria. Effectively the Mozilla CA policy remained static since its introduction, which is perhaps desirable (that a policy doesn't change every here and now). On the other hand, since its introduction, some CA practices by some CAs have gone dangerously low and more and more CAs knock at Mozilla's door and request to be included and shipped with NSS (the later is just fine if there weren't sometimes for the problems and some dubious practices involved). Today I feel, that the Mozilla CA policy and the inclusion process isn't fully up to its task for various reasons. Specially also because of the advancing of the software I feel that the policy hasn't kept pace. What's the use of effectively blocking access to a web site which is perhaps wrongly configured, when on the other hand CAs are given a free hand to do as they wish? During my short involvement with this team and specially during the last ten month I've encountered countless policies, practice statements and implementations for which the Mozilla policy doesn't provide answers, but which were nevertheless risky, to say the least. Additionally I have the feeling that there is flaw in the "review" system, because if it wasn't for me and the public comment period, _we'd have today CAs in NSS which weren't audited at all and which wouldn't have any requirements whatsoever placed upon them_ (like the bare minimum of domain/email validation). And because of that I'm asking the community, this team and the Mozilla Foundation, what is it that we want! There is no road map in place which would provide some guidance. There is no clear vision about how and what we should do (except that there is a policy and we accept requests on an ongoing basis). And I'm not even sure that anybody besides me sees any need to introduce changes and improvements at all. Not surprisingly, I don't see many others involved really. Instead the amount of requests for inclusion has dramatically increased since the introduction of the policy, but the responsibility and decision remained placed upon one person only (First Frank, then Gerv and now Frank again). During all that time, the only CA which has drawn some fire during the comment period was StartCom, which in itself might be understandable because of StartCom's position and unique approach (CAcert + some commercial CAs weren't all that happy I guess). But haven't it been for my involvement during the last time, there wouldn't be any second opinions and no second reviews of CAs whatsoever. This in itself is an unhealthy situation, not because Frank (and Gerv) do a bad job, but because people do make mistakes and tend to look at things differently. In the absence of better definitions (and recommendations) by the Mozilla policy, many times a decision must be taken on different issues based on...one persons point of view. Updates to the Mozilla policy are delayed indefinitely, no working group exists, not many consultations are taking place (if at all). And for me personally, willing to invest time and effort, but instead of contributing my expertise and experience I'm rather playing an opposition I don't want to play really, it has been somewhat unsatisfying. So what is it that we (and the Mozilla foundation) want? Is it correct the way we handle things here (basically Frank/Gerv proposing inclusion, Eddy reviewing and sometimes objecting, if not Eddy, nobody really will) or is there a better approach? Is it correct that decisions for updates to the CA policy are converted to recommendations which have no effect whatsoever when actually using them as an argument against inclusion of a CA (or request for change of said practice by the CA)? Shouldn't a group of experts review CAs and make decisions based on more than one persons opinion? Shouldn't a working group actively review proposed changes to the Mozilla CA policy and make decisions? So what is it that we want? We have an updated UI and improved NSS for FF3, but we don't have a really good inclusion process for CAs (note that the comment period is really unique and helpful, but it is missing the point if there is no real community actively reviewing the bits and bytes of the CP/CPS and other material of the CAs in question. Based on the comments I've seen during the last two years, serious work is basically non-existent). I came to the decision to write this mail and raise these questions, because I felt it somewhat pointless to provide my expertise upon the mail from Frank with the title "Audit requirements for government CAs", without defining what is it that this community and the Mozilla foundation wants before hand. I have no fun in playing an opposition to Frank just for the sake of it - and the last three CAs about which I raised some objections and the resulting discussions have left myself with questions, for which I feel I need some answers. What do you think? Is there room for such a definition (about what we really want)? Is there a need for it at all or is everything fine? Do we need to improve and change the ways things are handled currently? Should an experts group make the decisions for inclusion or should it remain as is? Should a working group be created for dealing with aspects of the Mozilla CA policy? Is the way we deal today sustainable over time? Other suggestions? -- 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 [email protected] https://lists.mozilla.org/listinfo/dev-tech-crypto
