1995-02-11 - Re: why pgp sucks

Header Data

From: Derek Atkins <warlord@MIT.EDU>
To: Matt Blaze <mab@crypto.com>
Message Hash: 7357cf259df60b41a485cbbc82442224fbb11bafceaa1027ba7b9f328223121c
Message ID: <9502110316.AA29939@toxicwaste.media.mit.edu>
Reply To: <199502110114.UAA07325@crypto.com>
UTC Datetime: 1995-02-11 03:16:52 UTC
Raw Date: Fri, 10 Feb 95 19:16:52 PST

Raw message

From: Derek Atkins <warlord@MIT.EDU>
Date: Fri, 10 Feb 95 19:16:52 PST
To: Matt Blaze <mab@crypto.com>
Subject: Re: why pgp sucks
In-Reply-To: <199502110114.UAA07325@crypto.com>
Message-ID: <9502110316.AA29939@toxicwaste.media.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain


Matt Blaze:
> I don't think it's clear yet, by the way, that domain names are
> the right model for personal key distribution (in particular, it
> assumes that keys are being distributed on-line and deals only
> awkwardly with semi- off-line clients, as anyone who travels with
> a sometimes-networked laptop knows.  It also assumes that the
> distribution hierarchy can be mapped atop the lookup keys namespace,
> which makes it hard to use for anything that isn't hierarchically
> formed).  It's probably one of the important options, though, since
> it scales so well and has a successfully fielded history in DNS.

The idea I've had, and have floated to a few people, is not to
base a distributed keyserver on DNS, but to use DNS as a model
for a distributed key database.  

Hal, yes, you could have a keyID->userID mapping, but that doesn't
scale well.  Let me give you a concrete example (using DNS): I want
the host information for TOXICWASTE.MIT.EDU.  From the root servers I
get to EDU->MIT->TOXICWASTE, and find its IP address (18.85.0.40).
This would be like asking for a key by UserID (warlord@MIT.EDU would
go to the MIT.EDU keyserver).  Now, lets work in reverse, you have
18.85.0.40 and want to get the hostinfo.  In DNS there is a 1-to-1
mapping of Domain to Network.  You _know_ that any machine that is in
18.* will be at MIT, so again you can go to the MIT nameserver for
help.

This doesn't work with PGP KeyID, since the keyID is a random string
of bits.  As a result, you have no way to know that keyID 0xC1B06AF1
should be obtained on the MIT keyserver.  This is the major problem
that Perry is trying to address.  I just don't know of a good way of
doing this, other than maintaining a keyID->userID mapping table
somewhere, but that can become a HUGE flat lookup table!

James said:
> We already have a centralized, for profit, key distribution system.
> 
> http://ww.four11.com/InfoServices.html
> 
> If they make money off it, there will be more of them, they
> will provide better service, and it will in due course
> become a distributed key distribution system.

No offense, James, but this needs to be a free infrastructure.  When
you get your shell account/IP address/PPP drop/etc., you should also
automagically be allocated space in a keyserver.  It shouldn't cost
you anything to be put in it (just like it doesn't cost you anything
to be put in the Telephone White Pages.

The keyservers have to be distributed so that there is a single method
for everyone in the world to connect to the white-page server of their
choice.  I'm sorry, but the WWW is not it.  The WWW does not scale,
and personally if I had to pay to be put on your server, I would
ignore it; I'm perfectly happy using the Public Keyservers.

Just as sites currently provide DNS service for names, they will, in
some time, provide KeyService as well.  It's just a matter of time.

As for the "centralized" part...  I think the distributed part is much
more important.  The public keyserver keyrings are currently over 3MB
and growing.  We need to be able to split that keyring across multiple
servers and have requests go to the appropriate locations.  Yes, there
will be a centralized authority delegator, but the keys themselves, as
well as the means to obtain them, will be distributed.

Enjoy!

-derek





Thread