What do I want? I want a use-case which expresses why the certificate validation policies (as implemented by NSS) must be so draconian.
I want a use-case which expresses, clearly, why certificate validation problems have to be modal and completely disrupt the user's workflow. I want a use-case which expresses why certificates from unknown CAs have to show up as certificate validation errors in situations where there are no forms to harvest private information. (why not a 'pop-up' of "we don't know that this site is who it says it is, but we're letting you browse it anyway' -- which shows up on all pages under that certificate for the duration of the session, rather than just once at the beginning with no continual reinforcement?) I want a user interface which allows me -- at a minimum -- to see what CA signed a given certificate, how that CA is in my store (whether it was provided by Mozilla or the administrator or through my own action), the subject of the certificate, and the validity period of the certificate without having to click on "more information" and then scroll through the byzantine hierarchy of certificate fields. I want a policy in place which prevents situations such as the transition from Thawte CPS version 1 (which did not allow for domain-validated certificates) to Thawte CPS version 2 (which did allow for domain-validated certificates) without a new CA being created and vetted. I want, frankly, more transparency and usability from the software. And I want less pseudo-militaristic enforcement of the concept that CAs can get away with murder as long as they document what they're doing. -Kyle H On Sat, Mar 29, 2008 at 7:58 PM, Eddy Nigg (StartCom Ltd.) <[EMAIL PROTECTED]> wrote: > 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 > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto > _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
