> The difficulty for the end user here is that the little lock icon is > overloaded: it is taken to mean both "session is secured against > spying" AND "session is with a trusted partner". One could argue that > this confounds authentication (verifying the cert.) and authorization > (asserting trust of the target site). One could also argue that end > users should know better than to read it that way, but the UI is just > too simple to do the job required and the protocol hasn't been > supplying all the information that the user really wants.
I don't understand this argument at all. The two questions you seem to think are being confused are the *same* question. When I type in "https://www.amazon.com";, what I want to know is -- do I have a secure connection to Amazon? A secure connection to someone who is out to steal my credit card is not really any better or worse than in insecure connection to Amazon. A secure connection to an unauthenticated source is of no value because the unauthenticated source could be the one person who the connection is supposed to be secured from. If there's nobody the connection is supposed to be secured from, why would you care that the connection is secure? Authentication and authorization are the same thing. They are both required to ensure that only those who are supposed to be parties to the conversation are in fact parties to the conversation. And that is the root security requirement. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
