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