1995-02-12 - the problem that destroyed PGP

Header Data

From: peace@BIX.com
To: cypherpunks@toad.com
Message Hash: 2437ea5a38162e116cbbc8cefa69ce550d0589e1b832c6c6eb1a06886d59392b
Message ID: <9502120550.memo.29017@BIX.com>
Reply To: N/A
UTC Datetime: 1995-02-12 10:50:41 UTC
Raw Date: Sun, 12 Feb 95 02:50:41 PST

Raw message

From: peace@BIX.com
Date: Sun, 12 Feb 95 02:50:41 PST
To: cypherpunks@toad.com
Subject: the problem that destroyed PGP
Message-ID: <9502120550.memo.29017@BIX.com>
MIME-Version: 1.0
Content-Type: text/plain


Return-path: <peace@BIX.com>
Received: by bix.com (CoSy3.31.1.50) id <9502112132.memo.28092@BIX.com>;
 Sat, 11 Feb 1995 21:32:20 -0500 (EST)
From: peace@BIX.com
Date: Sat, 11 Feb 95 21:32:20 EST
To: cyperpunks@toad.com
Message-ID: <9502112132.memo.28092@BIX.com>
Subject: the problem that destroyed PGP

So finding a KeyID is the problem that destroys PGP eh?

Well I would just take that as the problem to solve, not a
reason to throw the baby out with the bath water.

All we need to do is design a distributed, hashed database.
Should be a piece 'o cake, right?

Let's see, first of all the problem is the receiver of a message
who gets just the KeyID.  First of all, the trusted keys should
be expected to be local (in some webby sense).  But lets assume
that the key is new, not in our local cache.  Now my scheme would put
a net of keyservers that ALL know each other.  The local environment
puts in a request to its usual keyserver.  That is the keyserver
that typically has the keys that the receiver is likely to trust.
Now it is certainly possible to imagine a case where a key is not
in the receiver's expected server, so what's next.  Well the 
keyserver knows ALL the other servers, right, so just copy the
original receiver's request to all the other keyservers.  If that
gets to be too big, just build a real net where every keyserver is
at most two hops away from any other one, then the intermediate
servers that could not honor the request would forward it to all 
the servers it knew.  I purposely propose that only two steps would
ever be necessary to limit the explosion, but I see that as no
real limitation, the rule could even be modified if there was
really any need.

Hey look, the net supports archie and a host of other non-structured
search mechanisms.  Why create a search hierarchy where such things
are not natural.  Why create a naming hierarchy where such things are
not natural.

By the way, the dockmaster.ncsc.mil note is a good example of a naming
hierarchy that has nothing to do with the employment of the person.
Anyone working in the security field can get an address there.  And
any member can get acm.org or ieee.org. But I can post from any of
there different net addresses which do not even agree at the very
most basic level.  So why would my KeyID be naturally associated with
any one of .net, .org or .com?

Peace ..Tom





Thread