On Tue, 28 Nov 1995, Carl Ellison wrote:
Raph Levien wrote:
First, on what basis will users decide which keys are worthy of being assigned which aliases? Public keys are big hunks of base64 encoded gibberish. They are difficult to present in a user interface, difficult to communicate in alternate, known secure channels (such as telephone calls and face to face communication). There is no way that a person could memorize one.
That's true. What the user would have to see is some icon (or, for text-bound folks, a temporary unique string) until the user chooses and assigns the appropriate alias. That icon would have no meaning by itself. It would acquire a meaning by being associated with some message or set of messages:
a) an attribute testimony (signed by someone with known authority to specify such an attribute -- the equivalent of a certificate)
This is the induction case, not the base case. It assumes that you've already got a bunch of trusted public keys in your database. It also assumes the willingness of the ownsers of those public keys to sign new keys. See, now they've got the same problem of trying to determine whether the key is valid. Turtles all the way down.
b) a set of messages signed by the key in question (tying the key to the source material from which the user formed his/her impression of the sender)
There being no reason, of course, why Mallet couldn't just sign all that stuff with his own signature. Here, you're relying on the ability of data to authenticate itself. I am simply proposing a third alternative that has neither of these problems: a short unique name for the key. Its success relies on alternate, non-digital forms of communication: the phone, ink-signed paper, face to face, whatever. [complex stuff deleted - I only wanted to make a simple point] Raph