Re: The future will be easy to use

-----BEGIN PGP SIGNED MESSAGE-----

>Date: Mon, 27 Nov 1995 11:06:13 -0800 (PST)
>From: Raph Levien <raph@c2.org>


>   Form this perspective, let's take a look at the recent thread on
>"establishing trust." Carl Ellison advocates the MOSS alias system. My
>understanding of this system is that individual users associate "aliases" 
>with public keys. If done right, it can work well. However, from a
>usability perspective, it is just one more trouble spot. 

Yes, it could easily be done wrong in such a way that the user gets
confused rather than helped; burdened rather than relieved.

I advocate aliases because that's how *I* think.  I think in words so I
assign my own names (aliases) for the people who populate my mental model
of the world.  By definition, these are all my correspondents.  It's
possible of course that some other people (of different Myers-Briggs type,
perhaps) think differently -- not in words or aliases.  If that's true, we
should find out how they think and associate the right thing for them.  For
example, I had a friend (a painter/sculpter) who thought in images.  She
might prefer to use little pictures or icons (of her own drawing) as the
aliases.

>   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)

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)

I, the user, would want to be able to call up the set of defining messages
for any key or alias at any time in the future -- just in case I get so
many aliases that I forget who one belongs to.

>   The other issue is how much time and energy the user has to spend 
>keeping the alias database up to date. There is no way to communicate 
>securely with anyone who's not in the database. If the user is 
>communicating with a large number of people, then it's very tempting to 
>get sloppy.

I keep a fairly large database of aliases already, in my .mailrc on UNIX.
Eudora permits a similar DB.  So do a number of other mailers.  Users must
be demanding this feature and using it.  All I say we have to add to that
is protection from tampering.

>   There's no way around it. This kind of system will not make it in the 
>big time.  

I wouldn't be so quick to dismiss it.

>	    As I see it, any system that does must have the following 
>properties:
>
>   * Some variant on the Web of Trust.

Of course -- you have to have some means for communicating and recording
attributions (that the person who owns a key is allowed to spend money on a
given bank account; that the person who owns a key goes by the name Carl or
receives mail at cme@acm.org; that the person who owns a key is a trusted
developer of PGP; ...).

>   * Online key-servers for getting keys in real time.
>   * A clean mechanism for validating keys through alternate channels.

These two have to go together -- but I'm curious what anyone means by
"validating keys".  I see this as the flaw killing certificate structures
like X.509 or PGP's.  [Even Steve Kent, a major X.509 advocate, seems to
see this problem (with sadness, in his case).]

I had a secretary once, long ago.  I would drive her home from work
occasionally -- or to parties -- when her husband wasn't around or wasn't
interested in going someplace.  One time, in passing, he noted that this
arrangement was OK with him because he "trusted her".  I trusted her, too.
I knew her to be having affairs with various people (not me at the time)
but he didn't.  So we each trusted her but what we trusted her to be was
different.  Just saying that we trusted her wasn't saying anything.

As soon as you qualify the "validated key" (e.g., to be allowed to spend
money, etc.), you get to the signed attributes which I advocate over
certificates.  If all you do with the validated key is tie it to a text
string which purports to specify a human being, as X.509 or PGP do, you
haven't done anything for me.  If all humans had unique names, then this
might mean something to me (assuming I knew the human in question and knew
his unique name).  However, that's what killed X.509 -- the need for unique
names.  We don't have them and we're not about to adopt some new social
structure which assigns them.  Even if we did all adopt unique names, you
postulated a *large* set of people to communicate with -- larger than my
immediate circle of acquaintances, presumably -- so even a unique name
would be meaningless to me because I would not have met the person in
question.  If the unique name certificate works at all it's because I have
some mechanism (not mentioned in the certificate hierarchy design) for
attaching attributes to the named person.  However, if I haven't met the
person in question, I don't have that mechanism already and it needs to be
created alongside the certificate mechanism.

I don't need testimony about the name (unique or otherwise) of the person
who owns that key.  I need testimony about the attributes of that person
(PGP developer; fellow Cypherpunk; FBI agent; undercover NSA plant;
permission to use a checking account; receives mail at xxx@yyy.com; ...).
That testimony can be provided by referencing the key itself, rather than
some (artificially unique) name which exists only to link the attribute to
the key.  The S/W which links these together and lets me find the various
testimonies for a key has to be convenient -- but that was your original
point and I concur.  I object only to the implication that current
certificate hierarchy thinking gets us closer to that goal than the direct
signed attribute statements would.

>   There are three possible outcomes: we build it, the NSA builds it, or 
>Microsoft/Netscape builds it. This last outcome might not be so bad, but 
>only in the first one can we rely on our principles being advanced.

Amen!

 - Carl

+--------------------------------------------------------------------------+
|Carl M. Ellison      cme@tis.com    http://www.clark.net/pub/cme	   |
|Trusted Information Systems, Inc.   http://www.tis.com/                   |
|3060 Washington Road          PGP 2.6.2:  61E2DE7FCB9D7984E9C8048BA63221A2|
|Glenwood MD  21738         Tel:(301)854-6889      FAX:(301)854-5363       |
+--------------------------------------------------------------------------+

- -----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMLtON1QXJENzYr45AQGiEwP+OpETJDPJ8rWbur4oH/PCZqKWtXmzTquV
4QIwoZlXoK6RnZ60szR/qqPxjnj+TtsO8FOQK5lWurv+FG67ma5PfyNbxU+WFapY
uxwop8Ivb3bw0uFT2oh2VE5owAYFkmqz7kd7GleEG33dGOUz7jSELugzL4Ag8zRF
40qPwsU7B08=
=aeKx
- -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMLtOvVQXJENzYr45AQH5RQP+JroFSz3bJapOGEqA2pfhZ1dn9d7VDEUd
h/JLbhFkgYbzMGsVzpu20Ww0uOsOwxQR2ItLkaSlTG0O76rgATE2Cma9LEvdoque
LMgN/xg0GmaSHoecHLuKJxRz/1xreKODuai2FvndyjspfgO/H6zrQOfhsWn3qa6a
ZqnNaEY+kXw=
=cuUk
-----END PGP SIGNATURE-----

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

-----BEGIN PGP SIGNED MESSAGE-----

>Date: Tue, 28 Nov 1995 11:43:34 -0800 (PST)
>From: Raph Levien <raph@c2.org>

>> 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.

Of course.  This isn't the base case.  We would have some keys which I sign
based on my own personal knowledge; things handed to me by people I know;
some possibly published in the paper where the real key owner would see the
claim and be able to contest it.  PGP today comes shipped with some keys to
provide the base for a chain of key signatures, but there's no verification
of PRZ's or JIS's keys.  One has to prime the mesh somehow.

I personally prime it by having some keys (or fingerprints) exchanged face
to face with people I know -- and having others acquired by association
with signed messages (b).  I don't have any yet whose trust has been
acquired by attribution (a), since we don't have that machinery set up yet.

BTW -- PGP currently lacks a way for me to note, when I sign a key, how it
is that I trust that key (by personal meeting, by attribution, by message
association, ...).  A signed attribute record would let me record that
information for myself as well as for others.

>> 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.

Here I'm talking about people I "meet" and "get to know" based strictly on
my own e-mail conversations with them.  For such people, there is no other
evidence.  If it weren't for those messages, these people effectively
wouldn't exist in my world.  These messages define the people in question.

Stated another way:  I want to communicate with Alice.  I don't want to
communicate with Bob.  I've never met Alice but I have an address for her
and a public key.

	Alice --- Bob --- Carl

shows Bob as an active eavesdropper, controlling all of Alice's channels,
blocking release of her real key, announcing a key he controls under her
name to the rest of the world.  By contrast,

	Alice --- Bob --- Carl

shows Bob as Alice's secretary, who has been given the job, by Alice, of
reading all Alice's mail, choosing which to pass along to her and answering
all the others.  Alice has generated a key for herself and has given the
private key to Bob so that he can sign for her and read all her mail.
Alice could even have that key certified as hers within some massive X.509
hierarchy -- doing that before she gave the private key to Bob.

I know of no crypto protocol which will distinguish one from the other
unless I have a private channel to Alice at some time -- but that
contradicts the original assumption that I've never met her.

In both cases, the person I think of as Alice is really

	(Alice --- Bob) ---

and that's the "person" I learn to trust or not to trust.  That's the
"person" for whom I attach an alias to the public key.

 - Carl

+--------------------------------------------------------------------------+
|Carl M. Ellison      cme@tis.com    http://www.clark.net/pub/cme	   |
|Trusted Information Systems, Inc.   http://www.tis.com/                   |
|3060 Washington Road          PGP 2.6.2:  61E2DE7FCB9D7984E9C8048BA63221A2|
|Glenwood MD  21738         Tel:(301)854-6889      FAX:(301)854-5363       |
+--------------------------------------------------------------------------+


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMLtxOlQXJENzYr45AQFw4gP/es2salfOBrsPW3X1d+NnsBTThKJSkTYP
yCp7YZ9iIgBXnV/rQ3TcZg2Gbts/QwpUrqN7fQQ+tNazMxqomd3+Iz+5HPTU2jc7
5rW8p/dyq1vKGDgy+M4ohTLE9XXVJLJo3AwpUJeAhqd/SAUiJPTpdgggotnXfAeF
wWovhe3nq+U=
=jpzx
-----END PGP SIGNATURE-----