Dave Korn wrote:
We already had this with PKI and SSL, and it basically failed. Works fine on a small scale in a tightly-disciplined organisation; fails totally to scale to Joe Internet-User.
one could claim that PKI failed ... especially in its trusted 3rd party scenario ... since it was an amazingly complex and expensive deployment to solve a rapidly vanishing problem. the basic design point is the electronic analog for physical credentials, certificates, licenses used in the "offline" world ... or the electronic analog of letters of credit/introduction from the sailing ship days (and before) ... the trusted distribution of information for the benefit of relying parties that had no other recourse for the information. in an online world ... a paradigm designed for trusted distribution of information for an offline world, rapidly becomes redundant, superfluous and obsolete (besides enormously NOT cost effective). SSL was intended as countermeasures to two vulnerabilities 1) are you really talking to the server that you think you are talking to (among other things ip-address hijacking) and 2) evesdropping of information in transit. The SSL solution to #1 was predicated on the end-user having knowledge of a trusted binding between the server he thought he was talking to and the URL for that server. The SSL protocol then provided the trusted binding between the URL and the server the user was actually talking to. That weak-link in all of this was current infrastructure where end-users frequently have very little knowledge of the binding between the server they think they are talking to and the URL for that server. It isn't so much that SSL has failed to do what it was implemented to do, it is that SSL failed to take into account that part where end-users have very little knowledge of the relationship between servers and the URLs for those servers. It isn't so much a small-scale population that it works for ... it requires a (disciplined) population that maintains adequate knowledge of the relationship between servers and the URL for those servers. Even a well disciplined population is likely only to maintain knowledge of strong binding between servers and URLs ... for only a small number of servers and their corresponding URLs. The same population may be also be vulnerable when dealing with URLs and servers outside some well regulated domain. these series of posts talk about eliminating PKI and digital certificates for SSL ... and going to real-time public key operations in the domain name infrastructure ... as countermeasure to ip-address hijacking (original SSL) as well as domain name hijacking (as well as providing mechanism for encrypting information while in transit). http://www.garlic.com/~lynn/subpubkey.html#catch22 Aka the current domain name certification authority PKI-based paradigm has its root trust in the validity of the information at the domain name infrastructure. While the existing SSL/PKI related implementation was targeted at ip-address take-over ... it still remained vulnerable to domain name hijacking. however, the real-time domain name public keys, still doesn't address the vulnerability of end-users typically not having knowledge of strong binding between the website they think they are talking to and the corresponding URL (making them vulnerable to website impersonation and social engineering attacks that get them to click on arbitrary URLs). Solutions for these vulnerabilities ... typically involve some amount of additional trust operations by the users ... along the lines of local repository of trusted public keys with the corresponding trusted binding to trusted URLs (which starts to look somewhat like the PGP email public key repository). One of the issues for such solutions is that they lack the economic incentive for large scale deployment (i.e. there is no 3rd party taking in money selling digital certificates). --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]