Some comments, only.
On 30/08/13 11:11 AM, Ray Dillinger wrote:
Okay...
User-side spec:
1. An email address is a short string freely chosen by the email user.
It is subject to the constraint that it must not match anyone else's
email address, but may (and should) be pronounceable in ordinary
language
and writable with the same character set that the user uses for
writing.
They require extension with a "domain" as current email addresses do,
but not a "domain name" in the IETF sense; just a chosen disambiguator
(from a finite set of a million or so) to make name collisions less of
a problem.
2. An email user may have more than one email address. In fact s/he can
make up more email addresses at any time. He or she may choose to
associate
a "tagline" -- name, handle, slogan or whatever -- with the address.
An email user may have one or more identities... (confusion between
email addresses, keys, chat handles, etc).
3. When an email user gets an email, s/he is absolutely sure that it comes
from the person who holds the email address listed in its "from" line.
S/he may or may not have any clue who that person is. S/he is also
sure that no one else has seen the contents of the email. The
"tagline"
and email address are listed in the "from:" line.
This requirement is troubling, and it has bedevilled many systems
because it has artificially locked them into perfect traffic analysis,
low key agility, poor economics, and messy identity semantics.
It typically is an assumption of the email providers that an email
address must have a certificate, and this allows the certificate to be
'checked' against the email address. But it is not necessary nor
particularly effective.
A better requirement might be worded:
When a user receives an email, she is sure that it comes from the stated
identity as found in the address book. The stated identity may not be
related to the "from" line.
4. A user has an address book. The address book can be viewed as a
whole or
as seen by just one of the user's email addresses. IOW, if you
have an
email address that you use for your secret society and a different
email
address that you use for your job, you can choose to "be" one or
the other
and your address book will reflect only the contacts that you have
seen
from that address or have been visible to under that address.
5. A mail client observes all email addresses that go through it.
all identities (email addresses and/or keys)...
When a
user receives mail from someone who has not directly sent them mail
before,
the client opens a visible entry in the address book and makes
available
a record of previous less-direct contacts with that address, for
example
from posts to mailing lists, from CC: lists on emails, etc. The
client
also makes visible a list of possible contact sources; places where
the
correspondent may have seen the address s/he's writing to.
However, often
enough, especially with cases where it's a "scribbled on a napkin"
address,
the client just won't know.
6. When a user sends mail, s/he knows that no one other than the holder of
the address/es s/he's sending it to will see the body of the mail,
and also
that the recipient will be able to verify absolutely that the mail
did in
fact come from the holder of the user's address.
This needs to nailed down, otherwise the system falls into the abyss of
digital signatures. What this means (at a lower level) is that every
mail is digitally signed by the sender. It needs to be stated that the
signature of the sender's key means that the message came from the
sender's key, and not anything else. Especially, it is not a signed
contract, not a non-repudiable bla bla, and is not even a proof that the
person sent the message (without significant other support).
That is, the digsig is a low-level protocol tool, not a legal digital
signature.
Also, to bed in a complete understanding, a separate requirement 6.b
should be added for a second signing process using separate "signing
keys" following the notions expressed in (eg) EU digital signature
directive (eg) OpenPGP cleartext signing. However, this should be
clearly stated as optional, as such digital signatures are fraught, and
if not optional, the system will fail to be implemented and be accepted.
iang
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
