Subject: Re(2): The subject line leakage problem

From: Jim Craigie <[email-masked]>
Date: Wed, 9 Jan 2002 3:53:44 +0000

> I think this is the wrong way to go about it. If you want to protect an
> entire message including its outermost headers, simply place the entire
> message inside your protective envelope using the message/rfc822 construct.
> Then strip the outer, unprotected header to its barest essentials.
> 
> The process is then reversed by the receiver.
> 
> This approach uses nothing but existing media types and can leverage existing
> support for message/partial and message/rfc822. It doesn't require that you add
> additional fields to your structures, with all the attendant deployment
> problems that will cause.
> 
> > The required support for message/rfc822 is attractive, but I am not sure
> > that is has the correct semantics.  Can you explain your idea further?
> 
> See above. At most what's needed here is an indicator in the protected content
> that it is to be merged with the outer message header on receipt. That could
> easily be done with either a message-context or a content-disposition field in
> the protected content.
> 
> 				Ned

I agree with Ned's proposal. However, the indicator that Ned mentions is an absolute requirement. This indicator is the only way to differentiate a message where the whole header is protected, from a message which is forwarding another. In the latter case it is essential that the From field from the outer unprotected header is not supressed, since it indicates who did the forwarding.

There also needs to be a precise specification of merging the protected header with the unprotected header. The From and Date from the protected header must replace those fields in the outer header (since they cannot be removed from the outer unprotected header). But which other header fields in the outer unprotected header are to be replaced, and which fields are be presented as the union of both headers. For example, Received fields should probably be presented as the union of Received fields from both headers (e.g. to allow a message to be signed by a domain gateway without losing the Received fields before signing).

Jim