ietf-openpgp
[Top] [All Lists]

Re: confidential subject lines -> use content description field w/ pgp/mime?

2000-06-09 05:49:40
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