-- James A. Donald:
In my blog http://blog.jim.com/ I post "how email encryption should work"
On 8 Apr 2005 at 22:17, Bill Stewart wrote:
I see a couple of problems with your proposal. I'm not sure I like your external trusted mail-server assumptions
Trusting the mail server is merely the default. The user can use a different password for the certificate server, and if that password is strong enough to resist offline attack, he does not have to trust the certificate server - but all that is "advanced cryptographic options", which regular people are not expected to touch.
Your plan is really designed for a small number of addresses per sender, as opposed to a quasi-infinite set of tagged addresses. It's becoming pretty common for anti-spam reasons to give different recipients different mail addresses like tag@mydomain.com (or tag@mysubdomain.domain.com) or myname+tag@domain.com so you can track and whitelist/blacklist people you communicate with,
This does not seem to me to be a problem. When one uses a large number of addresses one does not want external people to know, or be readily able to prove, that these multiple addresses map to a single address - therefore one wants separate keys for each address. These multiple addresses are akin to inverse petnames. People of categoy X know you as JoeX, people of categoryY know you as JoeY, and people of the category client know you as Joe's Consulting Services Incorporated In the proposed scheme, the default case is that JoeX, JoeY, and Joe's Consulting services each get globally unique public and private key, without Joe doing anything or thinking about it. That seems correct behavior to me.
- Is (sender+recipient+timestamp+message) the right thing to sign? The Subject: line is in the mail headers, but it's probably something that should be part of the message. I'm not sure about some various X-headers.
Subject should of course be signed - and in encrypted messages, subject and timestamp should be encrypted.
And of course the From: line includes both the email address and the sender's name, and the sender's name may be different for different recipients (in some sense, it may be the recipient's petname for the sender.)
As in the petname prescription, petnames should be translated to global names immediately after leaving the user interface. Zooko's triangle: email addresses are global and securely unique identifiers, but not necessarily memorable. In the proposed system, the email address may also identify a key, or several keys. In the default case A key maps to one, and only one, email address, but an email address may map to none, one, or many keys. Most commonly one key. Nicknames are global and memorable, but not necessarily unique. Petnames not global, but are memorable and unique per user The user will commonly adopt the nickname or an abbreviation of it as a petname, but he does not have to. The client software, however defaults to the first seen nickname as petname, if there is no collision or near collision. Thus in the email address, James A. Donald <jamesd@echeque.com> "jamesd@echeque.com" is the globally unique identifier, "James A. Donald" is the nickname, which the recipient might ignore, substituting the petname "jim" Assume the recipient has substituted "jim" Then when the recipient reads mail from jamesd@echeque.com, he should see "jim" on the from line, even though what was sent and signed was "Hound of the Baskervilles <jamesd@echeque.com>" (Due to the fact that I recently changed the nickname after the recipient gave me a petname - alas a user assigned petname takes precedence over a sender nicknam) Then when the recipient replies, he should see "Jim" on the "To" line, but this gets translated to Hound of the Baskervilles <jamesd@echeque.com> before the message is signed, encrypted, and sent. (The nickname does not get frozen in, but may change at any time, potentially causing confusion. Still, if someone changes his nickname, he cannot complain about confusion.)
- Also, if you're attaching a key strictly to the email address, what happens to old signatures if you move email addresses?
Unavoidably, digital signatures are going to be more transient than ink signatures. It is the nature of the technology. Fighting it will only lead to complexity and difficulty of use. If someone values a signature, perhaps because it is a business name associated with a good reputation, he best have a personal and valuable domain name, as most such businesses do. If you are worried about being impersonated, you are quite likely writing from an address something like customer_support@e-gold.com, in which case you are NOT going to move email addresses. (Actually customer_support@egold.com never sends email because there are so many spammers forging that address. This proposal is designed to address that problem. The names that are valuable to protect, are not going to be changed, because they are valuable.
One option is to do what you can do in Crypto Kong, where you send a message from old-address signed by old-address, saying that you'll be using new address and new key, but that seems a bit awkward, since you need a convenient way to include the new keys for people who whitelist you or who you only want to send encrypted mail to.
This proposal is designed for Joe Sixpack. Crypto Kong is not. One probably should have "notice of change of address" capability, wherein someone can persuade other people's clients to be willing to switch the globally unique identifier associated with a petname, but I suspect Joe Sixpack would not use it correctly. Come to think of it, I suspect I would not use it correctly. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG /sTVFbs01dVcl9T0AB/DqTVG+nbPmjyiDNxMivMj 4CY4mIrULimk2rhNnFDTBK5cwSvBBnI0nisok5g8c