[Spasm] Updating S/MIME handling of message/rfc822?

[Wei Chuang <[e-mail]>]

Hi,

I would like to propose that draft-schaad-rfc5751-bis-00 further specify
handling message/rfc822 processing and specify how to merge message headers
from
decrypted/decoded non message/rfc822 types mime parts.  If we can clarify
header
processing this could provide significant improvement in privacy as
revealing
headers like subject can reveal a great deal about the content of the
message
and even metadata like date can be used with traffic analysis to reveal
hidden
recipients (Bcc).

There already exists "Securing Header Fields" as experimental RFC7508.  This
proposes that certain message header fields are signed and verified, and
optionally can replace or delete the field.  This provides a high degree of
flexibility and one approach would be to standard track this.  But this RFC
requires a fairly significant change to S/MIME / CMS processing steps, and
there
would be a deployed base that would find it difficult to interoperate with.
Another more feasibile approach is to clarify RFC5751 message/rfc822
language.
Likely this can get most of the header hiding benefit with a smaller change
to
CMS processing.

This proposes that if it is desirable to protect header integrity and
privacy
that message/rfc822 be used as specifed in RFC5280.  However this instead of
presenting both the outer header (original) and the inner header
(message/rfc822) part to the recipient, this proposes that when the CMS
processing is done, the inner headers in message/rfc822 update the outer
ones.
If there is a conflict between the inner and outer, then the inner header
replaces the outer ones.  Body content in message/rfc822 part replaces that
of
the parent as well.  Further there should a signed attribute that tells the
recipient to protect header integrity and privacy upon reply or forwarding
of
the message.  There also should be a capability specified as well.  Before
sending the message implementations would move these headers to the
message/rfc822 part, leaving those header fields unspecified in the sent
outer message header.

Compliant implementations should protect at least these message headers:
  Subject
  Date
  References
  Message-ID
  Keywords
  Original-XXX
This list is not meant to be exhaustive.  A complete list generated
from (http://www.iana.org/assignments/message-headers/message-headers.xhtml)
can
be done at a later time.  This list also makes no attempt to hide transport
artifacts like the trace headers as these are outside of the control of the
sender and recipient, or the sender and recipient headers as these are
needed by
transport.  (Other much more heavy weight approaches are better suited to
handle
hiding those headers)

thanks,
-Wei