From: Alex Strasheim <alex@omaha.com>
Date: Mon, 28 Nov 94 00:34:08 PST
To: cypherpunks@toad.com
Subject: Transparent Email (WAS disable telnet to port 25)
In-Reply-To: <199411280806.CAA00150@omaha.omaha.com>
Message-ID: <199411280834.CAA00176@omaha.omaha.com>
MIME-Version: 1.0
Content-Type: text


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

> I don't have an answer to your question, but you did bring up something 
> I've been meaning to ask about for some time and I never really got 
> around to it; Are there any short-term plans to press for an RFC 
> utilizing digital signatures?  With the exponential increase of mail 
> users, as well and the influx of Compu$erv, AOL, Prodigy and other users, 
> some methods for the transparent use of digital signatures needs to be 
> worked out before it becomes too difficult to implement change because 
> the commercial services have all the power.  (or worse, before the 
> government decides for us.)

Some still unformed thoughts on this subject:

The big problem with transparent encryption and signatures is key 
distribution:  if you've never sent a letter to me, your mailer will have 
to get my key (invisibly) before the mail can be sent.  The big problem 
with key distribution is the web of trust:  who gets to decide which keys 
are good?

This is a subtle advantage that systems with centralized key generation 
have over systems like PGP, which let users generate their own keys.  If 
big brother mints all the keys, then big brother can set up an 
authoritative keyserver.

The best answer that I can come up with for this problem is to allow for 
several webs of trust to function simultaneously.  Perhaps we would have 
a default web, which would have everyone's key in it.  The idea behind 
the default web is that it should be able to return a key as often as 
possible, so we don't want to make it too difficult to submit keys for 
this web.

But anyone else could devise his or her own web, and administer it however
he or she pleased.  A request to a keyserver would include a list of webs,
in order of preference, that the user would be willing to deal with.  At
the end of the list would be the default web, in case nothing better was
available.

A web could be defined by a single top-level public key and a set of 
rules.  Perhaps a text based program -- a sort of "meta-pgp" -- could 
check chains of signatures to validate a key.

Suppose, for example, that I'm administering a web of trust.  I set up 
the web so that I can deputize notaries who can in turn sign user keys.  
Lets further assume that all signatures are good for a year.  A keyserver 
would return a text file containing: (a) the user's key, concated with a 
header specifiying the date it was signed by the notary, and (b) the 
notary's key, concated with a header specifiying the date it was singed 
by me.

We'd want "meta-pgp" to be able to handle complex rules which would give 
it the flexibility to implement a wide variety of webs.  Perhaps it could 
use prolog-ish style induction to determine if a key was good.

Does this make sense?  Is it something that was already proposed and 
discarded?


==
Alex Strasheim | finger astrashe@nyx.cs.du.edu
alex@omaha.com | for my PGP 2.6.1. public key


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

iQCVAwUBLtmV+hEpP7+baaPtAQH3kgP8DmycpNrZKQRpyK1rclxJnIY2bdT5m4iM
p7IQ7nI07PSMn+ldye2xG5jjms42CR0BVvk4hhdGzDJwcgdd3FHFC7xNHvhk+SOE
4EHqpyW+YdNSe3A7+sMZp30mgWEnvHOpnrU9UiMUIaC8gcLk3GlkXdxDG+SWGwv/
1yesnbaUxYM=
=p2UQ
-----END PGP SIGNATURE-----