The Problem
===========

Using GnuPG (or equivalent such as PGP) to encrypt your email is
useful, if done routinely. If done selectively it is less useful,
as an adversary can use traffic analysis to find who you want
secret correspondence with. (Here I am considering an adversary
such as a governmet with desires to monitor all email).

Also, the more people routinely encrypt their email, the
harder it is for governments to find the needle of thier
citizens posts they really want to spy on in the haystack of
millions ot encryped emails.

Many citizens are concerned by government plans to monitor email,
but few routinely encrypt theirs. Why? Because it is a hassle to do.


Proposed solution
=================

To make sending encrypted email easier, by getting the email user
agent (MUA) to do the hard work. Define a standard in email
headers for encryption; the purpose of this standard is to allow
encrypted emails to be send almost completely automatically if the
MUAs at each end support the standard.

The standard defines two new headers, X-GPG-Key: and
X-GPG-Fingerprint:. These contain the sender's public key and its
associated fingerprint. The public key is sent radix-64 encoded,
probably over multiple lines, 64 characters per X-GPG-Key: header,

Compliant MUAs will, by default (overridable by the user) generate
a public/private key pair and transmit the public key.            


When a compliant MUA sees an incoming email with the headers it
makes a note of it. When the user sends an email to that email
address, the MUA can encrypt it with the reciever's public key,
so that only the receiver can read it.

Compliant MUAs will have a system for checking that the key and
fingerprint that are recieved from incoming email are the real
keys of the sender, and not altered as part of a man-in-the-middle
attack. But the system would default to doing everything
automatically (and perhaps telling the user, via a dialog box,
what is going on).

As well as defining the headers, a project to implement this
scheme would include adding the relevant functionality to one or
more of the popular open-source MUAs. Makers of closed source MUAs
would be invited to use the protocol too.


Possible pitfalls
=================

There is the possibility of a man-in-the-middle attack, unless
the public key is verified by another pathway; such verification
detracts from the aim of ease-of-use of the system: it should be
as nearly as possible transparent to the user.                             

For the system to work with mailing lists, the list itself will
have to know about the protocol. Even then, that wouldn't work, unless
everyone on the list was using a compliant MUA, because if some MUAs
wanted unencrypted email, the adversary would be able to read those
copies. Similar comments apply to email sent to more than one
recipient.

Conclusion
==========

What do people think of this scheme? Would it work as planned?
Does anything like this already exist?

How successful could such a scheme be? Well, if 5% of email users
start using compliant MUAs, and there are 200 million email users,
and each sends on avarage one non-multiply-posted email per day,
that's 500,000 encrypted emails a day for the authorities to
catch. Obviously, as the system gets more popular, it gets more
successful.                                                 


;end