Frank Hecker wrote: > Nelson B wrote: > > Gervase Markham wrote: <snip>
> Finally, let me consider some larger issues. Forgive me if I'm missing > something, but I'm getting contradictory impressions here. On the one > hand I get the impression that you and others believe that historically > there have been minimal problems (and hence minimal risks to users) > resulting from CA practices and the selection of CAs to be included in > the Mozilla default set. Now that I'm proposing this new policy I get > the impression that you and others believe it will result in significant > problems and significant risks to users, even though the sorts of CAs > and CA practices permitted under the new policy are AFAICT basically the > same sorts of CAs and CA practices that were permitted under the old policy. > > (The major exception to this is the possibility of including CAs like > CAcert.org based on non-traditional evaluations; but I'm not clear there > whether non-traditional evaluations are the sorts of your concern or > whether it's domain-validated SSL certs and other low-assurance certs.) > > The only way I can personally resolve this contradiction is to conclude > that it's not the policy in isolation which is at issue, it's the policy > in combination with the new environment in which protecting against > phishing has become a top priority. In other words, while existing > policies (which in practice permitted things like domain-validated SSL > certs) may have been good enough way back when, any new policy has to be > more stringent in order to counter the increased threat; it's not good > enough for us to just continue and formalize existing de facto > practices, we have to add some more requirements over and above what has > been done in the past. > > Is this what you and others are arguing? If so, it's a perfectly > legitimate argument to make. But if you and others want to make this > argument (i.e., that policy needs to be more stringent in this new > environment) then I believe it's incumbent on you and others to a) > propose in some level of details what more stringent requirements we > should actually impose, and b) explain how those requirements will > actually reduce the risks experienced by ordinary users. > > I think such a detailed justification is necessary because there are > consequences to adopting more stringent policies: We're talking about > eliminating (i.e., no longer accepting as valid) uses of things like > domain-validated certs that are currently in use (with apparently no > problems resulting), and closing off the possibility of such uses in the > future. We're in essence saying that use of SSL in e-commerce and > financial applications is our primary concern, that the risks associated > with SSL in such applications require us to adopt as stringent a set of > rules as we can, and that all other uses of SSL have to play by the same > rules, whether they make sense in other contexts or not. > > I know you're busy and don't have time to create such a detailed > justification, but I certainly wish someone would. I think there are potential applications of PKI outside phishing prevention and further that PKI by itself is not a perfect solution. There are plenty of things that could be done to improve the safety of netizens; some risks or aspects of risks can be mitigated by use of public key technologies. Different approaches and different applications could have different requriements. The root list management approach to date in MF and Microsoft has been, more or less, to identify the CA legal entity and require that they document their policies and practices and undergo an audit. Both Microsoft and Netscape used to charge a huge amount for inclusion in their root lists which ensured the CAs had something to lose if their brand was tarnished, but it also kept smaller CAs off the list (it may be worth noting that quite a few of the CAs commonly trusted have been bought or sold or gone bankrupt - what policies and practices survive change of ownership?). An advocate in nmpc suggests driving broader adoption of SSL by changing the trust model in combination with loading additional financial exposure on the CAs (ie make their brand/reputation suffer for their mistakes and weaknesses). Others advocate raising the bar for entry into the root list through other means. I think there is merit to both approaches. It seems to me that internet use is increasing and therefor so is the value to be garnered by criminals. I expect the approach criminals take will be path of least resistance and that the particular attacks will vary substantially to work around changes in the landscape. So what do we do? I don't expect we will find one new technology or enhancement to an existing technology that will solve all our problems. I think the right approach is to be practical and improve things even imperfectly. So to the topic at hand - what about the MF policy for PK root inclusion. My opinion is that there are many approaches we could take to improve the security proposition some will require a lot of work others less. The following are a few of my thoughts and suggestions. For practical reasons I think it is easier to be tougher on the admission and more lenient on the removal side as it is much more difficult to orchestrate a reasonable removal without unduly damaging innocents such as web site operators who chose a CA that was later removed from the trust list. I don't believe the bar can be set high enough on admission to the root list that it can be left unmaintained nor do I believe that any CA is capable of operating perfectly against strong policies such that thinks like revocation don't matter. I propose a requirement that every CA whose certificates will identify ecommerce sites or software publishers must support revocation checking through standard means, say a CRL or OCSP pointer in every certificate. This could have an SLA aspect such that the OCSP or CRL not lapse (the CRL pointer should never point at a CRL whose next-udate time is three days ago). I think presentation of the CA logo leverages natural human and market systems to drive quality up for the consumer but practically this seems to be difficult as there is a UI real-estate issue - perhaps in time we will see the UI issue resolved through client software competition. Showing the user the vetted organization name when present does a lot to prevent homoglyph (homosymbol?) type attacks (one for el, zero for oh, and the IDN and unicode versions). Within this contex and to the question of whether strong authentication of the organization is the best approach or if it is better to issue broadly and revoke quickly I claim that the economics of revocation status services will drive a practical shift to stronger up front authentication given an active system of high enough value and volume to be part of the attack space. Finally I think there is merit to having different requirements for different applications of PKI. Compare the risks of interacting with your bank, installing software, and logging into your favorite internet portal so it recalls your content preferences. In the banking case I really care about authentication and encryption as does the bank. If you interact with your bank from your computer than you (and your bank) both care about what software you install. A few good keylogging attacks in the press and we may see the priority of software publishing security increase. _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
