> Ian Grigg wrote: >> 1. The reason there is a strong dominating player at >> the moment is because there is no way to compete. > > But the reason there's no way to compete is due to whose root certs are > in the main browsers, not any other reason like branding or lack of it.
Yes, the reason there is no way to compete is because the root certs are a fixed and hidden bucket of certs. The solution is to unfix it and to unhide it. One way of unhiding it is to brand the CAs. Another way is to petname the certs. A third way is to put the counts in, and a fourth way is to treat self-signed certs as simply a cert with a less popular brand. A fifth way is to have the user sign off on each cert and attach logos to them. All of these things are useful for competition, and for that reason, the CAs generally actually want these things (because only competition in a public space will let them grow the market) ... they actually want to compete against alternates like self-signed certs that are not based on a fixed/hidden bucket of root certs. But, the real reason for them is security. Currently, the reason the SSL browser security model is breached by phishing is because the cert is hidden from the user, and not surfaced (as per brand and other activities). Competition and monopolies are side issues, really. >> 3. Incumbents don't currently do anything to justify >> their brands, basically because they don't have to. If >> they had to, there would be a shakeup in the marketplace. >> Those that are small, lean and mean would be much better >> placed to deal with the new branding issues than those >> that are large, and encumbered with the baggage of past >> mistakes. > > But there can never be a proper market in certs, can there? So, why should we keep the current un-proper one? > If Amazon is > secured by Verisign, I can say "Well, I don't trust Verisign", but if I > want to buy from Amazon, I don't have much choice, do I? I'm not sure where to start! You have plenty of choice. If you don't "trust Verisign" you examine the cert that is presented and you check it is the one that Amazon uses. Hopefully your browser will then allow some relationship building to assist in this. Bear in mind that you almost certainly won't be phished the *first* time, only later on when you have a relationship established (when it is a valuable relationship...). The reason you might think you have no choice is because the browser doesn't give you any choice. Hence.... phishing. Solution: have the browser give you a choice! (But, you are right in one facet: x.509 doesn't support trust as we humans know it, which is with multiple vectors. But, the browser doesn't have to follow that.) >> I don't see the problem. The user sees that they >> are different sites. She analyses the sites, and >> if they are bona fide, enters different pet names >> and carries on. When she gets phished over to >> https://www.barclaysbank.com/ and finds that the >> site might not be right, she doesn't petname it. > > But surely the point about phishing is that https://www.barclaysbank.com > looks totally genuine even if it's not. RIght. So the user has to determine whether it is. Verisign isn't going to help, because there is no cert in use. In fact the only thing that will help is that there is no cert in use; but right now, the brower hides the presence or otherwise of the cert, down in the lower left corner where nobody notices. (Note that this prescription of fixes also will lead to much more cert usage ... which will allow Verisign to help, *iff* it can rely on its brand being obvious.) > I assumed the point about petnames is that the user "goes to their > bank", but the petname doesn't appear, and they go "Huh?". Was I wrong? Yes, that is the first defence for the immediate problem. But what we have to do is to migrate all important sites across to SSL, and to place the browser in control of the relationship, so that the information tied to Verisign and the cert and all the other personal information can be integrated. >> to hide all the real information. So the problem >> with the above is to stop assuming that they are >> valid, and to insist that the user authenticates >> them in some fashion or other. > > Using what evidence? Inspecting the website? The only sensible thing I > can think of is comparing the URL with one printed in e.g. a magazine. If you open a bank account online then generally, the bank takes some care to establish the relationship. Maybe it's the URL, maybe it is a token that is sent in the mail, or text'd to their cell. Personally, I'd rather see the fingerprint printed on statements, but that might be a ways in the future. If you are just shopping at Amazon, then there would be less of a burden, because it matters less, but Amazon still has a way of reaching people, and generally, they have no difficulty in finding excuses to try. Consumers and merchants do use a little bit of common sense when establishing a relationship; they just need to be given the tools to do that. > But who would bother doing that? Anybody who's been phished! iang _______________________________________________ Mozilla-security mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-security
