Transparent Email (WAS disable telnet to port 25)

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

The big problem 
   with key distribution is the web of trust:  who gets to decide which keys 
   are good?

This whole area of key distribution has generated much confusion.  A
perfect world is described, and then everyone is assumed to
participate in achieving this world.  This approach of generality,
however, is notably more complicated than a world where responsibility
for security is partitioned, where  each user does not have to worry
about all the possible systemic security issues.

Proposition: You don't need to be responsible for making sure that the
other person is being spoofed; that's their responsibility.

A common situation where this proposition makes a significantly
simpler system is exactly in the case described, where you and your
email correspondents wish to exchange keys.  Suppose, in addition,
that you two met online and that your only channels of communication
are electronic.  The goal here is to create persistence of identity;
identification with a physical body is not needed.

In the PGP case you start with your own key, which you trust, then
look for a chain of signatures to the destination.  This chain can be
rather cumbersome to produce.  It's overkill, as well, since all you
really needed to know is that the key was not being translated on your
own end.  The PGP trust chain largely accomplishes that, true, but not
as simply as possible.

Alternatively, you save the first piece of email that you receive from
your correspondent; it has a digital signature on it.  Now _by
whatever means_, you obtain a public key by which to verify that
signatures on email you receive are the same.  You yourself need to
ensure that you aren't getting spoofed; you can do this by, say,
having your correspondent send mail to two different locations, or by
using a second channel to obtain the key by, or by using a PGP trust
chain, if one is available.

The original model for public key communications seems to have been
one channel with an interposer.  The real world is much more
complicated than that.  One can obtain good protection, at least as
good as a trust chain, by crossing organizational boundaries.  The
argument that trust chains are better because they are cryptographic
carries no weight; the decision at each link to make a signature is of
social, not cryptographic, character.

In particular, the design of PGP that ties key management inextricably
to encryption is bad and will contribute to an inflexibility that will
eventually sink PGP if it is not corrected.

   Perhaps we would have 
   a default web, which would have everyone's key in it.  

This is a really bad idea.  Some "public" keys should not be made
public, but rather revealed only to the correspondent.  Forward
secrecy is the reason.  If the public key has never been in the
possession of an opponent, and assuming the results of the public key
operation yield little or no information about the modulus, then when
the keys are changed and destroyed, no amount of factoring can find
the private key because the public key isn't around to factor.

Eric