The solution is simpler than it seems. Let's first look at one scenario that is already working and use it as an example to show how the email scenario may work.
Banks are already, and securely, sending and receiving online messages to/from their clients. This is done by a web interface, after the user logs in to their account. Web user login can be based on a number of two-factor and mutualauthentication solutions, some of them quite ineffective to prevent phishing but, nonetheless, better than what the email PKI model provides. What's missing with the email PKI model? While the bank is asking to be authenticated by the user, it does so by asking the user to rely on a number of third-party references that are actually unreliable (ie, by being without recourse, warrantless, unverifiable, and chosen by the purported sender in what may be a con game). The bank would never allow the user to be authenticated under the same assumptions! So, what's missing in the email PKI model is two-sidedness. Fairness. It is essential to have a reference point that the user trusts. In the web messaging example already used by banks, this is provided by the user login -- the user trusts that that is their account -- their name is correct, their balance and transactions are correct. I am using this insight in a secure email solution that provides just that -- a reference point that the user trusts, both sending and receiving email. Without such reference point, the user can easily fall prey to con games. Trust begins as "self-trust". Anyone interested in trying it out, please send me a personal email with application info. Best, Ed Gerck --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
