There are two approachs with the padlock, as you suggest: the high road and the low road. The problem with the low road is that nobody is happy with the perception of lowered security. The problem with the high road is that VeriSign aren't going to agree that Comodo's high-ass certs are as good as the VeriSign ones.
Of course not, but that's their problem, not ours. We (the browser vendors) could easily make a determination that a "high-assurance" cert from CA Foo is equivalent to a "high-assurance" cert from CA Bar, at least as far as typical users are concerned. See my next message for a strawman proposal to do exactly that.
Of the two, I'd prefer the low road: padlock signifies that a TLS connection is in place.
I think this matches the "pure view of TLS". The purpose of the cert is to simply stop the MITM, so the domain needs to be checked only. Hence Ram's "control-of-domain" term.
But IMO your "pure view" of certs as an anti-MITM defense is just as much an idealization as the "pure view" that certs prove identity. I think the reality is rather that for typical users the padlock simply means "it's OK to send my cherished personal information", no more and no less.
There is an even further step beyond, which might be called "the trust view." That is, if the padlock is on, you can trust... This is hopeful at best and will lose the client money at worst, simply because trust is an undefined concept, and thus is oversold. In the security community these days, we tend to perceive the word 'trust' as snake oil; if you can't describe your claims without using the word trust, it is likely you don't know what your claims are, and you are just hoping the listener doesn't notice.
Snake oil or not, I think the "trust view" is exactly what typical users hold, for better or worse. (And I might add that just because a concept is slippery and ill-defined doesn't mean it is wholly without validity or use in real life.)
Which still leaves (sorry to bring this up) the oddball meaning of a self-signed cert. Where this gets interesting is that when it first appears, it signifies a secure connection albeit with a minor risk of MITM. But, if the user then accepts that connection, and if she could record that acceptance, then follow-on connections would potentially deserve the padlock. Still, let's ignore that for now...
See my next message for how I'd propose to treat self-signed certs. (Short answer: better than we do now, with all the alarming warning dialogs, but not as you'd like them to be.)
Frank
P.S. Apropos of these discussions, there's an interesting post by Clay Shirky (ostensibly on the subject of the "Wikipedia vs. Encyclopedia Brittanica" debate) that posits two classes of people: "radialists" and "Cartesians":
http://www.corante.com/many/archives/2005/03/09/one_world_two_maps_thoughts_on_the_wikipedia_debate.php
After reading it I realized that I am a "radialist" at heart, while I suspect you are a "Cartesian" (as are certain others on this group as well). I am interested in incrementally improving the situation in which we (browser vendors, CAs, and end users) find ourselves, without necessarily achieving ending up in some posited ideal end state. My next message ("Strawman proposal for SSL UI changes") is an example of this approach in action.
I think there is a place for the "Cartesian" approach, but I think in practice it will prove to be outside the traditional SSL/TLS/PKI domain.
-- Frank Hecker [EMAIL PROTECTED] _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
