"Robert G. Brown" wrote:
Currently, email addresses are relatively "simple" objects and as such
are easy enough to remember (for humans) and communicate (for humans).
You propose to make an address a "complex" object: the simple address
plus kilobyte-sized blocks of text or binary data such as:
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.7 (GNU/Linux)
mQGiBDprOxURBADW+ybmMpoBfbRADv3OzXaaIQVWGDoaNsR4uxstcJgo+FYMcO9B
Ag7eXRLfOQFPPS3211W/f1/GaQa70ZaPZaQV/A9POIGfRIbcfePHaIUUXYulO3Nh
Bqewb5JZjzkj0yZWdjzK/OSBEPITXMXyTDVnG0+Y4YHHLDOODnnkSOlZKwCg453O
....(much much more)
The key can be given by:
1. return mail requesting an encrypted message with the
attached key (as I wrote in my first posting on this suggestion),
2. key server, by using an URL
3. by searching google
4. by using DNS records
5. by reading the email's signature line when my mail reaches you
and you want to reply to me.
So, there are many, simple and automatic ways for PK distribution.
PK certification is another thing, but encryption does not it.
Also, humans have been using complex postal addresses for centuries,
without even the benefit of computers to help with them until quite
recently. Complexity is in the eyes of the beholder.
On the other hand, this additional degree of complexity will be a
horrible burden in time, energy, and money to ordinary users of mail at
every level and especially to systems administrators responsible for
training those users and de facto responsible for managing the data
problem the composite "address" object would represent. Communicating,
managing, and remembering email addresses like "joe(_at_)whereever(_dot_)edu"
is
already "challenging" to many, if not most, users of email and is
obviously equally challenging at the corporate/professional level. Let
us recall that most current AV software is still stupid enough to
consider the From address to actually be valid for viruses and SPAM and
cannot even manage to parse the real message header in sensible ways.
Now visualize these same bozos trying to deal with messages whose header
contains a 1-2K key:-/
This will all require a level of automation and user-friendliness way
above what we have today. Nonetheless, possible and necessary if
we want to (1) preserve email confidentiality and (2) provide an even
mandatory burden to sending email.
On the flip side, I can see all your arguments above applying to
the difficulty of sending spam -- in addition to the time burden.
Obviously, people will no longer be able to just say "here's my email
address".
Not true. After you send an email and you'd get a bounce requesting an
encrypted message, with the public-key included. In fact, you can
easily use your email as a way to distribute your PK with the benefit
of challenge-response -- if your email is active, the sender gets the
current key for that address. You can also use it to update your PK,
easily.
Business cards will need to be roughly 4x6" and covered
mostly in small type. Most users will simply rebel. Most systems
people will simply rebel.
:-) not really...see above.
People CAN send encrypted, signed email now,
but how many do?
5%. The failure is actually ours, not making it easy to use. Just ask
any email user...How do they feel when they understand that email
is really like a postcard... open for anyone to read? How do they
feel about spammers having near zero cost to send them messages
while they need to use valuable time and resources to weed them out?
You are also suggesting that the encryption step, by being "expensive"
computationally, will at least slow down the spammers. This assertion,
which has been made several times now, is simply not true.
[snip, good comments]
The point is that it CAN be made very expensive for sending 100,000s
of emails. In addition to the PK encryption of the random symm key
used to encrypt the message (in PGP, for example) you can also add
the recipient's PK MACs to tie the recipient's PK to the message as
well. Further, the proposal should include "puzzles" to be solved
by the sender (a la hashcash) that can penalize an unknown sender as
much as desired and trickle its output as much as needed.
Users can also require less burdensome encryption from known parties,
without "puzzles".
There is nothing to prevent a spammer -- as an entity with NO previous
relationship to the receiver -- to be penalized at will, while known
users mail send messages with regular encryption or even no encryption
at all (by using whitelists).
I'm thus led to the opposite conclusion that you suggest: I think
that it is clear that this proposal can have a significant
impact on SPAM generation, while but it will not have any, or hardly
any, negative impact on ordinary mail users.