From: Raph Levien <raph@c2.org>
To: Carl Ellison <cme@TIS.COM>
Message Hash: 36fb3c19505be0140b0d502284c41d96208dd9ee94c862f79d2e08a5290bdd84
Message ID: <Pine.SUN.3.91.951128113331.17420A@infinity.c2.org>
Reply To: <9511281803.AA20521@tis.com>
UTC Datetime: 1995-11-28 20:03:41 UTC
Raw Date: Wed, 29 Nov 1995 04:03:41 +0800
From: Raph Levien <raph@c2.org>
Date: Wed, 29 Nov 1995 04:03:41 +0800
To: Carl Ellison <cme@TIS.COM>
Subject: Re: The future will be easy to use
In-Reply-To: <9511281803.AA20521@tis.com>
Message-ID: <Pine.SUN.3.91.951128113331.17420A@infinity.c2.org>
MIME-Version: 1.0
Content-Type: text/plain
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
Return to November 1995
Return to “Raph Levien <raph@c2.org>”