Re: Transparent Email (WAS disable telnet to port 25)

[Alex Strasheim <alex@omaha.com>]

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

I think that the main problem with this is that it would require email 
addresses to be transmitted electronically.  My email address is 
alex@omaha.com, and one of the nice things about it is that I can tell 
someone what it is, and they'll remember it.  I'd hate to have to append 
a fingerprint to the address when I gave it out.

The big problem with secure mail in the real world is that most people
probably aren't willing to sacrifice much in the way of convenience in
order to get security.  We really need a Eudora-style program which would
look and act like Eudora does now, with encryption and signatures going on
in the background.  A scheme which would make addresses more complicated 
probably won't fly.

The general approach that I was proposing was to create a lowest common
denominator web of trust, but to allow anyone to create, maintain, and use
their own webs, using whatever criteria they deem appropriate.  This is, 
in my understanding at least, the best way to guard against the man in 
the middle problem:  keys would have to be signed by someone we trust in 
order to be accepted.  The idea is to put a lot of flexibility in the 
hands of users, making a very high level of security possible, without 
imposing the responsibilities this involves on people who don't want or 
need it.

In order to do this, we'd need a general system for describing and 
manipulating webs.  Ideally, a web could be defined with a single top 
level public key and a rule set.  They keyserver would return a text file 
which contained a chain of signatures in a text file, and a general 
program, which I'm calling meta-pgp, would be able to extract and verify 
the user's public key using the web's top level public key and the rule 
set.

The point of meta-pgp is to give people enough flexibility in 
administering their webs that they wouldn't feel constrained by the 
system.  It would work by allowing chains of signatures, and allowing 
supplemental information to be affixed to each key in the chain before it 
was signed.

Suppose, to take a simple example, I administer a web.  I decide that I'll
deputize people to sign user keys.  Each signature will be good for a
year. 

First of all, I'd have to sign the deputy's keys.  I'd meet with the 
deputies, and they'd give me their public keys in text format.  I'd 
prepend two fields of header information, a DEPUTY token, and a DATE 
11/28/94 token to the deputy's key, and then sign it with my public key.  
Then I'd return it to the deputy.

The deputy would do something similar for the user when he signed the 
user's public key:  he'd affix USER and DATE tokens, sign the result and 
give it back to the user.  He'd also prepend his own public key, signed 
by my top level public key.  The user would submit this to the keyserver 
database.

That way when someone wants to send mail to the user, they'd query the 
database.  The sender would send the keyserver the email address of the 
recipient, along with a list of acceptable webs, in order of preference.  
If the sender was willing to accept my web, the keyserver would return 
that chain, and the sender's meta-pgp would validate the key, based on 
the top level key for the web and the rule set.

The point of meta-pgp would be to allow people to use whatever kinds of 
webs they want, at the same time preserving the ability of generalized 
programs to verify keys.

The default web could be based on something simple, with comparatively low
security, allowing people to send in their keys via email and requiring
them to respond to an encrypted reply from the web administrator.  This
wouldn't be impossible to spoof, obviously, but it would allow a lot of
people to put their keys into circulation.  Those of us who would be
dissatisfied with such an insecure setup could make other arrangements.

[I'm sorry to describe the same proposal twice, but I wrote the last one 
in the middle of the night, and I was a little bleary...  I'm not sure 
how well I described it.]


> If I have never sent you mail, consider how I got your e-mail address?
> You could have sent your public key to me along with your e-mail address.
> If your public key is too big you could include a phoneticized secure hash of
> your public key and I could check big brother (the CA). I suspect that initial
> bits of a public key serve pretty well as a secure hash. Perhaps all email
> addresses should be accompanied by such a hash. The more initial bits
> the harder to find a fake public key with sutiable mathematical properties
> and initial bits that agree with your real pulic key.
> 
> If an email address and its associated PK are sent thru unauthenticated
> channels a man in the middle can substitute the PK. In the same situation,
> however, the man in the middle can substitute the email address!


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

iQCVAwUBLtoo3xEpP7+baaPtAQEkSwP/SlwhZ9TGnB0hpGMZ5L/WRjyKe7OTEAlj
yzYRGCPdEarvWkY9NtNDB1tqLJjomARJEZGD8jACSo25z8lgTXguVm98BxkzBErz
TlWhRuSBY/UzfBDLG7PMP5VlR6yosNrToErwbl7ZSAveZuC9+usjCXB8WGhvK+Qg
/zKGskP06iI=
=lEaX
-----END PGP SIGNATURE-----