Ian G wrote: > Ram A M wrote: > >>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. > > > It's never been done as far as I know. Maybe > we should defer conjecture until it has been > done?
Perhaps you meant that you find reason to doubt my statement and so I would like to understand why you think MF would hesitate to remove a CA that is known to be intentionally acting maliciously. > Sticking to facts here - are you saying that it > is not possible or is inordinately expensive to set > up an OCSP server that simply reports "none today"? No. Reread the previous post. I'm saying that to the extent a CA violates a stated policy they may be removed from a list. To the extent that the violation is clearly in bad intent there will be little debate over it. > > 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? > > > A worthy question. The great value of the > 'show the CA brand on the chrome' is that it > takes Mozilla out of the judgement game and > into the tools game. In testing it against > the phisher, it seems to answer that threat. You've measured a decline in phishing scams as a result of a CA brand show through program? While the conclusion lines up nicely with theory I have yet to see data myself. But back to the point at hand; I don't see how showing the CA brand is effective all by itself. The technique presupposes many other things are in place and is not a solution on its own. So I ask again, why do you support the imperfect approach of showing the CA brand to the relying party (user) but argue against the support of other features that enable the value of showing the CA brand to the relying party, such as revocation checking? > what you are suggesting is that revocation is > good enough to differentiate between good > CAs and bad CAs. No. Nor do I see any reason for you to believe that I do. > >>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. > > > OK. Which browser has it turned on? Several including IE. Does this mean that now you support requiring revocation support as a matter of policy? > And has anyone > reported on the experiences? It seems likely. > For web browsing? I very clearly stated revocation checking for code-signing is deployed. > I know you will find these questions uncomfortable, Nope - they are part of the foundation of my understanding and approach. > >>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. > I'm not saying don't adopt. You are saying don't adopt. When a suggestion is made and you say "that shouldn't be done" I take that to mean you think it should not be adopted. For an example of why I believe this, see your next sentence. > I'm saying do not > set policy to rely on it before it has been shown > to make a difference. I take that to mean don't adopt that as part of a policy until we see exploitation that could be remedied by the adoption. > I take it you are not at > this stage claiming it has made a difference? Are you saying it can't make a difference and so there is no point supporting it as part of a robust approach? This still sounds like you don't want to take any action until we see exploitations it would prevent. I think you impose constraints which are unrealistic when addressing large systems. <unsnip> Ian G wrote: > > If users cease to have a clear indication of "good enough for banking", > > I would expect banks to react to that, not with another user education > > campaign, but by refusing to work with those browsers and their tiny > > market shares. Some banks already do this. > > Nelson, I hate to repeat myself, but according to your definition users > today don't have a "clear indication of 'good enough for banking'" in > the browser with the dominant market share, since to the best of my > knowledge IE will happily display a padlock for a site with a "control > of domain" cert issued by any of a number of CAs Ram A M wrote: > 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. Do you agree that the lack of an attack vector being exploited it not proof that it can't or won't be exploited? _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
