[Cryptography] Functional specification for email client?

ianG iang at iang.org
Sat Aug 31 09:35:34 EDT 2013


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



More information about the cryptography mailing list