On Fri, 2 Jun 2000, Ian BROWN
<I(_dot_)Brown(_at_)cs(_dot_)ucl(_dot_)ac(_dot_)uk> wrote:
This is a really important thing we need to sort out. There was extensive
discussion of it almost two years ago (!) but I don't know if that resulted in
anything in the PGP/MIME draft.
Ned Freed's suggestion seemed to be widely agreed upon: I've attached his last
e-mail on the subject, but you can read the discussion in the archives at
www.imc.org
So far in this thread, two methods of encrypting headers have been
discussed: encapsulating a complete message in a message/rfc822 and
encapsulating an SMTP session in BSMTP. Both can be used for end-to-end
encryption and the first probably inter-operates quite well amongst
existing PGP/MIME or S/MIME clients.
However, encrypting message headers could also be potentially useful for
protecting stored messages as well, but here the message/rfc822 solution
is not so useful (and BSMTP not appropriate at all).
For instance, an IMAP client may want to allow its users to encrypt all
messages being archived on an IMAP server in order to protect the user
against any server security event. It could do this by encapsulating
existing messages in a message/rfc822 and holding the resulting
encrypted message in a vanilla outer message header (e.g. no subject,
all addressees set to the user themselves etc...).
However if this is done to lots of messages, the problem arises that the
user won't be able to distinguish between messages without the client
downloading and decrypting all messages (including bodies) first!
Two things seem to be needed to usefully support this sort of stored
message encryption: the ability of a client to know that there are some
replacement headers in an encrypted message and the ability of the
client to decrypt those headers independently of the body.
This could be accomplished using an unencrypted multipart message, where
the first part could hold the headers (text/rfc822-headers, encrypted
using PGP/MIME or S/MIME) and the second part could hold the body (again
encrypted). If a new type were defined (multipart/rfc822?), an IMAP
client could recognize the top level Content-Type, download and decrypt
the secure headers and thereafter display the decrypted header
information to the user.
Just an idea, but without something like this, re-encrypting messages
for storage involves either making the user enter alternative header
details, or not securing the headers in the first place.
--
Ian Bell T U R N P I K E Ltd