ietf-openpgp
[Top] [All Lists]

Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages

1998-09-17 11:12:30
(Apologies if this has been done to death in the past - I can imagine
Ned sighing about protracted discussions prior to RFC1847 - but I
couldn't find any discussion in the archives)

RFC2311 (SMIME) and RFC1847 (upon which PGP/MIME has been based) only
allow MIME headers to be protected by the encryption process. Was there
any discussion during the preparation of RFC1847 about the possibility /
desirability / feasibility of allowing general RFC822 headers to be
included in the encrypted part of the message?

There were extensive discussions of this. I probably have several hundred
messages archived on this topic, and there were also WG discussions and several
private meetings where the design team covered this area exhaustively.

The basic conclusion was (and is) that this dog doesn't hunt and cannot be made
to hunt. The problem is that message headers are routinely rewritten by
intervening MTAs as messages are transferred via SMTP. They are refolded,
reordered, addresses are converted from one form to another, encoded
words are added or removed, entire fields are added or deleted.

And all these activities are the rule, not the exception. And it is far more
likely to happen to fields it makes sense to sign, such as subject, to/cc/bcc,
comments, etc. than to any others.

In short, if you want to keep the transports from modifying things, you cannot
put them in the primary header. You either have to put them in the body. And
given this, MIME provides the obvious means to do this if that's what you're
after -- nested messages.

The most obvious candidates for headers to be encrypted along with the
MIME headers would be Subject: and Disposition-Notification-To: (the
subject the sender may have intended to use may be too sensitive to use
as the subject of the open message: the sender may want any MDN to be
sent only when the message is decrypted), though cases could probably be
made for just about any RFC822 header.

Could (and should) any replacements for RFC2015 and RFC2311 be amended
to allow RFC822 headers to be sent encrypted, and for the decryption
process to swap any encrypted headers found with the corresponding
headers in the actual message?

There is no need to do this. All you need to do is use MIME encapsulation
to put the real headers into the body of the message.

One thing that would be nice is if there was a way to say in the signature
information that the inner message is actually supposed to replace the outer
container message. (This could also be done as a parameter to message/rfc822
if need be, although there are arguments for doing it in the signature.

There is one other thing that is missing, however, and that is a means of
encapsulating the entire message including the envelope. There are many
applications where the envelope itself is sensitive and needs end-to-end
protection.

And there is a proposal on the table to deal with this:
draft-freed-bsmtp-02.txt. This defines envelope encapsulation and the semantics
that necessarily follow from doing it.

As availability of encryption software becomes more widespread, many
end-users may find SMIME/PGP most useful as simply a transport security
mechanism rather than a way of securely storing messages. In any case,
MUAs implementing PGP or S/MIME probably already allow the user to save
the decrypted version of a message.

Sure.

It would be good if there were an interoperable way of making the
stored, decrypted message reflect the message the author would have
liked to send in the first place. It would be particularly nice if the
author could transmit the intended subject of a message when this may be
too sensitive to put in the open message headers.

See above.

                                Ned