ietf-smime
[Top] [All Lists]

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

1998-09-18 05:20:45
In article <01J1WTASZMX291VY4C(_at_)INNOSOFT(_dot_)COM>, Ned Freed
<Ned(_dot_)Freed(_at_)innosoft(_dot_)com> writes
(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.


Thought as much :-)

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.

I was just thinking of encryption, but of course a scheme that covers
signing headers as well as encrypting them is so much the better.


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.


My problem with that was that the intent of encapsulation would not be
clear. However, putting a parameter on the message/rfc822 to make it
clear seems to solve the problem completely.

Later, you wrote:

Its clear that this indicator has to be on the "inside", since you want the
signature to be able to cover it. This then begs the question of whether
it should be an attribute of the signature/encryption facility or of the 
MIME message/rfc822 content.

Putting the parameter at the encryption header level announces that
there are hidden headers that will be substituted, though maybe that's
too minor a security breach to worry about.

A parameter at the message/rfc822 header level would in one extension
cover signed, encrypted, encrypted-then-signed and encrypted-and-signed
messages, and would even allow messages to be resent without using
Resent- headers if anyone has a use for that!


-- I've suggested adding
it several times in the past, but was never able to get much support
for it.


Hopefully this thread will have demonstrated sufficient support.

-- 
Ian Bell                                           T U R N P I K E  Ltd