I think this is a good summary of how it should work, except, that I
don't think messages should be signed by default, only authenticated
(MAC). Users should be clearly aware of making a non-repudable statement.
Plus, it may be preferable to use something like matasignatures.org to
ensure authenticated e-mail does not alarm recipient with non-compliant
e-mail clients.
A missing element is motivation for getting something like this
deployed... I think spam could offer such motivation; and, I strongly
believe that a cryptographic protocol to penalize spammers could be one
of the most important tools against spam. I've presented such a simple
crypto protocol (SICS) in SCN'04 [available off my site], and now work
on open-source implementation (with student Jonathan Levi) of an
improved version (SICSv2...), to be published soon. [I can send draft to
experts willing to provide feedback...]
Best, Amir Herzberg
James A. Donald wrote:
--
In my blog http://blog.jim.com/ I post "how email
encryption should work"
I would appreciate some analysis of this proposal, which
I think summarizes a great deal of discussion that I
have read.
* The user should automagically get his certified
key when he sets up the email account, without
having to do anything extra. We should allow him the
option of doing extra stuff, but the default should
be do nothing, and the option to do something should
be labelled with something intimidating like
“Advanced custom cryptographic key management" so
that 99% of users never touch it.
* In the default case, the mail client, if there are
no keys present, logs in to a keyserver using a
protocol analogous to SPEKE, using by default the
same password as is used to download mail. That
server then sends the key for that password and
email address, and emails a certificate asserting
that holder of that key can be reached at that email
address. Each email address, not each user, has a
unique key, which changes only when and if the user
changes the password or email address. Unless the
user wants to deal with “advanced custom options”,
his “from” address must be the address that the
client downloads mail from – as it normally is.
* The email client learns correspondent's public
keys by receiving signed email. It assigns petnames
on a per-key basis. A petname is also shorthand for
entering a destination address (Well it is shorthand
if the user modified it. The default petname is the
actual address optionally followed by a count.)
* The email client presents two checkboxes, sign and
encrypt, both of which default to whatever was last
used for this email address. If several addresses
are used, it defaults to the strongest that was used
for any one of them. If the destination address has
never been used before, then encrypt is checked if
the keys are known, greyed out if they are unknown.
Sign is checked by default.
* The signature is in the mail headers, not the
body, and signs the body, the time sent, the
sender's address, and the intended recipient's
address. If the email is encrypted, the signature
can only be checked by someone who possesses the
decryption key.
* If the user is completely oblivious to encryption
and completely ignores those aspects of the program,
and those he communicates with do likewise, he sends
his public key all over the place in the headers,
signs everything he sends, and encrypts any messages
that are a reply to someone using similar software,
and neither he nor those he corresponds with notice
anything different or have to do anything extra –
other than that when he gets unsigned messages, or
messages with an key different from the previously
used key, a warning comes up – an unobtrusive and
easily ignored warning if he has never received a
signed message from that source, a considerably
stronger warning if he has previously received
signed mail from that source.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
gOiN3HXQALAQHbKEOYdu/aZClRbPTEfjzyLpGAMx
4dJddm3vIwGuBnfc933djUV6zT4DWvM26KobmzFyC
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
.
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
