Re: ::scr tales from the crypto

[Alex Robinson <scr@xxxxxxxxxxxxxxxxxx>]

[All of Matt's message zapped so as to convince the signal/noise 
fascists that this is a 'good' mail]

http://www.hushmail.com/about_hushmail/openpgp/
vs
http://www.viacorp.com/crypto.html#messages

The second approach of just using webpages and browsers to do the 
dirty work and route round the whole retrieval of keys and ensuring 
that the key is actually up-to-date seems vastly superior (if you're 
talking about John and Jane Noclue)

Funnily enough I once started writing an email to (void) on this very 
subject (after reading the article above), attempting to sketch out 
some method of mapping email addresses to websites which would then 
do the encrypting on the fly (well whatever kind of server you want 
to call it, what with all the RPC SOAPY TRENDINESS around these days, 
there's no reason it couldn't actually be a traditional email client)

I've lost my original notes (and stupid diagram) but I think this sums it up

1. Sender hits "send message"
2. Client looks up address and contacts relevant server
3. Server passes back public key
4. Client encrypts message
5. Client sends message to server
6. Server passes message to recipient
7. Recipient decrypts message with private key

Now obviously, the tough part is how to get to the server that has 
the key. Well, couldn't that be handled in much the same way that dns 
is? Individual domains can run their own, or alternatively they can 
delegate the responsibility to somebody else. And it would only be 
the private key being stored here (hand waves at technical 
implementation of getting the keys on to the server but to the user 
it would be something along the lines of set up the details of your 
online key server, then click generate key and hey presto)

The client could also send the mail insecurely if that was either 
desired or no key could be located and the sender wanted to proceed 
in any case

Is this idea of key servers mad, impossible to implement or already 
in existence?