Eddy Nigg (StartCom Ltd.) wrote: > 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).
It's a secondary point, but I don't automatically accept the proposition that CA practices have gotten much worse since we originally created our policy. That has to be demonstrated, not simply asserted. Some would argue that that the time that (commercial) CA practices actually got worse was between the time SSL was originally introduced and the time we created our policy. Certainly DV certs and related practices existed prior to our policy. > And because of that I'm asking the community, this team and the Mozilla > Foundation, what is it that we want! I can't speak for the community in general or for the NSS/PSM/Firefox developers, however I can speak for myself and at least to some extent for the Mozilla Foundation. I'll basically repeat here various things I said during the discussions leading up to the creation of the Mozilla CA policy. Basically we have a CA policy (and associated evaluation of CAs) in order to help protect the security of typical users of Mozilla-based products, with respect to product features that are PKI-based, taking into account the nature of commercial and non-commercial CAs as they currently function. To take those points in order: First, our ultimate goal is to protect users' security in general, not to deal with PKI-related security issues in particular. PKI and CAs are important only in so far as they related to typical security problems that occur in the real world with typical users. They are not themselves the only or even necessarily the most important security-related area. (For example, the investments made in enabling Firefox automated security updates and anti-phishing measures have arguably made a greater impact on end user security, since phishing is a major problem and browser vulnerabilities are actively exploited. By comparison, a lot of the threats we discuss in relation to CAs seem more theoretical threats, with not a lot of evidence that they are being exploited or likely to be exploited.) Second, our goal with respect to PKI is to support the standard legacy uses of X.509 certificates, most importantly with respect to SSL/TLS-enabled web sites accessed via Firefox and other Mozilla-based browsers (SeaMonkey, Camino, etc.), but also wrt other uses of SSL/TLS (e.g., for mail servers accessed by Thunderbird), uses of S/MIME in an email context, and use of signed code objects. Our goal is *not* to try to modify, expand, or replace the traditional model of X.509 certs issued by trusted third parties (i.e., CAs). For example, that's why the Firefox/PSM/NSS developers ultimately rejected the idea of supporting an SSH-like model for SSL through automatically acceptance of self-signed SSL server certificates. (As a side note, based on my experience with and reading about industry dynamics, I think that advances in PKI-related technologies are much more likely to occur in new protocols and new products than in mainstream cases like browsing SSL web sites. A good example is Skype's implementation of an internal PKI infrastructure for securing VOIP traffic.) Third, we need to take into account the CA industry as it currently is, not as we might wish it to be based on our particular ideas about how it should work. That's why we ultimately decided to implicitly "bless" DV certs by accepting CAs that issued them, despite the arguments of many people that doing (just) domain validation was totally contrary to what a CA should be doing. > There is no road map in place which > would provide some guidance. Here are some quick thoughts about where we might or should go from here: First, now that I'm using Firefox 3 beta full-time the importance of EV certs is clear to me. There's a real difference between using an EV-enabled site like paypal.com and a more traditional SSL-protected site like bankofamerica.com (which apparently has a regular OV cert from VeriSign). I think the EV UI is a real improvement as far as typical users are concerned, which is one reason I'm putting a priority on getting EV-related requests from CAs processed. I also think that with the advent of EV and the Firefox 3 UI that the world of certs will divide into EV and everything else (OV/IV/DV). Maybe I'm missing something, but I can't see any discernible difference between the UI for https://www.bankofamerica.com/ (OV cert) and the UI for https://www.hecker.org/ (DV cert). For that matter, at least on Mac there's not much difference between the Firefox 3 UI for those sites and the UI for non-SSL sites. (For some reason Firefox 3 on Mac OS X doesn't show the yellow background to the location bar that's used on Windows, so the only visual indicator of SSL is the lock and domain name in the lower right corner. I don't know whether this is a bug or was done deliberately as part of the Firefox/Mac UI work.) So my feeling is that in the longer term the most important types of certs for typical users may well be EV certs, with non-EV certs, even OV/IV certs, relegated to low-value uses, uses involving non-critical data, and/or uses for personal or small group sites. This is another reason why I prioritize EV requests. Second, in line with arguments by Bruce Schneier and others, I'd like to emphasize detection of and response to problems as much as prevention of problems, Traditionally there's been this idea that if we don't apply stringent criteria to CAs upfront then the whole system will break -- CAs will engage in potentially dangerous practices, subordinate CAs will run wild, anybody will be able to get a cert without proper vetting, fraudulent SSL-enabled sites will rapidly increase in number, the whole idea of PKI and CAs will be undermined, and so on. And then our only response is to pull roots and break every SSL-enabled site whose cert is issued under that root's hierarchy. Frankly this strikes me as poor security design if the whole PKI/CA infrastructure is this brittle; it reminds me of the US Transportation Security Administration shutting down entire airports if just one person gets through the security area without being screened. I think supporting OSCP checks as the default for EV certs in Firefox 3 is a major advance in terms of enabling more targeted responses to cert-related problems. (Turning on CRL checking by default would be good as well, and as I've said before I would be willing to sell the idea to the board of having the Foundation fund NSS work to support CRLDP or whatever else would be needed to do this.) There are other ways I could imagine us being able to have more targeted responses to problems. For example, I've previously mentioned the idea of handling issues related to subordinate CA certs on an exception basis, e.g., by adding particular subordinates as trust anchors if need be and then modifying the trust bits to limit what the subordinate can do. (I presume improved implementations of EKU support and CA constraints would also help here, and again I could make a case for the Foundation funding such work.) One argument given against this idea is that the response will be too late, the damage will already be done. This relates to the problem of detection: how will we know there's actually a problem in the first place? Back when we first created the Mozilla CA policy I challenged people to provide some data on whether, how, and how much the CA system was actually being exploited for criminal and fraudulent purposes. No real evidence was provided then, and I haven't seen any data since then either. Instead the idea seems to be that since we don't know what's going on we need to protect ourselves from every possible threat scenario we can conceive of. Again, this strikes me as misguided. If we don't know what's going on we need to try to find out, and if it turns out that nothing much is going on then we can adjust our thinking about these proposed threats accordingly. Third, following on from the previous point, I'd like to see us spend more time gathering information on what's going on in the CA world overall, as opposed to focusing on isolated examples that happen to arise in te course of evaluating particular CAs. This is clearly an area that will take some time and resources to do a good job; for that reason it's another area where I think it might be a good idea for the Mozilla Foundation to make an investment (e.g., hiring a contractor to help out or whatever). Fourth, I'd like us to have a general discussion of policy around a variety of issues that are beyond the bounds of the original policy, including government CAs, "bootstrapping" CAs, subordinate CAs in general, long-lived DV certs, wildcard DV certs, etc., etc. I'd like those discussions to be informed with better information about what's going on the CA world generally (per point 3 above), to focus on how to detect and respond to any problems, not just on how to prevent them (per point 2 above), and to take into account users' security in general, not just particular PKI/CA-related security issues (per point 1 above). For example (a thinly-disguised one): We evaluate a CA that issues EV certs and wants to have them recognized as such; however the CA also issues DV certs under the same hierarchy, including DV certs about which we might have security concerns (e.g., they have long lifetimes, use wildcards, whatever). Would the security of typical users be improved by having this CAs EV certs be recognized, enough to more than offset any potential security harm associated with the CA's DV practices? I can't absolutely prove that this might be so, but I also can't dismiss the possibility out of hand. Another (thinly-disguised) example: Typical users in a particular country use IE rather than Firefox because (among other things) Firefox doesn't recognize the major government-established and regulated CAs in that country. Would the security benefits of giving those users the ability to use Firefox be sufficient to justify our including those CAs' certs even though there are some open questions about how the CAs exactly fit into our policy framework? Again I suspect this might be the case, can't absolutely prove it, but certainly wouldn't reject it. My point (and I do have one, to quote Ellen DeGeneres) is that the Mozilla CA policy is just a tool, not an end in itself, and it doesn't exist in isolation from everything else in the world of Mozilla security and the world of CAs. If we're going to change the policy, I don't want to have us change the policy simply to address theoretical concerns and proposed threat scenarios of uncertain importance, and ignore any associated trade-offs. Frank -- Frank Hecker [EMAIL PROTECTED] _______________________________________________ dev-tech-crypto mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-crypto
