-- In my blog http://blog.jim.com/ I post "how email encryption should work"
I would appreciate some analysis of this proposal, which I think summarizes a great deal of discussion that I have read. * The user should automagically get his certified key when he sets up the email account, without having to do anything extra. We should allow him the option of doing extra stuff, but the default should be do nothing, and the option to do something should be labelled with something intimidating like “Advanced custom cryptographic key management" so that 99% of users never touch it. * In the default case, the mail client, if there are no keys present, logs in to a keyserver using a protocol analogous to SPEKE, using by default the same password as is used to download mail. That server then sends the key for that password and email address, and emails a certificate asserting that holder of that key can be reached at that email address. Each email address, not each user, has a unique key, which changes only when and if the user changes the password or email address. Unless the user wants to deal with “advanced custom options”, his “from” address must be the address that the client downloads mail from – as it normally is. * The email client learns correspondent's public keys by receiving signed email. It assigns petnames on a per-key basis. A petname is also shorthand for entering a destination address (Well it is shorthand if the user modified it. The default petname is the actual address optionally followed by a count.) * The email client presents two checkboxes, sign and encrypt, both of which default to whatever was last used for this email address. If several addresses are used, it defaults to the strongest that was used for any one of them. If the destination address has never been used before, then encrypt is checked if the keys are known, greyed out if they are unknown. Sign is checked by default. * The signature is in the mail headers, not the body, and signs the body, the time sent, the sender's address, and the intended recipient's address. If the email is encrypted, the signature can only be checked by someone who possesses the decryption key. * If the user is completely oblivious to encryption and completely ignores those aspects of the program, and those he communicates with do likewise, he sends his public key all over the place in the headers, signs everything he sends, and encrypts any messages that are a reply to someone using similar software, and neither he nor those he corresponds with notice anything different or have to do anything extra – other than that when he gets unsigned messages, or messages with an key different from the previously used key, a warning comes up – an unobtrusive and easily ignored warning if he has never received a signed message from that source, a considerably stronger warning if he has previously received signed mail from that source. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG gOiN3HXQALAQHbKEOYdu/aZClRbPTEfjzyLpGAMx 4dJddm3vIwGuBnfc933djUV6zT4DWvM26KobmzFyC --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]