public-key: the wrong model for email?

Ed Gerck egerck at nma.com
Wed Sep 15 14:39:25 EDT 2004


[Perry: please use this version, if possible]

Public-key cryptography burdens the recipient and puts the recipient in
charge, while the sender is at the recipient's mercy. Is this the right
model for email security? After all, the sender is the party at risk.

To clarify, my comment is not that PKC is not useful for email. I believe it
is, but not directly used as it is today.

What I am saying is that the problem is key distribution. I want to separate the
key distribution solution as directly done by PKC today (send the public-key) from
a possible general solution for PKC key distribution that does not require sending
the public-key. The point is that when PKC solves this problem directly, it solves
it in a way that's useful for webservers (the webserver does not have to
trust the client's certificate) but presents difficulties for email senders (the
sender has to trust the recipient's certificate). Email use of PKC treats the
recipient as a server.

I think that what we need is a key distribution method for email (that can still
use PKC and PKI) where, because the sender has all the risk, the sender defines how
email is secured and delivered. The recipient should always be able to receive
it, without too much burden or required previous work.

For example, let's see how FedEx works. The sender chooses the service and the
type of envelope to protect the message. The sender also chooses the instructions
that must be followed before the envelope can be opened by the recipient.
The recipient has no charge to pay for, or burden, in order to receive the
envelope, and does not have to do anything before the envelope is sent. The
recipient is able to verify the identity of the sender and, if so desired,
refuse the envelope. The recipient can open the envelope if and only if
the recipient is willing to follow the sender's instructions (e.g., providing
name, address, date, signature).

Yes, SSL and public-key encryption are and continue to be a success for web
servers. However, the security model for protecting email with public-key
cryptography seems to be backwards, technically and business wise. The sender,
who is the party at risk, has to trust a lock provided by the recipient (his
public-key) to protect her secrets (the message). If FedEx would provide message
security a la PGP, PGP/MIME or S/MIME email, the sender would have to convince
the recipient to pay and send in advance an envelope for the sender to use.
The sender, however, would never know whether the envelope indeed prevented
others from prying into its contents.

A better situation would arise if the lock (i.e., the envelope) would be controlled
by the sender. Moreover, the recipient is not the business driver who needs to
provide, pay for and protect the lock. The sender is the party who has the
motivation to spend money to provide and protect the lock.

In short, I find that public-key cryptography cannot solve the security issues of
email when used as it is today and, most importantly, cannot provide the needed
motivation for users, senders and recipients, to buy into it.

It's not a matter of improvements in usability, better pricing or user education
[1]. It simply does not work as it should work. That's also why, IMO, it does
not take off. It is using the wrong mathematics for the problem.

Does anyone know of any email system that would put the sender in charge?

Comments?

Cheers,
Ed Gerck

[1] Public-key cryptography gives the impression that email message security can
be achieved quite simply. The public-key can be distributed at will, no need for
secrecy, and anyone can receive private and secure messages. The same procedure
being applied to each side, sender and receiver, both could immediately engage
in private and secure communication.


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list