1994-10-06 - Re: Nom de guerre public key

Header Data

From: Derek Atkins <warlord@MIT.EDU>
To: franl@centerline.com (Fran Litterio)
Message Hash: 2f563633a47308983837dbe05d7f710c5db78e7505bbf2d377281c9c0cd6dabd
Message ID: <9410060229.AA15700@toxicwaste.media.mit.edu>
Reply To: <FRANL.94Oct5093142@draco.centerline.com>
UTC Datetime: 1994-10-06 02:29:28 UTC
Raw Date: Wed, 5 Oct 94 19:29:28 PDT

Raw message

From: Derek Atkins <warlord@MIT.EDU>
Date: Wed, 5 Oct 94 19:29:28 PDT
To: franl@centerline.com (Fran Litterio)
Subject: Re: Nom de guerre public key
In-Reply-To: <FRANL.94Oct5093142@draco.centerline.com>
Message-ID: <9410060229.AA15700@toxicwaste.media.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain


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

To: franl@centerline.com (Fran Litterio)
cc: cypherpunks@toad.com
Subject: Re: Nom de guerre public key 
In-reply-to: Your message of "05 Oct 1994 13:31:42 GMT."
             <FRANL.94Oct5093142@draco.centerline.com> 
- --------
> key's owner).  Sure signatures bind the userid to the key, but what
> good is that to third parties if they can't be sure that the userid
> accurately names the person who possesses that key?

What is in a name?  A name is just a convenience with which one can
identify some object/entity/etc.  "Pr0duct Cypher" is as much a valid
name as "Derek Atkins".  The fact that some entity can produce some
United States Government paperwork that says that the US Govt believes
that this person "exists" is irrelevant in this discussion.  The fact
that I can certify that "This Public key belongs to the identity
Pr0duct Cypher" is _all_ that a key signature says.

> When I meet you in person to hand you my key fingerprint, won't you
> require me to identify myself in order that you can be sure the name
> in the userid of my key is also the name of the person you are
> meeting?  If you do, then you will have just validated the binding
> between userid and real person.

This is a humanly-applied set of restrictions.  I have in the past
signed keys for people whom I haven't met in person; my personal
requirements for signing keys do require out-of-band authentication,
however.  Yet PGP does not impose this restriction.  I could create
an identity (call him Mr. X), and Mr. X could start to sign keys
based upon continuous communication.  

For example, Mr. X could encrypt a message to some other pseudosym,
and ask them to sign the message that was encrypted to them and send
it back.  Since only the owner of the key can both read it and sign
it, and since Mr. X only sent this to a single person (and included
some identification string), Mr. X could know, with marginal doubt,
that this key belongs to this identity -- even without ever meeting
this person and without ever needing to talk to a real person.

> entity.  Because the entity is unwilling to prove to me that there is
> a single real person who possesses the private half of his key.

This is fine -- you don't have to sign pseudonymous keys.  That is
your perogative.  That doesn't mean that there aren't cases where
signing a pseudonym's key is the right thing to do.

> I don't like the idea of an automaton possessing or signing PGP keys.
> People sign other people's keys because only people have the need to
> trust other people.  Automatons don't need to trust and they are not
> the direct targets of trust.  

So what you are saying is that you don't see any reason for a server
to be able to authenticate itself or for someone to be able to send a
message to a server?  You don't believe that there could be a
PGP-telnet?  If this is what you believe, then you have a very
short-sighted view of the world.

A server needs to trust that a person is allowed to log into it, or
that a client is allowed to use the service it provides.  As such, it
is vital that the server be able to authenticate to the client as much
as the client needs to authenticate to the server.  This requires that
the server itself maintain a key.


> This is the objection I had to Phil's
> signing of the Betsi public key.  As an automaton, Betsi is only as
> trustable as its human authors and adminstrators.  Yet Phil doesn't
> know who those people may be in five or ten years.  Yes, people change
> over time too, but not as quickly or as radically as an automaton can.
> It's too easy to subvert an automaton for me to ever sign an
> automaton's PGP key.

This is the point I am trying to make.  When I sign a key, I do not
say ANYTHING about how that key will be used -- I am only saying that
I know that that key is what it claims to be.  I know that this key
belongs to this user, this name, this email-address, this server.  I
don't know that if I sign your key you will then use it to send
threatening email to president@whitehouse.gov.  And personally, I
don't care -- that shouldn't be a consideration in my signing your
key.

Phil signed the Betsi key because to his knowledge that key really
belonged to the Betsi server.  Just like I will sign the MIT PGP
Keysigner key because I will know that it belongs to that identity.
As to how much trust I put in these keys to sign other keys is a
determination that I make orthogonal to the question of signing the
key.  I happened to write the keysigner software, so I know what it
will do -- but that is me -- you don't have to trust it if you don't
want to.

I think the problem here is that you are combining a number of
orthogonal decisions into a single one.  These decisions are:
	1) trust in userID to sign a key
	2) trust in that key to sign others
	3) trust in the usage of that key.

These are distinct for a reason, and should be kept that way.  If you
want to lump them together, that is your perogative, but that is not
something that can be, or should, be enforced.

- -derek

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQBuAwUBLpNg7zh0K1zBsGrxAQGETQLECyKXVFNnai1otoSH3IMungYtXqR+y4gj
LFyIa0iIhMgTMYI0tCFs4RmG3pwO83qCoaLRbGdJ5IpjbepqbUHKDwFm0AB7Z43I
x2s2A+HjqTtEu5XaNV1qGvg=
=4urS
-----END PGP SIGNATURE-----





Thread