Some comments, only.

On 30/08/13 11:11 AM, Ray Dillinger wrote:


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
     and writable with the same character set that the user uses for
     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
     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
     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
     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
     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
     the client opens a visible entry in the address book and makes
     a record of previous less-direct contacts with that address, for
     from posts to mailing lists, from CC: lists on emails, etc.  The
     also makes visible a list of possible contact sources; places where
     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"
     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.


The cryptography mailing list

Reply via email to