how email encryption should work

[James A. Donald]

    --
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 at mydomain.com (or 
>          tag at mysubdomain.domain.com) or 
>          myname+tag at 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 at echeque.com> "jamesd at 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 at echeque.com, he should see "jim" on the from 
line, even though what was sent and signed was "Hound of 
the Baskervilles <jamesd at 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 at 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 at e-gold.com, in which case you are NOT 
going to move email addresses.

(Actually customer_support at 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