I read that last night, and was still musing on it...
James A. Donald wrote:
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
For clarity reasons, I think you mean that the default should be to not invoke the 'extra stuff' on automagic creation, rather than "do nothing" which is in fact what users get today - nothing.
be labelled with something intimidating like “Advanced custom cryptographic key management" so that 99% of users never touch it.
Concur. The notion that a user needs a cert from anyone else for the purpose of email is wrong; this doesn't mean denying them so they can take part in corporate nets for example, but that ordinary users in ordinary email will not get much benefit from certs signed by other agents.
* 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.
I would put this in the "extra stuff" category, and not in the default category.
The reason is that it creates a dependency on a server that might not exist and even if a good idea, will take a while to prove itself.
* The email client learns correspondent's public keys by receiving signed email.
The problem I've discovered with this is that the signing of mail is (I suggest) not a good idea unless you have a good idea what the signature means. I've not seen anywhere where it sets out what a signature means for S/MIME. For OpenPGP the signature is strictly undefined by the code, so that's a better situation - it means whatever you want it to mean.
Which means that most people under most circumstances should not send most emails out signed. Which sort of makes "signed emails" a poor carrier pigeon for a key exchange.
(I don't have a solution to this - just pointing out what I see as a difficulty. The workaround is that the user turns off signing and has to send an explicit blank signed email as a key exchange message. Clumsy.)
(One possibility is to put the cert in headers.)
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.)
Yes this would help a lot. Any petname set should be displayed distinctly from the default name.
(Oh, as a nitpick, a default address is not a petname, it's just a default name. A petname has to be set by the user to exist.)
* 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.
Right, the UI could do a lot to show what is possible by shading the various email addresses or adding little icons to indicate their encryptability state.
* 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.
I had an entertaining read of the paper on Naive Sign & Encrypt last night. There are a lot of issues in how signatures are combined with encryption, I don't think this is a solved issue by any means when it comes to email.
* 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
See caveat about signing above. I certainly agree that any message that can be encrypted should be encrypted.
If you thought that the threat was changing emails etc etc then it might be possible to create a cert that could just be used for message integrity and stick some tag in there that says "message integrity only purposes." Then, as long as the client at the other end said "this message was delivered without change" instead of "this message was signed" then this might work.
When cryptograpers say a message is signed, users think that a message has been signed.... getting around that confusion is quite hard.
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.
Yes, the model for an unobtrusive message is the red cross alert bars added in Firefox these days. They solve the popup nightmare quite nicely.
iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]