how email encryption should work

James A. Donald jamesd at echeque.com
Mon Mar 28 21:00:21 EST 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.

    * 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 majordomo at metzdowd.com



More information about the cryptography mailing list