Ian G wrote: > Ram A M wrote: > > Frank Hecker wrote: > >>I'm happy to take suggestions on this from you and others.
> > Suggestion: Require support for programmatic revocation checking before > > illuminating the "safe for e-banking and e-commerce" light. That means > > either raising the bar on CAs that qualify for the lock and gold > > background, or, making a UI change that enables an intuitive > > distinction between those that do and those that don't. > If I was a rogue CA I'd consider that hardly a > barrier. It wouldn't take more than a weekend > to knock up a "null revocation" service AFAICS. I don't see anyone throwing their arms up over an immediate patch to FF to remove a CA that does this. > Turn the problem around and look at the cost of > falsely showing that you do revocation; Cost is not being a CA. Once you demonstrate bad intent people are quick to shun you. Your statement doesn't seem thought out, that's ok - I'm not perfect either. > Even if you are talking OCSP and automated checking, > it would still seem to be relatively easy to knock > up a server using open source code that just reports > "no revocations today, come back tomorrow." It would take a lot more than that to affect an attack which suggests it makes the overall PKI model resilient. Maybe if you think about this from a more inclusive perspective it will help. The domain name system is meant to serve a diverse audience. That means some of its users security needs unfulfilled. PKI style delegated authentication is part of an answer in several ways includng that it brings the notion of identity into play which allows the existing legal and law enforcement systems to add their capabilities to the system. Authentication is imperfect and so the upfront vetting process of even a really hard trying CA is imperfect. The better the authentication practices the fewer failures. Revocation is useful in addressing the remaining weaknesses of authentication procedures. You point out that things are imperfect. You seem to argue both the position that PKI helps and the position that PKI doesn't help. You can drill down on many things and find them imperfect. I assume you can find imperfection in the 'show the CA brand on the chrome' concept and yet you argue it is a worthy addition. What gives? > changing the policy to slow down the influx > of dodgy CAs is only half the story, and unless the > other half - cleaning out the current lot of dodgy > CAs - is put on the agenda, this is an incomplete > approach? Where did you get the idea that evaluating the current CA list is not on the table? > My understanding is that no browser gets shipped > with any revocation system turned "on", right? So > this is an untested system, yes? Wrong. Revocation checking is on by default in quite a few systems at this point, even public consumer ones. Deployments are more prevalent on the wireless infrastructure because of different risk profile. Also Microsoft Windows has revocation checking turned on by default for code-signing last time I checked, and has been that way for quite a while if memory serves. > From a policy point of view, it would be wise to > see this thing in action, and then adjust the policy > to suit. As the current root list is apparently full > of control-of-domain opportunities, this doesn't > represent a problem. I strongly disagree with your suggestion that we should wait for heavy exploitation before adopting useful technologies. Fortunately for both of us, I know I'm not alone in this. > OK, but that's on paper. The notion that someone has > a quick and easy way for closing down a web site is > so ... much further forward than where we are now, that > I would be skeptical. Let's see this thing in action > first, before relying on it, as nobody else has ever > been able to do such a trick. Wrong. CAs have been revoking certificates for inappropriate use for many years. That is even if a "subscriber" (to the CA service) is correctly named a certificate a CA may decide based on policy that they will revoke the subscriber's certificate. In the case of private deployments (where a CA operates a PKI system for lets say a wireless carrier, large corporation, government body etc) the policy is set by the CA customer (the wireless carrier) and enforced by the CA using whatever feedback and control mechanisms are specified in the defined policy. This is really old stuff and there are many examples. > > There was very little UBE in 1995. I wouldn't count that as an argument > > to say that the email infrastructure was good enough for broad > > adoption. The value of UBE went up and the problem grew to suit. > > > What is UBE? http://www.sendmail.org/~ca/email/spam.html Not all 'SPAM' is UCE as fraud or politics are not typically included in "commercial." _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
