(Sorry if this is a duplicate and I'm only greylisted or something. Stupid hotel proxy servers....) 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