First of all thank you for your reply! I understand that each such mail is an effort and consumes time (know it from myself). I appreciate it!
Frank Hecker: > > 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. > Well, yes, at large you are right. It hasn't gone much worse since then, most practices existed already in 2005, including DV certs and for example StartCom makes a special point in that respect (also started in 2005 interestingly). But as now more and more CAs request to be included, more and more unknown practices are coming up and for example with Comodo's ten year DV certs, this isn't something you could deal back then (which would have required to do something about it, a position Mozilla couldn't take. But things have changed...) But what I meant to explain is, that development of the software has continued, specially in relation to SSL, but the policy remained static and hasn't undergone a similar process. The trust in public PKI and the browser was lost with some people already back then, so nothing made a difference for them with the Mozilla CA policy. What I think we should try to do, is however to strengthening this model somewhat in order to gain some trust back. When we detect a flaw, we should respond. I'm not wearing devils cloth, but I'm looking at what we do here from where I stand and I saw some problems. I'm not saying to get rid of DV certs or nonsense like that, but I'm proposing to maintain a certain pragmatic and reasonable level of security, one I feel is responsible. If that requires sometimes to insist on certain points, than we shall do it, I think... >> 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. > This is certainly correct if you look at the browser as a whole. But what we are doing here is as you said correctly solving a typical and specific problem. This is what we do here and this is our field of expertise. Of course other aspects of the browser might be even more important, but I don't deal with it. There are other experts which deal with it, I deal with cryptography, PKI and CAs, that's why I'm here. > 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. > Agreed 100%! > (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.) > Outshhh, I don't like to even get into this one :-) Except that they are using some kind of PKI and I'm not sure what's so exceptional or new with it. > 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. > Yes, this is/was my understanding too. What I think/feel/proposed is, that there are limits even to DV certs, which we should try to adopt. >> 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. > Which is a standard Mozilla adopted. Mozilla could have adopted a different approach or standard and achieve the same or better effect. But this is what was decided and it's an improvement because Mozilla decided make it one. Similar Mozilla can decide to make other improvements, it's up mainly to us I guess. Not doing so or being passive is also kind of a decision which is made by Mozilla. > 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). Which I personally view as a mistake, because I believe DV and IV/OV certificates should be separated. Again, this is a decision Mozilla is taking, being it passively or actively. I'm not going to propose now how this could be done or what it implies, but I know for a fact that many web sites of banks (specially in the US) are using DV certs. Additionally I'm absolutely not sure if EV will become that mainstream, so that we could skip IV/OV certs and simply throw them together with DV (or stop issuing them altogether). If EV doesn't become mainstream and will replace IV/OV certs, than Mozilla (and the industry) will have to come up with some better answers and address this particularly. > 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.) > Which might be a bug. At least on Linux it's yellow in FF3 as it was for a long time. > 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. > Currently the ratio of EV certs is below 1% of overall SSL secured web sites. If EV doesn't get a significant market share, your priorities might have been wrong and we should have addressed other issues as well. (Concerning me: For now I'm fine with that and I have no problem with it. Quite the opposite, I never objected to an upgrade to EV status of any CA and there were no reasons to do so. The issue with Comodo is related to the non-EV certs) > > 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.) +1 > 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. > Yes, this sounds correct to me. > 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. > This is not how PKI and CAs work generally. You simply don't say: "OK, lets try it this way and if we see a problem we change". No, CAs generally work exactly the other way around. Let me make an extreme example: Currently there is no requirement about how issuing CA certificates are stored on the online systems (EV does that however). Therefore CAs can store them on the file system until you adjust your thinking. When in the software world an exploit is detected, the software is usually patched. When an exploit is detected in NSS, it's going to be patched. If however an exploit is detected by a CAs procedure you propose we do nothing until you are convinced that actually somebody is exploiting it and than you propose to adjust the thinking about the proposed threat. Really Frank? This is exactly why I have a problem here lately! This is exactly the opposite how CAs should and do work. This is the opposite of how developers are coding their software (to make a parallel example). This is exactly the opposite of what we should do here.... What's the use of all this secure protocols and strengthening of the software (remember that we disabled SSLv2, added OCSP?) if CAs are issuing certificates in an irresponsible way, CAs remain unaudited etc etc... > 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. Well, you know about what's going on in the CA world specially when evaluating CAs. I haven't found a better way to learn exactly that, by evaluating other CAs, being it here at dev-crypto or being it for StartCom. That's when the issues pop up and you have one of the best tools to exactly know what's going on in the CA world. One "isolated" example is one to much! > 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). > Yes, I really would like to see that happening. We need experts in this field, the same way Mozilla has experts for other fields. > 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. > OK, so we are going to discuss this and other issues? Are we going to setup a working group, time table, policy for changing the CA policy? Are we going to have experts in this field? > 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. > As to your example: Certainly worth thinking about and defining 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. > OK. Again thank you for your time. I'm trying to understand how all this relates to me and how I should approach future inclusion requests in the comment period (if at all). Personally I feel that on the issues which seem important to me we are not in agreement. And I'm still not sure exactly what is it that we want...also some questions I asked remained unanswered. -- 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
