--
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
> [EMAIL PROTECTED] (or
> [EMAIL PROTECTED]) or
> [EMAIL PROTECTED]
> 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
<[EMAIL PROTECTED]> "[EMAIL PROTECTED]" 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
[EMAIL PROTECTED], he should see "jim" on the from
line, even though what was sent and signed was "Hound of
the Baskervilles <[EMAIL PROTECTED]>" (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 <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED], in which case you are NOT
going to move email addresses.
(Actually [EMAIL PROTECTED] 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
