On 2013-03-06 4:41 AM, StealthMonger wrote:
What's wrong with the following simple idea:
1. p2p: The parties opportunistically verify out-of-band after
exchanging keys via public key servers or (insecure) email.
2. Prospective customer verification of merchant: Merchant includes
the ID of its signing key in every advertisement and repeatedly
admonishes prospects to "Accept No Substitutes".
3. Merchant authentication of Customer: Merchants don't deal with
people. They deal with keys. It's the key that has the purchasing
power, not some person. Nobody has the illusion that correlation
between key and person is any stronger than that person's security
habits.
4. Etc.
Let us suppose we have urls that contain public keys, or hashes of them,
or shared secrets, and let us suppose that clients and servers know how
to handle them: That the client will insist that the server proves
knowledge of the corresponding secret key, or knowledge of the shared
secret, without spilling the shared secret to all and sundry.
Can you implement your above design while hiding the keys in urls,
rather than inflicting them on the suffering user?
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
