Imagine if a website could instruct your browser to transparently generate a public/private keypair for use with that website only and send the public key to that website. Then, any time that the user returns to that website, the browser would automatically use that private key to authenticate itself. For instance, boa.com might instruct my browser to create one private key for use with *.boa.com; later, citibank.com could instruct my browser to create a private key for use with *.citibank.com. By associating the private key with a specific DNS domain (just as cookies are), this means that the privacy implications of client authentication would be comparable to the privacy implications of cookies. Also, in this scheme, there wouldn't be any need to have your public key signed by a CA; the site only needs to know your public key (e.g., your browser could send self-signed certs), which eliminates the dependence upon the third-party CAs. Any thoughts on this?
You don't have to imagine this. It is exactly how Infocard (the generic name of the technology of which Microsoft's CardSpace is one implementation of one component) works in its most common mode (the personal or self-issued card). It has lots of other benefits as well even in this mode (user-managed attributes, graphical UI) as well as other modes to support identity providers (managed cards).
Lest you think that this is Microsoft-only, be assured that there is a large community building implementations for many other platforms and systems. OSIS (http://osis.idcommons.net/) is the prime venue for people to work on interoperability across the spectrum of implementations. There's a big interop event coming up at the RSA conference in April.
If you'd like to help make your scenario a pervasive reality, check it out.
- RL "Bob" --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
