Considerations for protecting Email header with S/MIME
Isode Ltd14 Castle MewsHamptonMiddlesexTW12 2NPUKAlexey.Melnikov@isode.comEmailS/MIME
This document describes best practices for handling of Email header protected by S/MIME.
It also adds a new Content-Type parameter to help distinguish an S/MIME protected forwarded message
from an S/MIME construct protecting message header.
S/MIME is typically used to protect (sign and/or encrypt) Email message body parts,
but not header of corresponding Email messages. Header fields may contain confidential information
or information whose validity need protecting from disclosure or modification.
describes how to protect the Email message header ,
by wrapping the message inside a message/rfc822 container :
In order to protect outer, non-content-related message header fields
(for instance, the "Subject", "To", "From", and "Cc" fields), the
sending client MAY wrap a full MIME message in a message/rfc822
wrapper in order to apply S/MIME security services to these header
fields. It is up to the receiving client to decide how to present
this "inner" header along with the unprotected "outer" header.
When an S/MIME message is received, if the top-level protected MIME
entity has a Content-Type of message/rfc822, it can be assumed that
the intent was to provide header protection. This entity SHOULD be
presented as the top-level message, taking into account header
merging issues as previously discussed.
While the above advice helps in protecting message header fields, it doesn't provide
enough guidance on what information should and should not be included in outer (unprotected) header and
how information from outer and inner headers should be presented to users.
This document describes best UI and other practices for handling of messages wrapped
inside message/rfc822 body parts.
The goal of this document is to improve interoperability and minimize damage caused by
possible differences between inner and outer headers.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in
.
When generating S/MIME messages which protect header fields by wrapping a message inside message/rfc822 wrapper:
If a header field is being encrypted because it is sensitive, its true value
MUST NOT be included in the outer header. If the header field is mandatory
according to RFC 5322, a stub value (or a value indicating that the outer value is not to be used)
is to be included.
The outer header SHOULD be minimal in order to avoid disclosure of confidential information.
It is recommended that the outer header only contains "Date" (set to the same value as in the inner header, or,
if the Date value is also sensitive, to Monday 9am of the same week),
possibly "Subject" and "To"/"Bcc" header fields. In particular, Keywords, In-Reply-To and References header fields
SHOULD NOT be included in the outer header; "To" and "Cc" header fields should be omitted and replaced with
"Bcc: undisclosed-recipients;".
But note that having key header fields duplicated in the outer header is convenient
for many message stores (e.g. IMAP) and clients that can't decode S/MIME encrypted messages.
In particular, Subject/To/Cc/Bcc/Date header field values are returned in IMAP ENVELOPE FETCH data item
, which is frequently used by IMAP clients in order to avoid parsing
message header.
The "Subject" header field value of the outer header SHOULD either be identical to
the inner "Subject" header field value, or contain a clear indication that the outer value
is not to be used for display (the inner header field value would contain the true value).
Note that recommendations listed above only apply to non MIME header fields (header fields with names not starting with "Content-" prefix).Note that the above recommendations can also negatively affect antispam processing.
When displaying S/MIME messages which protect header fields by wrapping a message inside message/rfc822 wrapper:
The outer headers might be tampered with, so a receiving client SHOULD
ignore them, unless they are protected in some other way(*).
If a header field is present in the inner header, only the inner header field value
MUST be displayed (and the corresponding outer value must be ignored).
If a particular header field is only present in the outer header, it MAY be ignored (not displayed)
or it MAY be displayed with a clear indicator that it is not trustworthy(*).
(*) - this only applies if the header field is not protected is some other way,
for example with a DKIM signature that validates and is trusted.
This document defines a new Content-Type header field parameter with name "forwarded".
The parameter value is case-insensitive and can be either "yes" or "no". (The default value being "yes").
The parameter is only meaningful with media type "message/rfc822" and "message/global"
when used within S/MIME encrypted body parts.
The value "yes" means that the message nested inside message/rfc822 is a forwarded message and not a construct
created solely to protect the inner header.
Instructions in describing how to protect the Email message header ,
by wrapping the message inside a message/rfc822 container are thus updated to read:
In order to protect outer, non-content-related message header fields
(for instance, the "Subject", "To", "From", and "Cc" fields), the
sending client MAY wrap a full MIME message in a message/rfc822
wrapper in order to apply S/MIME security services to these header
fields. It is up to the receiving client to decide how to present
this "inner" header along with the unprotected "outer" header.
When an S/MIME message is received, if the top-level protected MIME
entity has a Content-Type of message/rfc822 or message/global without the "forwarded" parameter
or with the "forwarded" parameter set to "no", it can be assumed that
the intent was to provide header protection. This entity SHOULD be
presented as the top-level message, taking into account header
merging issues as previously discussed.
The following example demonstrates a message generated to protect original message header.
For example, this will be the first body part of a multipart/signed message or the payload
of the application/pkcs7-mime body part.
Extend the example to show different inner and outer header fields and clarify what should be displayed?
This document requests no action from IANA. RFC Editor should delete this section before publication.
This document talks about UI considerations, including security considerations, when processing
wrapped message/rfc822 messages protecting header fields. One of the goals of this document
is to specify UI for displaying such messages which is less confusing/misleading and thus more secure.
The document is not defining new protocol, so it doesn't
create any new security concerns not already covered by S/MIME ,
MIME and Email in general.
Thank you to Wei Chuang, Steve Kille, David Wilson and Robert Williams for suggestions, comments and corrections on this document.
Some ideas were also taken from Daniel Kahn Gillmor's email on the OpenPGP mailing list.David Wilson came up with the idea of defining a new Content-Type header field parameter to distinguish
forwarded messages from inner header field protection constructs.