::scr tales from the crypto
Alex Robinson
scr@thegestalt.org
Fri, 19 Apr 2002 19:39:52 +0100
[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?