Network Working Group | A. Melnikov |
Internet-Draft | Isode Ltd |
Intended status: Informational | August 24, 2016 |
Expires: February 25, 2017 |
Considerations for protecting Email header with S/MIME
draft-melnikov-smime-header-signing-03
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.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 25, 2017.
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
S/MIME [RFC5751] 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. [RFC5751] describes how to protect the Email message header [RFC5322], by wrapping the message inside a message/rfc822 container [RFC2045]:
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 [RFC2119].
When generating S/MIME messages which protect header fields by wrapping a message inside message/rfc822 wrapper:
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 affect antispam processing.
When displaying S/MIME messages which protect header fields by wrapping a message inside message/rfc822 wrapper:
This document defines a new Content-Type header field parameter [RFC2045] 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" [RFC6532] 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 [RFC5751] describing how to protect the Email message header [RFC5322], by wrapping the message inside a message/rfc822 container [RFC2045] are thus updated to read:
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 [RFC5751], MIME [RFC2045] and Email [RFC5322] in general.
[RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
[RFC2045] | Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996. |
[RFC5322] | Resnick, P., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008. |
[RFC5751] | Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, DOI 10.17487/RFC5751, January 2010. |
[RFC6532] | Yang, A., Steele, S. and N. Freed, "Internationalized Email Headers", RFC 6532, DOI 10.17487/RFC6532, February 2012. |
[RFC3501] | Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003. |
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.