Re: how email encryption should work
At 07:00 PM 3/28/2005, James A. Donald wrote:
In my blog http://blog.jim.com/ I post "how email encryption should work"
I see a couple of problems with your proposal. I'm not sure I like your external trusted mail-server assumptions, but they're probably good enough for many people, and other people will have better comments about them. 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, and some ISPs automagically translate between the two formats. Building a user interface that does that unobtrusively is probably a hard problem, or at least not a well-solved one, and building a cryptosystem that assumes a small number of addresses per user could make that style of mailer harder. A good user interface probably has some version of petname support, though, so there's some commonality with key handling. On the other hand, if you assume that most people will get domains, whether 2LD or 3LD or other subdomain, you could do a model that says that a user gets one key per domain, so you could think about hanging the keys off DNS. That may not be the right choice (do you want your email addresses to be easily correlated, and cracking/stealing one address's key to reveal the keys you use for everybody else? Or does the domain pretty much imply that to the skilled recipient anyway so who cares?) And of course it gets into the whole squabble about DNSSEC, and why its deployment failed, and whether it was trying to do a perfect job and therefore less scalable than a mostly-good-enough job, or at least into the politics of those questions if not the technology. The related problem is what to do if you *do* want different keys for different recipients; you could do that with different subdomains, or you could do a non-DNS approach. - 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. 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.) - Also, if you're attaching a key strictly to the email address, what happens to old signatures if you move email addresses? I suppose that's part of the point of getting your own domain name, so you can avoid having to change contact addresses when you change ISPs, but if you're using a new email address, how do you forward the signature? 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. Thanks; Bill Stewart
-- 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
participants (2)
-
Bill Stewart -
James A. Donald