How email encryption should work

29 Mar 2005

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

Here is how email encryption should work:

    * The user should automagically get his key and 
    certificate 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 labeled 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 the correspondent's public 
    key 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 recipient's address. If 
    the email is encrypted, the signature can only be 
    checked by someone who possesses the decryption key.

    * If 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 software that follows 
    the same protocol, 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, 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
     VvdTZKUxpdfcDRAGwBSupIYVIUGAAE5orXRkJl8q
     4y7qVNj7u/H3nJLgyAs5pGM2tDFOcyCyC9L+vbbpa