[Dev] Automatic secure email

[Aaron Swartz]

On Wednesday, November 6, 2002, at 10:42  PM, Andy Hertzfeld wrote:
> the hash/URL approach requires the user to have access to a server, 
> and the ability to set it up, which we can't count on.

Anyone can publish their public key to the Web simply by pasting it 
into one of these forms:

http://pgp.mit.edu/
http://www.{us,ca,ch,dk,de,no,uk}.pgp.net/pgpnet/pks-commands.html

There are many others. You end up with a URL like 
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x79F0DF4B

> There are multiple existing cryptographic algorithms and formats; it 
> would be nice to be able to support as many as we can, including ones 
> not yet defined.

"While good formats allow you to select from a variety of options and 
extensions, there are times when this is not valuable. If there are, 
for example, two algorithms one can use to encrypt a message, all that 
means is that all encrypters are forced to be able to do both."
  - http://www.templetons.com/brad/cryptech.html

> The email round-trip (requesting a profile from a client, then 
> receiving it via email) adds an additional level of security, since 
> it's relatively hard to intercept someone's email, compared to sending 
> a message with fake headers.

Paranoid clients can do a verification ping. You can still encrypt with 
one less round trip (and the cost of your message possibly not getting 
through) and you'll never bother people using tools which don't support 
the system (imagine 100 new subscribers flooding a mailing list with 
"What's your key?" messages).

> It's nice to have the non-crypto part of the profile (what mime-types 
> you accept, and perhaps other APIs supported by the client, including 
> SOAP over email); it wouldn't make sense to include an elaborate 
> profile in every message.

Why would you want to do SOAP over email?

MIME is currently designed to be fully extensible without requiring 
such a profile.
-- 
Aaron Swartz [http://www.aaronsw.com] "Curb your consumption," he said.