[gmime] Updated README for various RFCs and notes about GMime-Sharp
- From: Jeffrey Stedfast <fejj src gnome org>
- To: commits-list gnome org
- Cc:
- Subject: [gmime] Updated README for various RFCs and notes about GMime-Sharp
- Date: Wed, 19 Feb 2014 16:27:48 +0000 (UTC)
commit 503e6782c218e7ec92a43bf59d7131dc6e3b6c92
Author: Jeffrey Stedfast <jeff xamarin com>
Date: Wed Feb 19 11:27:05 2014 -0500
Updated README for various RFCs and notes about GMime-Sharp
README | 26 +-
rfc/rfc1341.txt | 5265 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
rfc/rfc1342.txt | 395 +++++
rfc/rfc1522.txt | 563 ++++++
rfc/rfc1544.txt | 171 ++
rfc/rfc2110.txt | 1067 +++++++++++
rfc/rfc2112.txt | 507 ++++++
rfc/rfc3850.txt | 899 ++++++++++
rfc/rfc3851.txt | 2019 +++++++++++++++++++++
rfc/rfc5750.txt | 1179 +++++++++++++
rfc/rfc5751.txt | 2523 ++++++++++++++++++++++++++
11 files changed, 14612 insertions(+), 2 deletions(-)
---
diff --git a/README b/README
index e477bb8..18f02a2 100644
--- a/README
+++ b/README
@@ -10,9 +10,15 @@ the Multipurpose Internet Mail Extension (MIME) as defined by the
following RFCs:
* 0822: Standard for the Format of Arpa Internet Text Messages
+ * 1341: MIME (Multipurpose Internet Mail Extensions): Mechanisms for
+ Specifying and Describing the Format of Internet Message Bodies
+ * 1342: Representation of Non-ASCII Text in Internet Message Headers
* 1521: MIME (Multipurpose Internet Mail Extensions) Part One:
Mechanisms for Specifying and Describing the Format of
- Internet Message Bodies
+ Internet Message Bodies (Obsoletes rfc1341)
+ * 1522: MIME (Multipurpose Internet Mail Extensions) Part Two: Message
+ Header Extensions for Non-ASCII Text (Obsoletes rfc1342)
+ * 1544: The Content-MD5 Header Field
* 1847: Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted
* 1864: The Content-MD5 Header Field (Obsoletes rfc1544)
@@ -41,6 +47,7 @@ Other RFCs of interest:
* 1872: The MIME Multipart/Related Content-type
* 1927: Suggested Additional MIME Types for Associating Documents
+ * 2110: MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML)
* 2111: Content-ID and Message-ID Uniform Resource Locators
* 2311: S/MIME Version 2 Message Specification
* 2312: S/MIME Version 2 Certificate Handling
@@ -52,6 +59,14 @@ Other RFCs of interest:
* 2634: Enhanced Security Services for S/MIME
* 3280: Internet X.509 Public Key Infrastructure certificate and
Certificate Revocation List (CRL) Profile
+ * 3850: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1
+ Certificate Handling (Obsoletes rfc2632)
+ * 3851: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1
+ Message Specification (Obsoletes rfc2633)
+ * 5750: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2
+ Certificate Handling (Obsoletes rfc3850)
+ * 5751: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2
+ Message Specification (Obsoletes rfc3851)
Cryptography related RFCs:
@@ -178,7 +193,14 @@ are:
- Perl: http://search.cpan.org/dist/MIME-Fast/
-- .NET (Mono): Included in this distribution.
+- .NET (Mono): Included in this distribution (Obsolete).
+
+
+Note: It is recommended that MimeKit[1] be used in place of GMime-Sharp in
+.NET 4.0 (or later) environments.
+
+
+1. MimeKit: https://github.com/jstedfast/MimeKit
REPORTING BUGS
diff --git a/rfc/rfc1341.txt b/rfc/rfc1341.txt
new file mode 100644
index 0000000..1be6f7d
--- /dev/null
+++ b/rfc/rfc1341.txt
@@ -0,0 +1,5265 @@
+
+
+
+
+
+
+ Network Working Group N. Borenstein, Bellcore
+ Request for Comments: 1341 N. Freed, Innosoft
+ June 1992
+
+
+
+ MIME (Multipurpose Internet Mail Extensions):
+
+
+ Mechanisms for Specifying and Describing
+ the Format of Internet Message Bodies
+
+
+ Status of this Memo
+
+ This RFC specifies an IAB standards track protocol for the
+ Internet community, and requests discussion and suggestions
+ for improvements. Please refer to the current edition of
+ the "IAB Official Protocol Standards" for the
+ standardization state and status of this protocol.
+ Distribution of this memo is unlimited.
+
+ Abstract
+
+ RFC 822 defines a message representation protocol which
+ specifies considerable detail about message headers, but
+ which leaves the message content, or message body, as flat
+ ASCII text. This document redefines the format of message
+ bodies to allow multi-part textual and non-textual message
+ bodies to be represented and exchanged without loss of
+ information. This is based on earlier work documented in
+ RFC 934 and RFC 1049, but extends and revises that work.
+ Because RFC 822 said so little about message bodies, this
+ document is largely orthogonal to (rather than a revision
+ of) RFC 822.
+
+ In particular, this document is designed to provide
+ facilities to include multiple objects in a single message,
+ to represent body text in character sets other than US-
+ ASCII, to represent formatted multi-font text messages, to
+ represent non-textual material such as images and audio
+ fragments, and generally to facilitate later extensions
+ defining new types of Internet mail for use by cooperating
+ mail agents.
+
+ This document does NOT extend Internet mail header fields to
+ permit anything other than US-ASCII text data. It is
+ recognized that such extensions are necessary, and they are
+ the subject of a companion document [RFC -1342].
+
+ A table of contents appears at the end of this document.
+
+
+
+
+
+
+ Borenstein & Freed [Page i]
+
+
+
+
+
+
+
+ 1 Introduction
+
+ Since its publication in 1982, RFC 822 [RFC-822] has defined
+ the standard format of textual mail messages on the
+ Internet. Its success has been such that the RFC 822 format
+ has been adopted, wholly or partially, well beyond the
+ confines of the Internet and the Internet SMTP transport
+ defined by RFC 821 [RFC-821]. As the format has seen wider
+ use, a number of limitations have proven increasingly
+ restrictive for the user community.
+
+ RFC 822 was intended to specify a format for text messages.
+ As such, non-text messages, such as multimedia messages that
+ might include audio or images, are simply not mentioned.
+ Even in the case of text, however, RFC 822 is inadequate for
+ the needs of mail users whose languages require the use of
+ character sets richer than US ASCII [US-ASCII]. Since RFC
+ 822 does not specify mechanisms for mail containing audio,
+ video, Asian language text, or even text in most European
+ languages, additional specifications are needed
+
+ One of the notable limitations of RFC 821/822 based mail
+ systems is the fact that they limit the contents of
+ electronic mail messages to relatively short lines of
+ seven-bit ASCII. This forces users to convert any non-
+ textual data that they may wish to send into seven-bit bytes
+ representable as printable ASCII characters before invoking
+ a local mail UA (User Agent, a program with which human
+ users send and receive mail). Examples of such encodings
+ currently used in the Internet include pure hexadecimal,
+ uuencode, the 3-in-4 base 64 scheme specified in RFC 1113,
+ the Andrew Toolkit Representation [ATK], and many others.
+
+ The limitations of RFC 822 mail become even more apparent as
+ gateways are designed to allow for the exchange of mail
+ messages between RFC 822 hosts and X.400 hosts. X.400 [X400]
+ specifies mechanisms for the inclusion of non-textual body
+ parts within electronic mail messages. The current
+ standards for the mapping of X.400 messages to RFC 822
+ messages specify that either X.400 non-textual body parts
+ should be converted to (not encoded in) an ASCII format, or
+ that they should be discarded, notifying the RFC 822 user
+ that discarding has occurred. This is clearly undesirable,
+ as information that a user may wish to receive is lost.
+ Even though a user's UA may not have the capability of
+ dealing with the non-textual body part, the user might have
+ some mechanism external to the UA that can extract useful
+ information from the body part. Moreover, it does not allow
+ for the fact that the message may eventually be gatewayed
+ back into an X.400 message handling system (i.e., the X.400
+ message is "tunneled" through Internet mail), where the
+ non-textual information would definitely become useful
+ again.
+
+
+
+
+ Borenstein & Freed [Page 1]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ This document describes several mechanisms that combine to
+ solve most of these problems without introducing any serious
+ incompatibilities with the existing world of RFC 822 mail.
+ In particular, it describes:
+
+ 1. A MIME-Version header field, which uses a version number
+ to declare a message to be conformant with this
+ specification and allows mail processing agents to
+ distinguish between such messages and those generated
+ by older or non-conformant software, which is presumed
+ to lack such a field.
+
+ 2. A Content-Type header field, generalized from RFC 1049
+ [RFC-1049], which can be used to specify the type and
+ subtype of data in the body of a message and to fully
+ specify the native representation (encoding) of such
+ data.
+
+ 2.a. A "text" Content-Type value, which can be used to
+ represent textual information in a number of
+ character sets and formatted text description
+ languages in a standardized manner.
+
+ 2.b. A "multipart" Content-Type value, which can be
+ used to combine several body parts, possibly of
+ differing types of data, into a single message.
+
+ 2.c. An "application" Content-Type value, which can be
+ used to transmit application data or binary data,
+ and hence, among other uses, to implement an
+ electronic mail file transfer service.
+
+ 2.d. A "message" Content-Type value, for encapsulating
+ a mail message.
+
+ 2.e An "image" Content-Type value, for transmitting
+ still image (picture) data.
+
+ 2.f. An "audio" Content-Type value, for transmitting
+ audio or voice data.
+
+ 2.g. A "video" Content-Type value, for transmitting
+ video or moving image data, possibly with audio as
+ part of the composite video data format.
+
+ 3. A Content-Transfer-Encoding header field, which can be
+ used to specify an auxiliary encoding that was applied
+ to the data in order to allow it to pass through mail
+ transport mechanisms which may have data or character
+ set limitations.
+
+ 4. Two optional header fields that can be used to further
+ describe the data in a message body, the Content-ID and
+ Content-Description header fields.
+
+
+
+ Borenstein & Freed [Page 2]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ MIME has been carefully designed as an extensible mechanism,
+ and it is expected that the set of content-type/subtype
+ pairs and their associated parameters will grow
+ significantly with time. Several other MIME fields, notably
+ including character set names, are likely to have new values
+ defined over time. In order to ensure that the set of such
+ values is developed in an orderly, well-specified, and
+ public manner, MIME defines a registration process which
+ uses the Internet Assigned Numbers Authority (IANA) as a
+ central registry for such values. Appendix F provides
+ details about how IANA registration is accomplished.
+
+ Finally, to specify and promote interoperability, Appendix A
+ of this document provides a basic applicability statement
+ for a subset of the above mechanisms that defines a minimal
+ level of "conformance" with this document.
+
+ HISTORICAL NOTE: Several of the mechanisms described in
+ this document may seem somewhat strange or even baroque at
+ first reading. It is important to note that compatibility
+ with existing standards AND robustness across existing
+ practice were two of the highest priorities of the working
+ group that developed this document. In particular,
+ compatibility was always favored over elegance.
+
+ 2 Notations, Conventions, and Generic BNF Grammar
+
+ This document is being published in two versions, one as
+ plain ASCII text and one as PostScript. The latter is
+ recommended, though the textual contents are identical. An
+ Andrew-format copy of this document is also available from
+ the first author (Borenstein).
+
+ Although the mechanisms specified in this document are all
+ described in prose, most are also described formally in the
+ modified BNF notation of RFC 822. Implementors will need to
+ be familiar with this notation in order to understand this
+ specification, and are referred to RFC 822 for a complete
+ explanation of the modified BNF notation.
+
+ Some of the modified BNF in this document makes reference to
+ syntactic entities that are defined in RFC 822 and not in
+ this document. A complete formal grammar, then, is obtained
+ by combining the collected grammar appendix of this document
+ with that of RFC 822.
+
+ The term CRLF, in this document, refers to the sequence of
+ the two ASCII characters CR (13) and LF (10) which, taken
+ together, in this order, denote a line break in RFC 822
+ mail.
+
+ The term "character set", wherever it is used in this
+ document, refers to a coded character set, in the sense of
+ ISO character set standardization work, and must not be
+
+
+
+ Borenstein & Freed [Page 3]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ misinterpreted as meaning "a set of characters."
+
+ The term "message", when not further qualified, means either
+ the (complete or "top-level") message being transferred on a
+ network, or a message encapsulated in a body of type
+ "message".
+
+ The term "body part", in this document, means one of the
+ parts of the body of a multipart entity. A body part has a
+ header and a body, so it makes sense to speak about the body
+ of a body part.
+
+ The term "entity", in this document, means either a message
+ or a body part. All kinds of entities share the property
+ that they have a header and a body.
+
+ The term "body", when not further qualified, means the body
+ of an entity, that is the body of either a message or of a
+ body part.
+
+ Note : the previous four definitions are clearly circular.
+ This is unavoidable, since the overal structure of a MIME
+ message is indeed recursive.
+
+ In this document, all numeric and octet values are given in
+ decimal notation.
+
+ It must be noted that Content-Type values, subtypes, and
+ parameter names as defined in this document are case-
+ insensitive. However, parameter values are case-sensitive
+ unless otherwise specified for the specific parameter.
+
+ FORMATTING NOTE: This document has been carefully formatted
+ for ease of reading. The PostScript version of this
+ document, in particular, places notes like this one, which
+ may be skipped by the reader, in a smaller, italicized,
+ font, and indents it as well. In the text version, only the
+ indentation is preserved, so if you are reading the text
+ version of this you might consider using the PostScript
+ version instead. However, all such notes will be indented
+ and preceded by "NOTE:" or some similar introduction, even
+ in the text version.
+
+ The primary purpose of these non-essential notes is to
+ convey information about the rationale of this document, or
+ to place this document in the proper historical or
+ evolutionary context. Such information may be skipped by
+ those who are focused entirely on building a compliant
+ implementation, but may be of use to those who wish to
+ understand why this document is written as it is.
+
+ For ease of recognition, all BNF definitions have been
+ placed in a fixed-width font in the PostScript version of
+ this document.
+
+
+
+ Borenstein & Freed [Page 4]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ 3 The MIME-Version Header Field
+
+ Since RFC 822 was published in 1982, there has really been
+ only one format standard for Internet messages, and there
+ has been little perceived need to declare the format
+ standard in use. This document is an independent document
+ that complements RFC 822. Although the extensions in this
+ document have been defined in such a way as to be compatible
+ with RFC 822, there are still circumstances in which it
+ might be desirable for a mail-processing agent to know
+ whether a message was composed with the new standard in
+ mind.
+
+ Therefore, this document defines a new header field, "MIME-
+ Version", which is to be used to declare the version of the
+ Internet message body format standard in use.
+
+ Messages composed in accordance with this document MUST
+ include such a header field, with the following verbatim
+ text:
+
+ MIME-Version: 1.0
+
+ The presence of this header field is an assertion that the
+ message has been composed in compliance with this document.
+
+ Since it is possible that a future document might extend the
+ message format standard again, a formal BNF is given for the
+ content of the MIME-Version field:
+
+ MIME-Version := text
+
+ Thus, future format specifiers, which might replace or
+ extend "1.0", are (minimally) constrained by the definition
+ of "text", which appears in RFC 822.
+
+ Note that the MIME-Version header field is required at the
+ top level of a message. It is not required for each body
+ part of a multipart entity. It is required for the embedded
+ headers of a body of type "message" if and only if the
+ embedded message is itself claimed to be MIME-compliant.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 5]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ 4 The Content-Type Header Field
+
+ The purpose of the Content-Type field is to describe the
+ data contained in the body fully enough that the receiving
+ user agent can pick an appropriate agent or mechanism to
+ present the data to the user, or otherwise deal with the
+ data in an appropriate manner.
+
+ HISTORICAL NOTE: The Content-Type header field was first
+ defined in RFC 1049. RFC 1049 Content-types used a simpler
+ and less powerful syntax, but one that is largely compatible
+ with the mechanism given here.
+
+ The Content-Type header field is used to specify the nature
+ of the data in the body of an entity, by giving type and
+ subtype identifiers, and by providing auxiliary information
+ that may be required for certain types. After the type and
+ subtype names, the remainder of the header field is simply a
+ set of parameters, specified in an attribute/value notation.
+ The set of meaningful parameters differs for the different
+ types. The ordering of parameters is not significant.
+ Among the defined parameters is a "charset" parameter by
+ which the character set used in the body may be declared.
+ Comments are allowed in accordance with RFC 822 rules for
+ structured header fields.
+
+ In general, the top-level Content-Type is used to declare
+ the general type of data, while the subtype specifies a
+ specific format for that type of data. Thus, a Content-Type
+ of "image/xyz" is enough to tell a user agent that the data
+ is an image, even if the user agent has no knowledge of the
+ specific image format "xyz". Such information can be used,
+ for example, to decide whether or not to show a user the raw
+ data from an unrecognized subtype -- such an action might be
+ reasonable for unrecognized subtypes of text, but not for
+ unrecognized subtypes of image or audio. For this reason,
+ registered subtypes of audio, image, text, and video, should
+ not contain embedded information that is really of a
+ different type. Such compound types should be represented
+ using the "multipart" or "application" types.
+
+ Parameters are modifiers of the content-subtype, and do not
+ fundamentally affect the requirements of the host system.
+ Although most parameters make sense only with certain
+ content-types, others are "global" in the sense that they
+ might apply to any subtype. For example, the "boundary"
+ parameter makes sense only for the "multipart" content-type,
+ but the "charset" parameter might make sense with several
+ content-types.
+
+ An initial set of seven Content-Types is defined by this
+ document. This set of top-level names is intended to be
+ substantially complete. It is expected that additions to
+ the larger set of supported types can generally be
+
+
+
+ Borenstein & Freed [Page 6]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ accomplished by the creation of new subtypes of these
+ initial types. In the future, more top-level types may be
+ defined only by an extension to this standard. If another
+ primary type is to be used for any reason, it must be given
+ a name starting with "X-" to indicate its non-standard
+ status and to avoid a potential conflict with a future
+ official name.
+
+ In the Extended BNF notation of RFC 822, a Content-Type
+ header field value is defined as follows:
+
+ Content-Type := type "/" subtype *[";" parameter]
+
+ type := "application" / "audio"
+ / "image" / "message"
+ / "multipart" / "text"
+ / "video" / x-token
+
+ x-token := <The two characters "X-" followed, with no
+ intervening white space, by any token>
+
+ subtype := token
+
+ parameter := attribute "=" value
+
+ attribute := token
+
+ value := token / quoted-string
+
+ token := 1*<any CHAR except SPACE, CTLs, or tspecials>
+
+ tspecials := "(" / ")" / "<" / ">" / "@" ; Must be in
+ / "," / ";" / ":" / "\" / <"> ; quoted-string,
+ / "/" / "[" / "]" / "?" / "." ; to use within
+ / "=" ; parameter values
+
+ Note that the definition of "tspecials" is the same as the
+ RFC 822 definition of "specials" with the addition of the
+ three characters "/", "?", and "=".
+
+ Note also that a subtype specification is MANDATORY. There
+ are no default subtypes.
+
+ The type, subtype, and parameter names are not case
+ sensitive. For example, TEXT, Text, and TeXt are all
+ equivalent. Parameter values are normally case sensitive,
+ but certain parameters are interpreted to be case-
+ insensitive, depending on the intended use. (For example,
+ multipart boundaries are case-sensitive, but the "access-
+ type" for message/External-body is not case-sensitive.)
+
+ Beyond this syntax, the only constraint on the definition of
+ subtype names is the desire that their uses must not
+ conflict. That is, it would be undesirable to have two
+
+
+
+ Borenstein & Freed [Page 7]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ different communities using "Content-Type:
+ application/foobar" to mean two different things. The
+ process of defining new content-subtypes, then, is not
+ intended to be a mechanism for imposing restrictions, but
+ simply a mechanism for publicizing the usages. There are,
+ therefore, two acceptable mechanisms for defining new
+ Content-Type subtypes:
+
+ 1. Private values (starting with "X-") may be
+ defined bilaterally between two cooperating
+ agents without outside registration or
+ standardization.
+
+ 2. New standard values must be documented,
+ registered with, and approved by IANA, as
+ described in Appendix F. Where intended for
+ public use, the formats they refer to must
+ also be defined by a published specification,
+ and possibly offered for standardization.
+
+ The seven standard initial predefined Content-Types are
+ detailed in the bulk of this document. They are:
+
+ text -- textual information. The primary subtype,
+ "plain", indicates plain (unformatted) text. No
+ special software is required to get the full
+ meaning of the text, aside from support for the
+ indicated character set. Subtypes are to be used
+ for enriched text in forms where application
+ software may enhance the appearance of the text,
+ but such software must not be required in order to
+ get the general idea of the content. Possible
+ subtypes thus include any readable word processor
+ format. A very simple and portable subtype,
+ richtext, is defined in this document.
+ multipart -- data consisting of multiple parts of
+ independent data types. Four initial subtypes
+ are defined, including the primary "mixed"
+ subtype, "alternative" for representing the same
+ data in multiple formats, "parallel" for parts
+ intended to be viewed simultaneously, and "digest"
+ for multipart entities in which each part is of
+ type "message".
+ message -- an encapsulated message. A body of
+ Content-Type "message" is itself a fully formatted
+ RFC 822 conformant message which may contain its
+ own different Content-Type header field. The
+ primary subtype is "rfc822". The "partial"
+ subtype is defined for partial messages, to permit
+ the fragmented transmission of bodies that are
+ thought to be too large to be passed through mail
+ transport facilities. Another subtype,
+ "External-body", is defined for specifying large
+ bodies by reference to an external data source.
+
+
+
+ Borenstein & Freed [Page 8]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ image -- image data. Image requires a display device
+ (such as a graphical display, a printer, or a FAX
+ machine) to view the information. Initial
+ subtypes are defined for two widely-used image
+ formats, jpeg and gif.
+ audio -- audio data, with initial subtype "basic".
+ Audio requires an audio output device (such as a
+ speaker or a telephone) to "display" the contents.
+ video -- video data. Video requires the capability to
+ display moving images, typically including
+ specialized hardware and software. The initial
+ subtype is "mpeg".
+ application -- some other kind of data, typically
+ either uninterpreted binary data or information to
+ be processed by a mail-based application. The
+ primary subtype, "octet-stream", is to be used in
+ the case of uninterpreted binary data, in which
+ case the simplest recommended action is to offer
+ to write the information into a file for the user.
+ Two additional subtypes, "ODA" and "PostScript",
+ are defined for transporting ODA and PostScript
+ documents in bodies. Other expected uses for
+ "application" include spreadsheets, data for
+ mail-based scheduling systems, and languages for
+ "active" (computational) email. (Note that active
+ email entails several securityconsiderations,
+ which are discussed later in this memo,
+ particularly in the context of
+ application/PostScript.)
+
+ Default RFC 822 messages are typed by this protocol as plain
+ text in the US-ASCII character set, which can be explicitly
+ specified as "Content-type: text/plain; charset=us-ascii".
+ If no Content-Type is specified, either by error or by an
+ older user agent, this default is assumed. In the presence
+ of a MIME-Version header field, a receiving User Agent can
+ also assume that plain US-ASCII text was the sender's
+ intent. In the absence of a MIME-Version specification,
+ plain US-ASCII text must still be assumed, but the sender's
+ intent might have been otherwise.
+
+ RATIONALE: In the absence of any Content-Type header field
+ or MIME-Version header field, it is impossible to be certain
+ that a message is actually text in the US-ASCII character
+ set, since it might well be a message that, using the
+ conventions that predate this document, includes text in
+ another character set or non-textual data in a manner that
+ cannot be automatically recognized (e.g., a uuencoded
+ compressed UNIX tar file). Although there is no fully
+ acceptable alternative to treating such untyped messages as
+ "text/plain; charset=us-ascii", implementors should remain
+ aware that if a message lacks both the MIME-Version and the
+ Content-Type header fields, it may in practice contain
+ almost anything.
+
+
+
+ Borenstein & Freed [Page 9]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ It should be noted that the list of Content-Type values
+ given here may be augmented in time, via the mechanisms
+ described above, and that the set of subtypes is expected to
+ grow substantially.
+
+ When a mail reader encounters mail with an unknown Content-
+ type value, it should generally treat it as equivalent to
+ "application/octet-stream", as described later in this
+ document.
+
+ 5 The Content-Transfer-Encoding Header Field
+
+ Many Content-Types which could usefully be transported via
+ email are represented, in their "natural" format, as 8-bit
+ character or binary data. Such data cannot be transmitted
+ over some transport protocols. For example, RFC 821
+ restricts mail messages to 7-bit US-ASCII data with 1000
+ character lines.
+
+ It is necessary, therefore, to define a standard mechanism
+ for re-encoding such data into a 7-bit short-line format.
+ This document specifies that such encodings will be
+ indicated by a new "Content-Transfer-Encoding" header field.
+ The Content-Transfer-Encoding field is used to indicate the
+ type of transformation that has been used in order to
+ represent the body in an acceptable manner for transport.
+
+ Unlike Content-Types, a proliferation of Content-Transfer-
+ Encoding values is undesirable and unnecessary. However,
+ establishing only a single Content-Transfer-Encoding
+ mechanism does not seem possible. There is a tradeoff
+ between the desire for a compact and efficient encoding of
+ largely-binary data and the desire for a readable encoding
+ of data that is mostly, but not entirely, 7-bit data. For
+ this reason, at least two encoding mechanisms are necessary:
+ a "readable" encoding and a "dense" encoding.
+
+ The Content-Transfer-Encoding field is designed to specify
+ an invertible mapping between the "native" representation of
+ a type of data and a representation that can be readily
+ exchanged using 7 bit mail transport protocols, such as
+ those defined by RFC 821 (SMTP). This field has not been
+ defined by any previous standard. The field's value is a
+ single token specifying the type of encoding, as enumerated
+ below. Formally:
+
+ Content-Transfer-Encoding := "BASE64" / "QUOTED-PRINTABLE" /
+ "8BIT" / "7BIT" /
+ "BINARY" / x-token
+
+ These values are not case sensitive. That is, Base64 and
+ BASE64 and bAsE64 are all equivalent. An encoding type of
+ 7BIT requires that the body is already in a seven-bit mail-
+ ready representation. This is the default value -- that is,
+
+
+
+ Borenstein & Freed [Page 10]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ "Content-Transfer-Encoding: 7BIT" is assumed if the
+ Content-Transfer-Encoding header field is not present.
+
+ The values "8bit", "7bit", and "binary" all imply that NO
+ encoding has been performed. However, they are potentially
+ useful as indications of the kind of data contained in the
+ object, and therefore of the kind of encoding that might
+ need to be performed for transmission in a given transport
+ system. "7bit" means that the data is all represented as
+ short lines of US-ASCII data. "8bit" means that the lines
+ are short, but there may be non-ASCII characters (octets
+ with the high-order bit set). "Binary" means that not only
+ may non-ASCII characters be present, but also that the lines
+ are not necessarily short enough for SMTP transport.
+
+ The difference between "8bit" (or any other conceivable
+ bit-width token) and the "binary" token is that "binary"
+ does not require adherence to any limits on line length or
+ to the SMTP CRLF semantics, while the bit-width tokens do
+ require such adherence. If the body contains data in any
+ bit-width other than 7-bit, the appropriate bit-width
+ Content-Transfer-Encoding token must be used (e.g., "8bit"
+ for unencoded 8 bit wide data). If the body contains binary
+ data, the "binary" Content-Transfer-Encoding token must be
+ used.
+
+ NOTE: The distinction between the Content-Transfer-Encoding
+ values of "binary," "8bit," etc. may seem unimportant, in
+ that all of them really mean "none" -- that is, there has
+ been no encoding of the data for transport. However, clear
+ labeling will be of enormous value to gateways between
+ future mail transport systems with differing capabilities in
+ transporting data that do not meet the restrictions of RFC
+ 821 transport.
+
+ As of the publication of this document, there are no
+ standardized Internet transports for which it is legitimate
+ to include unencoded 8-bit or binary data in mail bodies.
+ Thus there are no circumstances in which the "8bit" or
+ "binary" Content-Transfer-Encoding is actually legal on the
+ Internet. However, in the event that 8-bit or binary mail
+ transport becomes a reality in Internet mail, or when this
+ document is used in conjunction with any other 8-bit or
+ binary-capable transport mechanism, 8-bit or binary bodies
+ should be labeled as such using this mechanism.
+
+ NOTE: The five values defined for the Content-Transfer-
+ Encoding field imply nothing about the Content-Type other
+ than the algorithm by which it was encoded or the transport
+ system requirements if unencoded.
+
+ Implementors may, if necessary, define new Content-
+ Transfer-Encoding values, but must use an x-token, which is
+ a name prefixed by "X-" to indicate its non-standard status,
+
+
+
+ Borenstein & Freed [Page 11]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ e.g., "Content-Transfer-Encoding: x-my-new-encoding".
+ However, unlike Content-Types and subtypes, the creation of
+ new Content-Transfer-Encoding values is explicitly and
+ strongly discouraged, as it seems likely to hinder
+ interoperability with little potential benefit. Their use
+ is allowed only as the result of an agreement between
+ cooperating user agents.
+
+ If a Content-Transfer-Encoding header field appears as part
+ of a message header, it applies to the entire body of that
+ message. If a Content-Transfer-Encoding header field
+ appears as part of a body part's headers, it applies only to
+ the body of that body part. If an entity is of type
+ "multipart" or "message", the Content-Transfer-Encoding is
+ not permitted to have any value other than a bit width
+ (e.g., "7bit", "8bit", etc.) or "binary".
+
+ It should be noted that email is character-oriented, so that
+ the mechanisms described here are mechanisms for encoding
+ arbitrary byte streams, not bit streams. If a bit stream is
+ to be encoded via one of these mechanisms, it must first be
+ converted to an 8-bit byte stream using the network standard
+ bit order ("big-endian"), in which the earlier bits in a
+ stream become the higher-order bits in a byte. A bit stream
+ not ending at an 8-bit boundary must be padded with zeroes.
+ This document provides a mechanism for noting the addition
+ of such padding in the case of the application Content-Type,
+ which has a "padding" parameter.
+
+ The encoding mechanisms defined here explicitly encode all
+ data in ASCII. Thus, for example, suppose an entity has
+ header fields such as:
+
+ Content-Type: text/plain; charset=ISO-8859-1
+ Content-transfer-encoding: base64
+
+ This should be interpreted to mean that the body is a base64
+ ASCII encoding of data that was originally in ISO-8859-1,
+ and will be in that character set again after decoding.
+
+ The following sections will define the two standard encoding
+ mechanisms. The definition of new content-transfer-
+ encodings is explicitly discouraged and should only occur
+ when absolutely necessary. All content-transfer-encoding
+ namespace except that beginning with "X-" is explicitly
+ reserved to the IANA for future use. Private agreements
+ about content-transfer-encodings are also explicitly
+ discouraged.
+
+ Certain Content-Transfer-Encoding values may only be used on
+ certain Content-Types. In particular, it is expressly
+ forbidden to use any encodings other than "7bit", "8bit", or
+ "binary" with any Content-Type that recursively includes
+ other Content-Type fields, notably the "multipart" and
+
+
+
+ Borenstein & Freed [Page 12]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ "message" Content-Types. All encodings that are desired for
+ bodies of type multipart or message must be done at the
+ innermost level, by encoding the actual body that needs to
+ be encoded.
+
+ NOTE ON ENCODING RESTRICTIONS: Though the prohibition
+ against using content-transfer-encodings on data of type
+ multipart or message may seem overly restrictive, it is
+ necessary to prevent nested encodings, in which data are
+ passed through an encoding algorithm multiple times, and
+ must be decoded multiple times in order to be properly
+ viewed. Nested encodings add considerable complexity to
+ user agents: aside from the obvious efficiency problems
+ with such multiple encodings, they can obscure the basic
+ structure of a message. In particular, they can imply that
+ several decoding operations are necessary simply to find out
+ what types of objects a message contains. Banning nested
+ encodings may complicate the job of certain mail gateways,
+ but this seems less of a problem than the effect of nested
+ encodings on user agents.
+
+ NOTE ON THE RELATIONSHIP BETWEEN CONTENT-TYPE AND CONTENT-
+ TRANSFER-ENCODING: It may seem that the Content-Transfer-
+ Encoding could be inferred from the characteristics of the
+ Content-Type that is to be encoded, or, at the very least,
+ that certain Content-Transfer-Encodings could be mandated
+ for use with specific Content-Types. There are several
+ reasons why this is not the case. First, given the varying
+ types of transports used for mail, some encodings may be
+ appropriate for some Content-Type/transport combinations and
+ not for others. (For example, in an 8-bit transport, no
+ encoding would be required for text in certain character
+ sets, while such encodings are clearly required for 7-bit
+ SMTP.) Second, certain Content-Types may require different
+ types of transfer encoding under different circumstances.
+ For example, many PostScript bodies might consist entirely
+ of short lines of 7-bit data and hence require little or no
+ encoding. Other PostScript bodies (especially those using
+ Level 2 PostScript's binary encoding mechanism) may only be
+ reasonably represented using a binary transport encoding.
+ Finally, since Content-Type is intended to be an open-ended
+ specification mechanism, strict specification of an
+ association between Content-Types and encodings effectively
+ couples the specification of an application protocol with a
+ specific lower-level transport. This is not desirable since
+ the developers of a Content-Type should not have to be aware
+ of all the transports in use and what their limitations are.
+
+ NOTE ON TRANSLATING ENCODINGS: The quoted-printable and
+ base64 encodings are designed so that conversion between
+ them is possible. The only issue that arises in such a
+ conversion is the handling of line breaks. When converting
+ from quoted-printable to base64 a line break must be
+ converted into a CRLF sequence. Similarly, a CRLF sequence
+
+
+
+ Borenstein & Freed [Page 13]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ in base64 data should be converted to a quoted-printable
+ line break, but ONLY when converting text data.
+
+ NOTE ON CANONICAL ENCODING MODEL: There was some
+ confusion, in earlier drafts of this memo, regarding the
+ model for when email data was to be converted to canonical
+ form and encoded, and in particular how this process would
+ affect the treatment of CRLFs, given that the representation
+ of newlines varies greatly from system to system. For this
+ reason, a canonical model for encoding is presented as
+ Appendix H.
+
+ 5.1 Quoted-Printable Content-Transfer-Encoding
+
+ The Quoted-Printable encoding is intended to represent data
+ that largely consists of octets that correspond to printable
+ characters in the ASCII character set. It encodes the data
+ in such a way that the resulting octets are unlikely to be
+ modified by mail transport. If the data being encoded are
+ mostly ASCII text, the encoded form of the data remains
+ largely recognizable by humans. A body which is entirely
+ ASCII may also be encoded in Quoted-Printable to ensure the
+ integrity of the data should the message pass through a
+ character-translating, and/or line-wrapping gateway.
+
+ In this encoding, octets are to be represented as determined
+ by the following rules:
+
+ Rule #1: (General 8-bit representation) Any octet,
+ except those indicating a line break according to the
+ newline convention of the canonical form of the data
+ being encoded, may be represented by an "=" followed by
+ a two digit hexadecimal representation of the octet's
+ value. The digits of the hexadecimal alphabet, for this
+ purpose, are "0123456789ABCDEF". Uppercase letters must
+ be
+ used when sending hexadecimal data, though a robust
+ implementation may choose to recognize lowercase
+ letters on receipt. Thus, for example, the value 12
+ (ASCII form feed) can be represented by "=0C", and the
+ value 61 (ASCII EQUAL SIGN) can be represented by
+ "=3D". Except when the following rules allow an
+ alternative encoding, this rule is mandatory.
+
+ Rule #2: (Literal representation) Octets with decimal
+ values of 33 through 60 inclusive, and 62 through 126,
+ inclusive, MAY be represented as the ASCII characters
+ which correspond to those octets (EXCLAMATION POINT
+ through LESS THAN, and GREATER THAN through TILDE,
+ respectively).
+
+ Rule #3: (White Space): Octets with values of 9 and 32
+ MAY be represented as ASCII TAB (HT) and SPACE
+ characters, respectively, but MUST NOT be so
+
+
+
+ Borenstein & Freed [Page 14]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ represented at the end of an encoded line. Any TAB (HT)
+ or SPACE characters on an encoded line MUST thus be
+ followed on that line by a printable character. In
+ particular, an "=" at the end of an encoded line,
+ indicating a soft line break (see rule #5) may follow
+ one or more TAB (HT) or SPACE characters. It follows
+ that an octet with value 9 or 32 appearing at the end
+ of an encoded line must be represented according to
+ Rule #1. This rule is necessary because some MTAs
+ (Message Transport Agents, programs which transport
+ messages from one user to another, or perform a part of
+ such transfers) are known to pad lines of text with
+ SPACEs, and others are known to remove "white space"
+ characters from the end of a line. Therefore, when
+ decoding a Quoted-Printable body, any trailing white
+ space on a line must be deleted, as it will necessarily
+ have been added by intermediate transport agents.
+
+ Rule #4 (Line Breaks): A line break in a text body
+ part, independent of what its representation is
+ following the canonical representation of the data
+ being encoded, must be represented by a (RFC 822) line
+ break, which is a CRLF sequence, in the Quoted-
+ Printable encoding. If isolated CRs and LFs, or LF CR
+ and CR LF sequences are allowed to appear in binary
+ data according to the canonical form, they must be
+ represented using the "=0D", "=0A", "=0A=0D" and
+ "=0D=0A" notations respectively.
+
+ Note that many implementation may elect to encode the
+ local representation of various content types directly.
+ In particular, this may apply to plain text material on
+ systems that use newline conventions other than CRLF
+ delimiters. Such an implementation is permissible, but
+ the generation of line breaks must be generalized to
+ account for the case where alternate representations of
+ newline sequences are used.
+
+ Rule #5 (Soft Line Breaks): The Quoted-Printable
+ encoding REQUIRES that encoded lines be no more than 76
+ characters long. If longer lines are to be encoded with
+ the Quoted-Printable encoding, 'soft' line breaks must
+ be used. An equal sign as the last character on a
+ encoded line indicates such a non-significant ('soft')
+ line break in the encoded text. Thus if the "raw" form
+ of the line is a single unencoded line that says:
+
+ Now's the time for all folk to come to the aid of
+ their country.
+
+ This can be represented, in the Quoted-Printable
+ encoding, as
+
+
+
+
+
+ Borenstein & Freed [Page 15]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ Now's the time =
+ for all folk to come=
+ to the aid of their country.
+
+ This provides a mechanism with which long lines are
+ encoded in such a way as to be restored by the user
+ agent. The 76 character limit does not count the
+ trailing CRLF, but counts all other characters,
+ including any equal signs.
+
+ Since the hyphen character ("-") is represented as itself in
+ the Quoted-Printable encoding, care must be taken, when
+ encapsulating a quoted-printable encoded body in a multipart
+ entity, to ensure that the encapsulation boundary does not
+ appear anywhere in the encoded body. (A good strategy is to
+ choose a boundary that includes a character sequence such as
+ "=_" which can never appear in a quoted-printable body. See
+ the definition of multipart messages later in this
+ document.)
+
+ NOTE: The quoted-printable encoding represents something of
+ a compromise between readability and reliability in
+ transport. Bodies encoded with the quoted-printable
+ encoding will work reliably over most mail gateways, but may
+ not work perfectly over a few gateways, notably those
+ involving translation into EBCDIC. (In theory, an EBCDIC
+ gateway could decode a quoted-printable body and re-encode
+ it using base64, but such gateways do not yet exist.) A
+ higher level of confidence is offered by the base64
+ Content-Transfer-Encoding. A way to get reasonably reliable
+ transport through EBCDIC gateways is to also quote the ASCII
+ characters
+
+ !"#$ [\]^`{|}~
+
+ according to rule #1. See Appendix B for more information.
+
+ Because quoted-printable data is generally assumed to be
+ line-oriented, it is to be expected that the breaks between
+ the lines of quoted printable data may be altered in
+ transport, in the same manner that plain text mail has
+ always been altered in Internet mail when passing between
+ systems with differing newline conventions. If such
+ alterations are likely to constitute a corruption of the
+ data, it is probably more sensible to use the base64
+ encoding rather than the quoted-printable encoding.
+
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 16]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ 5.2 Base64 Content-Transfer-Encoding
+
+ The Base64 Content-Transfer-Encoding is designed to
+ represent arbitrary sequences of octets in a form that is
+ not humanly readable. The encoding and decoding algorithms
+ are simple, but the encoded data are consistently only about
+ 33 percent larger than the unencoded data. This encoding is
+ based on the one used in Privacy Enhanced Mail applications,
+ as defined in RFC 1113. The base64 encoding is adapted
+ from RFC 1113, with one change: base64 eliminates the "*"
+ mechanism for embedded clear text.
+
+ A 65-character subset of US-ASCII is used, enabling 6 bits
+ to be represented per printable character. (The extra 65th
+ character, "=", is used to signify a special processing
+ function.)
+
+ NOTE: This subset has the important property that it is
+ represented identically in all versions of ISO 646,
+ including US ASCII, and all characters in the subset are
+ also represented identically in all versions of EBCDIC.
+ Other popular encodings, such as the encoding used by the
+ UUENCODE utility and the base85 encoding specified as part
+ of Level 2 PostScript, do not share these properties, and
+ thus do not fulfill the portability requirements a binary
+ transport encoding for mail must meet.
+
+ The encoding process represents 24-bit groups of input bits
+ as output strings of 4 encoded characters. Proceeding from
+ left to right, a 24-bit input group is formed by
+ concatenating 3 8-bit input groups. These 24 bits are then
+ treated as 4 concatenated 6-bit groups, each of which is
+ translated into a single digit in the base64 alphabet. When
+ encoding a bit stream via the base64 encoding, the bit
+ stream must be presumed to be ordered with the most-
+ significant-bit first. That is, the first bit in the stream
+ will be the high-order bit in the first byte, and the eighth
+ bit will be the low-order bit in the first byte, and so on.
+
+ Each 6-bit group is used as an index into an array of 64
+ printable characters. The character referenced by the index
+ is placed in the output string. These characters, identified
+ in Table 1, below, are selected so as to be universally
+ representable, and the set excludes characters with
+ particular significance to SMTP (e.g., ".", "CR", "LF") and
+ to the encapsulation boundaries defined in this document
+ (e.g., "-").
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 17]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ Table 1: The Base64 Alphabet
+
+ Value Encoding Value Encoding Value Encoding Value
+ Encoding
+ 0 A 17 R 34 i 51 z
+ 1 B 18 S 35 j 52 0
+ 2 C 19 T 36 k 53 1
+ 3 D 20 U 37 l 54 2
+ 4 E 21 V 38 m 55 3
+ 5 F 22 W 39 n 56 4
+ 6 G 23 X 40 o 57 5
+ 7 H 24 Y 41 p 58 6
+ 8 I 25 Z 42 q 59 7
+ 9 J 26 a 43 r 60 8
+ 10 K 27 b 44 s 61 9
+ 11 L 28 c 45 t 62 +
+ 12 M 29 d 46 u 63 /
+ 13 N 30 e 47 v
+ 14 O 31 f 48 w (pad) =
+ 15 P 32 g 49 x
+ 16 Q 33 h 50 y
+
+ The output stream (encoded bytes) must be represented in
+ lines of no more than 76 characters each. All line breaks
+ or other characters not found in Table 1 must be ignored by
+ decoding software. In base64 data, characters other than
+ those in Table 1, line breaks, and other white space
+ probably indicate a transmission error, about which a
+ warning message or even a message rejection might be
+ appropriate under some circumstances.
+
+ Special processing is performed if fewer than 24 bits are
+ available at the end of the data being encoded. A full
+ encoding quantum is always completed at the end of a body.
+ When fewer than 24 input bits are available in an input
+ group, zero bits are added (on the right) to form an
+ integral number of 6-bit groups. Output character positions
+ which are not required to represent actual input data are
+ set to the character "=". Since all base64 input is an
+ integral number of octets, only the following cases can
+ arise: (1) the final quantum of encoding input is an
+ integral multiple of 24 bits; here, the final unit of
+ encoded output will be an integral multiple of 4 characters
+ with no "=" padding, (2) the final quantum of encoding input
+ is exactly 8 bits; here, the final unit of encoded output
+ will be two characters followed by two "=" padding
+ characters, or (3) the final quantum of encoding input is
+ exactly 16 bits; here, the final unit of encoded output will
+ be three characters followed by one "=" padding character.
+
+ Care must be taken to use the proper octets for line breaks
+ if base64 encoding is applied directly to text material that
+ has not been converted to canonical form. In particular,
+ text line breaks should be converted into CRLF sequences
+
+
+
+ Borenstein & Freed [Page 18]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ prior to base64 encoding. The important thing to note is
+ that this may be done directly by the encoder rather than in
+ a prior canonicalization step in some implementations.
+
+ NOTE: There is no need to worry about quoting apparent
+ encapsulation boundaries within base64-encoded parts of
+ multipart entities because no hyphen characters are used in
+ the base64 encoding.
+
+ 6 Additional Optional Content- Header Fields
+
+ 6.1 Optional Content-ID Header Field
+
+ In constructing a high-level user agent, it may be desirable
+ to allow one body to make reference to another.
+ Accordingly, bodies may be labeled using the "Content-ID"
+ header field, which is syntactically identical to the
+ "Message-ID" header field:
+
+ Content-ID := msg-id
+
+ Like the Message-ID values, Content-ID values must be
+ generated to be as unique as possible.
+
+ 6.2 Optional Content-Description Header Field
+
+ The ability to associate some descriptive information with a
+ given body is often desirable. For example, it may be useful
+ to mark an "image" body as "a picture of the Space Shuttle
+ Endeavor." Such text may be placed in the Content-
+ Description header field.
+
+ Content-Description := *text
+
+ The description is presumed to be given in the US-ASCII
+ character set, although the mechanism specified in [RFC-
+ 1342] may be used for non-US-ASCII Content-Description
+ values.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 19]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ 7 The Predefined Content-Type Values
+
+ This document defines seven initial Content-Type values and
+ an extension mechanism for private or experimental types.
+ Further standard types must be defined by new published
+ specifications. It is expected that most innovation in new
+ types of mail will take place as subtypes of the seven types
+ defined here. The most essential characteristics of the
+ seven content-types are summarized in Appendix G.
+
+ 7.1 The Text Content-Type
+
+ The text Content-Type is intended for sending material which
+ is principally textual in form. It is the default Content-
+ Type. A "charset" parameter may be used to indicate the
+ character set of the body text. The primary subtype of text
+ is "plain". This indicates plain (unformatted) text. The
+ default Content-Type for Internet mail is "text/plain;
+ charset=us-ascii".
+
+ Beyond plain text, there are many formats for representing
+ what might be known as "extended text" -- text with embedded
+ formatting and presentation information. An interesting
+ characteristic of many such representations is that they are
+ to some extent readable even without the software that
+ interprets them. It is useful, then, to distinguish them,
+ at the highest level, from such unreadable data as images,
+ audio, or text represented in an unreadable form. In the
+ absence of appropriate interpretation software, it is
+ reasonable to show subtypes of text to the user, while it is
+ not reasonable to do so with most nontextual data.
+
+ Such formatted textual data should be represented using
+ subtypes of text. Plausible subtypes of text are typically
+ given by the common name of the representation format, e.g.,
+ "text/richtext".
+
+ 7.1.1 The charset parameter
+
+ A critical parameter that may be specified in the Content-
+ Type field for text data is the character set. This is
+ specified with a "charset" parameter, as in:
+
+ Content-type: text/plain; charset=us-ascii
+
+ Unlike some other parameter values, the values of the
+ charset parameter are NOT case sensitive. The default
+ character set, which must be assumed in the absence of a
+ charset parameter, is US-ASCII.
+
+ An initial list of predefined character set names can be
+ found at the end of this section. Additional character sets
+ may be registered with IANA as described in Appendix F,
+ although the standardization of their use requires the usual
+
+
+
+ Borenstein & Freed [Page 20]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ IAB review and approval. Note that if the specified
+ character set includes 8-bit data, a Content-Transfer-
+ Encoding header field and a corresponding encoding on the
+ data are required in order to transmit the body via some
+ mail transfer protocols, such as SMTP.
+
+ The default character set, US-ASCII, has been the subject of
+ some confusion and ambiguity in the past. Not only were
+ there some ambiguities in the definition, there have been
+ wide variations in practice. In order to eliminate such
+ ambiguity and variations in the future, it is strongly
+ recommended that new user agents explicitly specify a
+ character set via the Content-Type header field. "US-ASCII"
+ does not indicate an arbitrary seven-bit character code, but
+ specifies that the body uses character coding that uses the
+ exact correspondence of codes to characters specified in
+ ASCII. National use variations of ISO 646 [ISO-646] are NOT
+ ASCII and their use in Internet mail is explicitly
+ discouraged. The omission of the ISO 646 character set is
+ deliberate in this regard. The character set name of "US-
+ ASCII" explicitly refers to ANSI X3.4-1986 [US-ASCII] only.
+ The character set name "ASCII" is reserved and must not be
+ used for any purpose.
+
+ NOTE: RFC 821 explicitly specifies "ASCII", and references
+ an earlier version of the American Standard. Insofar as one
+ of the purposes of specifying a Content-Type and character
+ set is to permit the receiver to unambiguously determine how
+ the sender intended the coded message to be interpreted,
+ assuming anything other than "strict ASCII" as the default
+ would risk unintentional and incompatible changes to the
+ semantics of messages now being transmitted. This also
+ implies that messages containing characters coded according
+ to national variations on ISO 646, or using code-switching
+ procedures (e.g., those of ISO 2022), as well as 8-bit or
+ multiple octet character encodings MUST use an appropriate
+ character set specification to be consistent with this
+ specification.
+
+ The complete US-ASCII character set is listed in [US-ASCII].
+ Note that the control characters including DEL (0-31, 127)
+ have no defined meaning apart from the combination CRLF
+ (ASCII values 13 and 10) indicating a new line. Two of the
+ characters have de facto meanings in wide use: FF (12) often
+ means "start subsequent text on the beginning of a new
+ page"; and TAB or HT (9) often (though not always) means
+ "move the cursor to the next available column after the
+ current position where the column number is a multiple of 8
+ (counting the first column as column 0)." Apart from this,
+ any use of the control characters or DEL in a body must be
+ part of a private agreement between the sender and
+ recipient. Such private agreements are discouraged and
+ should be replaced by the other capabilities of this
+ document.
+
+
+
+ Borenstein & Freed [Page 21]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ NOTE: Beyond US-ASCII, an enormous proliferation of
+ character sets is possible. It is the opinion of the IETF
+ working group that a large number of character sets is NOT a
+ good thing. We would prefer to specify a single character
+ set that can be used universally for representing all of the
+ world's languages in electronic mail. Unfortunately,
+ existing practice in several communities seems to point to
+ the continued use of multiple character sets in the near
+ future. For this reason, we define names for a small number
+ of character sets for which a strong constituent base
+ exists. It is our hope that ISO 10646 or some other
+ effort will eventually define a single world character set
+ which can then be specified for use in Internet mail, but in
+ the advance of that definition we cannot specify the use of
+ ISO 10646, Unicode, or any other character set whose
+ definition is, as of this writing, incomplete.
+
+ The defined charset values are:
+
+ US-ASCII -- as defined in [US-ASCII].
+
+ ISO-8859-X -- where "X" is to be replaced, as
+ necessary, for the parts of ISO-8859 [ISO-
+ 8859]. Note that the ISO 646 character sets
+ have deliberately been omitted in favor of
+ their 8859 replacements, which are the
+ designated character sets for Internet mail.
+ As of the publication of this document, the
+ legitimate values for "X" are the digits 1
+ through 9.
+
+ Note that the character set used, if anything other than
+ US-ASCII, must always be explicitly specified in the
+ Content-Type field.
+
+ No other character set name may be used in Internet mail
+ without the publication of a formal specification and its
+ registration with IANA as described in Appendix F, or by
+ private agreement, in which case the character set name must
+ begin with "X-".
+
+ Implementors are discouraged from defining new character
+ sets for mail use unless absolutely necessary.
+
+ The "charset" parameter has been defined primarily for the
+ purpose of textual data, and is described in this section
+ for that reason. However, it is conceivable that non-
+ textual data might also wish to specify a charset value for
+ some purpose, in which case the same syntax and values
+ should be used.
+
+ In general, mail-sending software should always use the
+ "lowest common denominator" character set possible. For
+ example, if a body contains only US-ASCII characters, it
+
+
+
+ Borenstein & Freed [Page 22]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ should be marked as being in the US-ASCII character set, not
+ ISO-8859-1, which, like all the ISO-8859 family of character
+ sets, is a superset of US-ASCII. More generally, if a
+ widely-used character set is a subset of another character
+ set, and a body contains only characters in the widely-used
+ subset, it should be labeled as being in that subset. This
+ will increase the chances that the recipient will be able to
+ view the mail correctly.
+
+ 7.1.2 The Text/plain subtype
+
+ The primary subtype of text is "plain". This indicates
+ plain (unformatted) text. The default Content-Type for
+ Internet mail, "text/plain; charset=us-ascii", describes
+ existing Internet practice, that is, it is the type of body
+ defined by RFC 822.
+
+ 7.1.3 The Text/richtext subtype
+
+ In order to promote the wider interoperability of simple
+ formatted text, this document defines an extremely simple
+ subtype of "text", the "richtext" subtype. This subtype was
+ designed to meet the following criteria:
+
+ 1. The syntax must be extremely simple to parse,
+ so that even teletype-oriented mail systems can
+ easily strip away the formatting information and
+ leave only the readable text.
+
+ 2. The syntax must be extensible to allow for new
+ formatting commands that are deemed essential.
+
+ 3. The capabilities must be extremely limited, to
+ ensure that it can represent no more than is
+ likely to be representable by the user's primary
+ word processor. While this limits what can be
+ sent, it increases the likelihood that what is
+ sent can be properly displayed.
+
+ 4. The syntax must be compatible with SGML, so
+ that, with an appropriate DTD (Document Type
+ Definition, the standard mechanism for defining a
+ document type using SGML), a general SGML parser
+ could be made to parse richtext. However, despite
+ this compatibility, the syntax should be far
+ simpler than full SGML, so that no SGML knowledge
+ is required in order to implement it.
+
+ The syntax of "richtext" is very simple. It is assumed, at
+ the top-level, to be in the US-ASCII character set, unless
+ of course a different charset parameter was specified in the
+ Content-type field. All characters represent themselves,
+ with the exception of the "<" character (ASCII 60), which is
+ used to mark the beginning of a formatting command.
+
+
+
+ Borenstein & Freed [Page 23]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ Formatting instructions consist of formatting commands
+ surrounded by angle brackets ("<>", ASCII 60 and 62). Each
+ formatting command may be no more than 40 characters in
+ length, all in US-ASCII, restricted to the alphanumeric and
+ hyphen ("-") characters. Formatting commands may be preceded
+ by a forward slash or solidus ("/", ASCII 47), making them
+ negations, and such negations must always exist to balance
+ the initial opening commands, except as noted below. Thus,
+ if the formatting command "<bold>" appears at some point,
+ there must later be a "</bold>" to balance it. There are
+ only three exceptions to this "balancing" rule: First, the
+ command "<lt>" is used to represent a literal "<" character.
+ Second, the command "<nl>" is used to represent a required
+ line break. (Otherwise, CRLFs in the data are treated as
+ equivalent to a single SPACE character.) Finally, the
+ command "<np>" is used to represent a page break. (NOTE:
+ The 40 character limit on formatting commands does not
+ include the "<", ">", or "/" characters that might be
+ attached to such commands.)
+
+ Initially defined formatting commands, not all of which will
+ be implemented by all richtext implementations, include:
+
+ Bold -- causes the subsequent text to be in a bold
+ font.
+ Italic -- causes the subsequent text to be in an italic
+ font.
+ Fixed -- causes the subsequent text to be in a fixed
+ width font.
+ Smaller -- causes the subsequent text to be in a
+ smaller font.
+ Bigger -- causes the subsequent text to be in a bigger
+ font.
+ Underline -- causes the subsequent text to be
+ underlined.
+ Center -- causes the subsequent text to be centered.
+ FlushLeft -- causes the subsequent text to be left
+ justified.
+ FlushRight -- causes the subsequent text to be right
+ justified.
+ Indent -- causes the subsequent text to be indented at
+ the left margin.
+ IndentRight -- causes the subsequent text to be
+ indented at the right margin.
+ Outdent -- causes the subsequent text to be outdented
+ at the left margin.
+ OutdentRight -- causes the subsequent text to be
+ outdented at the right margin.
+ SamePage -- causes the subsequent text to be grouped,
+ if possible, on one page.
+ Subscript -- causes the subsequent text to be
+ interpreted as a subscript.
+
+
+
+
+
+ Borenstein & Freed [Page 24]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ Superscript -- causes the subsequent text to be
+ interpreted as a superscript.
+ Heading -- causes the subsequent text to be interpreted
+ as a page heading.
+ Footing -- causes the subsequent text to be interpreted
+ as a page footing.
+ ISO-8859-X (for any value of X that is legal as a
+ "charset" parameter) -- causes the subsequent text
+ to be interpreted as text in the appropriate
+ character set.
+ US-ASCII -- causes the subsequent text to be
+ interpreted as text in the US-ASCII character set.
+ Excerpt -- causes the subsequent text to be interpreted
+ as a textual excerpt from another source.
+ Typically this will be displayed using indentation
+ and an alternate font, but such decisions are up
+ to the viewer.
+ Paragraph -- causes the subsequent text to be
+ interpreted as a single paragraph, with
+ appropriate paragraph breaks (typically blank
+ space) before and after.
+ Signature -- causes the subsequent text to be
+ interpreted as a "signature". Some systems may
+ wish to display signatures in a smaller font or
+ otherwise set them apart from the main text of the
+ message.
+ Comment -- causes the subsequent text to be interpreted
+ as a comment, and hence not shown to the reader.
+ No-op -- has no effect on the subsequent text.
+ lt -- <lt> is replaced by a literal "<" character. No
+ balancing </lt> is allowed.
+ nl -- <nl> causes a line break. No balancing </nl> is
+ allowed.
+ np -- <np> causes a page break. No balancing </np> is
+ allowed.
+
+ Each positive formatting command affects all subsequent text
+ until the matching negative formatting command. Such pairs
+ of formatting commands must be properly balanced and nested.
+ Thus, a proper way to describe text in bold italics is:
+
+ <bold><italic>the-text</italic></bold>
+
+ or, alternately,
+
+ <italic><bold>the-text</bold></italic>
+
+ but, in particular, the following is illegal
+ richtext:
+
+ <bold><italic>the-text</bold></italic>
+
+ NOTE: The nesting requirement for formatting commands
+ imposes a slightly higher burden upon the composers of
+
+
+
+ Borenstein & Freed [Page 25]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ richtext bodies, but potentially simplifies richtext
+ displayers by allowing them to be stack-based. The main
+ goal of richtext is to be simple enough to make multifont,
+ formatted email widely readable, so that those with the
+ capability of sending it will be able to do so with
+ confidence. Thus slightly increased complexity in the
+ composing software was deemed a reasonable tradeoff for
+ simplified reading software. Nonetheless, implementors of
+ richtext readers are encouraged to follow the general
+ Internet guidelines of being conservative in what you send
+ and liberal in what you accept. Those implementations that
+ can do so are encouraged to deal reasonably with improperly
+ nested richtext.
+
+ Implementations must regard any unrecognized formatting
+ command as equivalent to "No-op", thus facilitating future
+ extensions to "richtext". Private extensions may be defined
+ using formatting commands that begin with "X-", by analogy
+ to Internet mail header field names.
+
+ It is worth noting that no special behavior is required for
+ the TAB (HT) character. It is recommended, however, that, at
+ least when fixed-width fonts are in use, the common
+ semantics of the TAB (HT) character should be observed,
+ namely that it moves to the next column position that is a
+ multiple of 8. (In other words, if a TAB (HT) occurs in
+ column n, where the leftmost column is column 0, then that
+ TAB (HT) should be replaced by 8-(n mod 8) SPACE
+ characters.)
+
+ Richtext also differentiates between "hard" and "soft" line
+ breaks. A line break (CRLF) in the richtext data stream is
+ interpreted as a "soft" line break, one that is included
+ only for purposes of mail transport, and is to be treated as
+ white space by richtext interpreters. To include a "hard"
+ line break (one that must be displayed as such), the "<nl>"
+ or "<paragraph> formatting constructs should be used. In
+ general, a soft line break should be treated as white space,
+ but when soft line breaks immediately follow a <nl> or a
+ </paragraph> tag they should be ignored rather than treated
+ as white space.
+
+ Putting all this together, the following "text/richtext"
+ body fragment:
+
+ <bold>Now</bold> is the time for
+ <italic>all</italic> good men
+ <smaller>(and <lt>women>)</smaller> to
+ <ignoreme></ignoreme> come
+
+ to the aid of their
+ <nl>
+
+
+
+
+
+ Borenstein & Freed [Page 26]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ beloved <nl><nl>country. <comment> Stupid
+ quote! </comment> -- the end
+
+ represents the following formatted text (which will, no
+ doubt, look cryptic in the text-only version of this
+ document):
+
+ Now is the time for all good men (and <women>) to
+ come to the aid of their
+ beloved
+
+ country. -- the end
+
+ Richtext conformance: A minimal richtext implementation is
+ one that simply converts "<lt>" to "<", converts CRLFs to
+ SPACE, converts <nl> to a newline according to local newline
+ convention, removes everything between a <comment> command
+ and the next balancing </comment> command, and removes all
+ other formatting commands (all text enclosed in angle
+ brackets).
+
+ NOTE ON THE RELATIONSHIP OF RICHTEXT TO SGML: Richtext is
+ decidedly not SGML, and must not be used to transport
+ arbitrary SGML documents. Those who wish to use SGML
+ document types as a mail transport format must define a new
+ text or application subtype, e.g., "text/sgml-dtd-whatever"
+ or "application/sgml-dtd-whatever", depending on the
+ perceived readability of the DTD in use. Richtext is
+ designed to be compatible with SGML, and specifically so
+ that it will be possible to define a richtext DTD if one is
+ needed. However, this does not imply that arbitrary SGML
+ can be called richtext, nor that richtext implementors have
+ any need to understand SGML; the description in this
+ document is a complete definition of richtext, which is far
+ simpler than complete SGML.
+
+ NOTE ON THE INTENDED USE OF RICHTEXT: It is recognized that
+ implementors of future mail systems will want rich text
+ functionality far beyond that currently defined for
+ richtext. The intent of richtext is to provide a common
+ format for expressing that functionality in a form in which
+ much of it, at least, will be understood by interoperating
+ software. Thus, in particular, software with a richer
+ notion of formatted text than richtext can still use
+ richtext as its basic representation, but can extend it with
+ new formatting commands and by hiding information specific
+ to that software system in richtext comments. As such
+ systems evolve, it is expected that the definition of
+ richtext will be further refined by future published
+ specifications, but richtext as defined here provides a
+ platform on which evolutionary refinements can be based.
+
+ IMPLEMENTATION NOTE: In some environments, it might be
+ impossible to combine certain richtext formatting commands,
+
+
+
+ Borenstein & Freed [Page 27]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ whereas in others they might be combined easily. For
+ example, the combination of <bold> and <italic> might
+ produce bold italics on systems that support such fonts, but
+ there exist systems that can make text bold or italicized,
+ but not both. In such cases, the most recently issued
+ recognized formatting command should be preferred.
+
+ One of the major goals in the design of richtext was to make
+ it so simple that even text-only mailers will implement
+ richtext-to-plain-text translators, thus increasing the
+ likelihood that multifont text will become "safe" to use
+ very widely. To demonstrate this simplicity, an extremely
+ simple 35-line C program that converts richtext input into
+ plain text output is included in Appendix D.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 28]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ 7.2 The Multipart Content-Type
+
+ In the case of multiple part messages, in which one or more
+ different sets of data are combined in a single body, a
+ "multipart" Content-Type field must appear in the entity's
+ header. The body must then contain one or more "body parts,"
+ each preceded by an encapsulation boundary, and the last one
+ followed by a closing boundary. Each part starts with an
+ encapsulation boundary, and then contains a body part
+ consisting of header area, a blank line, and a body area.
+ Thus a body part is similar to an RFC 822 message in syntax,
+ but different in meaning.
+
+ A body part is NOT to be interpreted as actually being an
+ RFC 822 message. To begin with, NO header fields are
+ actually required in body parts. A body part that starts
+ with a blank line, therefore, is allowed and is a body part
+ for which all default values are to be assumed. In such a
+ case, the absence of a Content-Type header field implies
+ that the encapsulation is plain US-ASCII text. The only
+ header fields that have defined meaning for body parts are
+ those the names of which begin with "Content-". All other
+ header fields are generally to be ignored in body parts.
+ Although they should generally be retained in mail
+ processing, they may be discarded by gateways if necessary.
+ Such other fields are permitted to appear in body parts but
+ should not be depended on. "X-" fields may be created for
+ experimental or private purposes, with the recognition that
+ the information they contain may be lost at some gateways.
+
+ The distinction between an RFC 822 message and a body part
+ is subtle, but important. A gateway between Internet and
+ X.400 mail, for example, must be able to tell the difference
+ between a body part that contains an image and a body part
+ that contains an encapsulated message, the body of which is
+ an image. In order to represent the latter, the body part
+ must have "Content-Type: message", and its body (after the
+ blank line) must be the encapsulated message, with its own
+ "Content-Type: image" header field. The use of similar
+ syntax facilitates the conversion of messages to body parts,
+ and vice versa, but the distinction between the two must be
+ understood by implementors. (For the special case in which
+ all parts actually are messages, a "digest" subtype is also
+ defined.)
+
+ As stated previously, each body part is preceded by an
+ encapsulation boundary. The encapsulation boundary MUST NOT
+ appear inside any of the encapsulated parts. Thus, it is
+ crucial that the composing agent be able to choose and
+ specify the unique boundary that will separate the parts.
+
+ All present and future subtypes of the "multipart" type must
+ use an identical syntax. Subtypes may differ in their
+ semantics, and may impose additional restrictions on syntax,
+
+
+
+ Borenstein & Freed [Page 29]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ but must conform to the required syntax for the multipart
+ type. This requirement ensures that all conformant user
+ agents will at least be able to recognize and separate the
+ parts of any multipart entity, even of an unrecognized
+ subtype.
+
+ As stated in the definition of the Content-Transfer-Encoding
+ field, no encoding other than "7bit", "8bit", or "binary" is
+ permitted for entities of type "multipart". The multipart
+ delimiters and header fields are always 7-bit ASCII in any
+ case, and data within the body parts can be encoded on a
+ part-by-part basis, with Content-Transfer-Encoding fields
+ for each appropriate body part.
+
+ Mail gateways, relays, and other mail handling agents are
+ commonly known to alter the top-level header of an RFC 822
+ message. In particular, they frequently add, remove, or
+ reorder header fields. Such alterations are explicitly
+ forbidden for the body part headers embedded in the bodies
+ of messages of type "multipart."
+
+ 7.2.1 Multipart: The common syntax
+
+ All subtypes of "multipart" share a common syntax, defined
+ in this section. A simple example of a multipart message
+ also appears in this section. An example of a more complex
+ multipart message is given in Appendix C.
+
+ The Content-Type field for multipart entities requires one
+ parameter, "boundary", which is used to specify the
+ encapsulation boundary. The encapsulation boundary is
+ defined as a line consisting entirely of two hyphen
+ characters ("-", decimal code 45) followed by the boundary
+ parameter value from the Content-Type header field.
+
+ NOTE: The hyphens are for rough compatibility with the
+ earlier RFC 934 method of message encapsulation, and for
+ ease of searching for the boundaries in some
+ implementations. However, it should be noted that multipart
+ messages are NOT completely compatible with RFC 934
+ encapsulations; in particular, they do not obey RFC 934
+ quoting conventions for embedded lines that begin with
+ hyphens. This mechanism was chosen over the RFC 934
+ mechanism because the latter causes lines to grow with each
+ level of quoting. The combination of this growth with the
+ fact that SMTP implementations sometimes wrap long lines
+ made the RFC 934 mechanism unsuitable for use in the event
+ that deeply-nested multipart structuring is ever desired.
+
+ Thus, a typical multipart Content-Type header field might
+ look like this:
+
+ Content-Type: multipart/mixed;
+
+
+
+
+ Borenstein & Freed [Page 30]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ boundary=gc0p4Jq0M2Yt08jU534c0p
+
+ This indicates that the entity consists of several parts,
+ each itself with a structure that is syntactically identical
+ to an RFC 822 message, except that the header area might be
+ completely empty, and that the parts are each preceded by
+ the line
+
+ --gc0p4Jq0M2Yt08jU534c0p
+
+ Note that the encapsulation boundary must occur at the
+ beginning of a line, i.e., following a CRLF, and that that
+ initial CRLF is considered to be part of the encapsulation
+ boundary rather than part of the preceding part. The
+ boundary must be followed immediately either by another CRLF
+ and the header fields for the next part, or by two CRLFs, in
+ which case there are no header fields for the next part (and
+ it is therefore assumed to be of Content-Type text/plain).
+
+ NOTE: The CRLF preceding the encapsulation line is
+ considered part of the boundary so that it is possible to
+ have a part that does not end with a CRLF (line break).
+ Body parts that must be considered to end with line breaks,
+ therefore, should have two CRLFs preceding the encapsulation
+ line, the first of which is part of the preceding body part,
+ and the second of which is part of the encapsulation
+ boundary.
+
+ The requirement that the encapsulation boundary begins with
+ a CRLF implies that the body of a multipart entity must
+ itself begin with a CRLF before the first encapsulation line
+ -- that is, if the "preamble" area is not used, the entity
+ headers must be followed by TWO CRLFs. This is indeed how
+ such entities should be composed. A tolerant mail reading
+ program, however, may interpret a body of type multipart
+ that begins with an encapsulation line NOT initiated by a
+ CRLF as also being an encapsulation boundary, but a
+ compliant mail sending program must not generate such
+ entities.
+
+ Encapsulation boundaries must not appear within the
+ encapsulations, and must be no longer than 70 characters,
+ not counting the two leading hyphens.
+
+ The encapsulation boundary following the last body part is a
+ distinguished delimiter that indicates that no further body
+ parts will follow. Such a delimiter is identical to the
+ previous delimiters, with the addition of two more hyphens
+ at the end of the line:
+
+ --gc0p4Jq0M2Yt08jU534c0p--
+
+ There appears to be room for additional information prior to
+ the first encapsulation boundary and following the final
+
+
+
+ Borenstein & Freed [Page 31]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ boundary. These areas should generally be left blank, and
+ implementations should ignore anything that appears before
+ the first boundary or after the last one.
+
+ NOTE: These "preamble" and "epilogue" areas are not used
+ because of the lack of proper typing of these parts and the
+ lack of clear semantics for handling these areas at
+ gateways, particularly X.400 gateways.
+
+ NOTE: Because encapsulation boundaries must not appear in
+ the body parts being encapsulated, a user agent must
+ exercise care to choose a unique boundary. The boundary in
+ the example above could have been the result of an algorithm
+ designed to produce boundaries with a very low probability
+ of already existing in the data to be encapsulated without
+ having to prescan the data. Alternate algorithms might
+ result in more 'readable' boundaries for a recipient with an
+ old user agent, but would require more attention to the
+ possibility that the boundary might appear in the
+ encapsulated part. The simplest boundary possible is
+ something like "---", with a closing boundary of "-----".
+
+ As a very simple example, the following multipart message
+ has two parts, both of them plain text, one of them
+ explicitly typed and one of them implicitly typed:
+
+ From: Nathaniel Borenstein <nsb bellcore com>
+ To: Ned Freed <ned innosoft com>
+ Subject: Sample message
+ MIME-Version: 1.0
+ Content-type: multipart/mixed; boundary="simple
+ boundary"
+
+ This is the preamble. It is to be ignored, though it
+ is a handy place for mail composers to include an
+ explanatory note to non-MIME compliant readers.
+ --simple boundary
+
+ This is implicitly typed plain ASCII text.
+ It does NOT end with a linebreak.
+ --simple boundary
+ Content-type: text/plain; charset=us-ascii
+
+ This is explicitly typed plain ASCII text.
+ It DOES end with a linebreak.
+
+ --simple boundary--
+ This is the epilogue. It is also to be ignored.
+
+ The use of a Content-Type of multipart in a body part within
+ another multipart entity is explicitly allowed. In such
+ cases, for obvious reasons, care must be taken to ensure
+ that each nested multipart entity must use a different
+ boundary delimiter. See Appendix C for an example of nested
+
+
+
+ Borenstein & Freed [Page 32]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ multipart entities.
+
+ The use of the multipart Content-Type with only a single
+ body part may be useful in certain contexts, and is
+ explicitly permitted.
+
+ The only mandatory parameter for the multipart Content-Type
+ is the boundary parameter, which consists of 1 to 70
+ characters from a set of characters known to be very robust
+ through email gateways, and NOT ending with white space.
+ (If a boundary appears to end with white space, the white
+ space must be presumed to have been added by a gateway, and
+ should be deleted.) It is formally specified by the
+ following BNF:
+
+ boundary := 0*69<bchars> bcharsnospace
+
+ bchars := bcharsnospace / " "
+
+ bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" /
+ "_"
+ / "," / "-" / "." / "/" / ":" / "=" / "?"
+
+ Overall, the body of a multipart entity may be specified as
+ follows:
+
+ multipart-body := preamble 1*encapsulation
+ close-delimiter epilogue
+
+ encapsulation := delimiter CRLF body-part
+
+ delimiter := CRLF "--" boundary ; taken from Content-Type
+ field.
+ ; when content-type is
+ multipart
+ ; There must be no space
+ ; between "--" and boundary.
+
+ close-delimiter := delimiter "--" ; Again, no space before
+ "--"
+
+ preamble := *text ; to be ignored upon
+ receipt.
+
+ epilogue := *text ; to be ignored upon
+ receipt.
+
+ body-part = <"message" as defined in RFC 822,
+ with all header fields optional, and with the
+ specified delimiter not occurring anywhere in
+ the message body, either on a line by itself
+ or as a substring anywhere. Note that the
+
+
+
+
+
+ Borenstein & Freed [Page 33]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ semantics of a part differ from the semantics
+ of a message, as described in the text.>
+
+ NOTE: Conspicuously missing from the multipart type is a
+ notion of structured, related body parts. In general, it
+ seems premature to try to standardize interpart structure
+ yet. It is recommended that those wishing to provide a more
+ structured or integrated multipart messaging facility should
+ define a subtype of multipart that is syntactically
+ identical, but that always expects the inclusion of a
+ distinguished part that can be used to specify the structure
+ and integration of the other parts, probably referring to
+ them by their Content-ID field. If this approach is used,
+ other implementations will not recognize the new subtype,
+ but will treat it as the primary subtype (multipart/mixed)
+ and will thus be able to show the user the parts that are
+ recognized.
+
+ 7.2.2 The Multipart/mixed (primary) subtype
+
+ The primary subtype for multipart, "mixed", is intended for
+ use when the body parts are independent and intended to be
+ displayed serially. Any multipart subtypes that an
+ implementation does not recognize should be treated as being
+ of subtype "mixed".
+
+ 7.2.3 The Multipart/alternative subtype
+
+ The multipart/alternative type is syntactically identical to
+ multipart/mixed, but the semantics are different. In
+ particular, each of the parts is an "alternative" version of
+ the same information. User agents should recognize that the
+ content of the various parts are interchangeable. The user
+ agent should either choose the "best" type based on the
+ user's environment and preferences, or offer the user the
+ available alternatives. In general, choosing the best type
+ means displaying only the LAST part that can be displayed.
+ This may be used, for example, to send mail in a fancy text
+ format in such a way that it can easily be displayed
+ anywhere:
+
+ From: Nathaniel Borenstein <nsb bellcore com>
+ To: Ned Freed <ned innosoft com>
+ Subject: Formatted text mail
+ MIME-Version: 1.0
+ Content-Type: multipart/alternative; boundary=boundary42
+
+
+ --boundary42
+ Content-Type: text/plain; charset=us-ascii
+
+ ...plain text version of message goes here....
+
+
+
+
+
+ Borenstein & Freed [Page 34]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ --boundary42
+ Content-Type: text/richtext
+
+ .... richtext version of same message goes here ...
+ --boundary42
+ Content-Type: text/x-whatever
+
+ .... fanciest formatted version of same message goes here
+ ...
+ --boundary42--
+
+ In this example, users whose mail system understood the
+ "text/x-whatever" format would see only the fancy version,
+ while other users would see only the richtext or plain text
+ version, depending on the capabilities of their system.
+
+ In general, user agents that compose multipart/alternative
+ entities should place the body parts in increasing order of
+ preference, that is, with the preferred format last. For
+ fancy text, the sending user agent should put the plainest
+ format first and the richest format last. Receiving user
+ agents should pick and display the last format they are
+ capable of displaying. In the case where one of the
+ alternatives is itself of type "multipart" and contains
+ unrecognized sub-parts, the user agent may choose either to
+ show that alternative, an earlier alternative, or both.
+
+ NOTE: From an implementor's perspective, it might seem more
+ sensible to reverse this ordering, and have the plainest
+ alternative last. However, placing the plainest alternative
+ first is the friendliest possible option when
+ mutlipart/alternative entities are viewed using a non-MIME-
+ compliant mail reader. While this approach does impose some
+ burden on compliant mail readers, interoperability with
+ older mail readers was deemed to be more important in this
+ case.
+
+ It may be the case that some user agents, if they can
+ recognize more than one of the formats, will prefer to offer
+ the user the choice of which format to view. This makes
+ sense, for example, if mail includes both a nicely-formatted
+ image version and an easily-edited text version. What is
+ most critical, however, is that the user not automatically
+ be shown multiple versions of the same data. Either the
+ user should be shown the last recognized version or should
+ explicitly be given the choice.
+
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 35]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ 7.2.4 The Multipart/digest subtype
+
+ This document defines a "digest" subtype of the multipart
+ Content-Type. This type is syntactically identical to
+ multipart/mixed, but the semantics are different. In
+ particular, in a digest, the default Content-Type value for
+ a body part is changed from "text/plain" to
+ "message/rfc822". This is done to allow a more readable
+ digest format that is largely compatible (except for the
+ quoting convention) with RFC 934.
+
+ A digest in this format might, then, look something like
+ this:
+
+ From: Moderator-Address
+ MIME-Version: 1.0
+ Subject: Internet Digest, volume 42
+ Content-Type: multipart/digest;
+ boundary="---- next message ----"
+
+
+ ------ next message ----
+
+ From: someone-else
+ Subject: my opinion
+
+ ...body goes here ...
+
+ ------ next message ----
+
+ From: someone-else-again
+ Subject: my different opinion
+
+ ... another body goes here...
+
+ ------ next message ------
+
+ 7.2.5 The Multipart/parallel subtype
+
+ This document defines a "parallel" subtype of the multipart
+ Content-Type. This type is syntactically identical to
+ multipart/mixed, but the semantics are different. In
+ particular, in a parallel entity, all of the parts are
+ intended to be presented in parallel, i.e., simultaneously,
+ on hardware and software that are capable of doing so.
+ Composing agents should be aware that many mail readers will
+ lack this capability and will show the parts serially in any
+ event.
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 36]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ 7.3 The Message Content-Type
+
+ It is frequently desirable, in sending mail, to encapsulate
+ another mail message. For this common operation, a special
+ Content-Type, "message", is defined. The primary subtype,
+ message/rfc822, has no required parameters in the Content-
+ Type field. Additional subtypes, "partial" and "External-
+ body", do have required parameters. These subtypes are
+ explained below.
+
+ NOTE: It has been suggested that subtypes of message might
+ be defined for forwarded or rejected messages. However,
+ forwarded and rejected messages can be handled as multipart
+ messages in which the first part contains any control or
+ descriptive information, and a second part, of type
+ message/rfc822, is the forwarded or rejected message.
+ Composing rejection and forwarding messages in this manner
+ will preserve the type information on the original message
+ and allow it to be correctly presented to the recipient, and
+ hence is strongly encouraged.
+
+ As stated in the definition of the Content-Transfer-Encoding
+ field, no encoding other than "7bit", "8bit", or "binary" is
+ permitted for messages or parts of type "message". The
+ message header fields are always US-ASCII in any case, and
+ data within the body can still be encoded, in which case the
+ Content-Transfer-Encoding header field in the encapsulated
+ message will reflect this. Non-ASCII text in the headers of
+ an encapsulated message can be specified using the
+ mechanisms described in [RFC-1342].
+
+ Mail gateways, relays, and other mail handling agents are
+ commonly known to alter the top-level header of an RFC 822
+ message. In particular, they frequently add, remove, or
+ reorder header fields. Such alterations are explicitly
+ forbidden for the encapsulated headers embedded in the
+ bodies of messages of type "message."
+
+ 7.3.1 The Message/rfc822 (primary) subtype
+
+ A Content-Type of "message/rfc822" indicates that the body
+ contains an encapsulated message, with the syntax of an RFC
+ 822 message.
+
+ 7.3.2 The Message/Partial subtype
+
+ A subtype of message, "partial", is defined in order to
+ allow large objects to be delivered as several separate
+ pieces of mail and automatically reassembled by the
+ receiving user agent. (The concept is similar to IP
+ fragmentation/reassembly in the basic Internet Protocols.)
+ This mechanism can be used when intermediate transport
+ agents limit the size of individual messages that can be
+ sent. Content-Type "message/partial" thus indicates that
+
+
+
+ Borenstein & Freed [Page 37]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ the body contains a fragment of a larger message.
+
+ Three parameters must be specified in the Content-Type field
+ of type message/partial: The first, "id", is a unique
+ identifier, as close to a world-unique identifier as
+ possible, to be used to match the parts together. (In
+ general, the identifier is essentially a message-id; if
+ placed in double quotes, it can be any message-id, in
+ accordance with the BNF for "parameter" given earlier in
+ this specification.) The second, "number", an integer, is
+ the part number, which indicates where this part fits into
+ the sequence of fragments. The third, "total", another
+ integer, is the total number of parts. This third subfield
+ is required on the final part, and is optional on the
+ earlier parts. Note also that these parameters may be given
+ in any order.
+
+ Thus, part 2 of a 3-part message may have either of the
+ following header fields:
+
+ Content-Type: Message/Partial;
+ number=2; total=3;
+ id="oc=jpbe0M2Yt4s thumper bellcore com";
+
+ Content-Type: Message/Partial;
+ id="oc=jpbe0M2Yt4s thumper bellcore com";
+ number=2
+
+ But part 3 MUST specify the total number of parts:
+
+ Content-Type: Message/Partial;
+ number=3; total=3;
+ id="oc=jpbe0M2Yt4s thumper bellcore com";
+
+ Note that part numbering begins with 1, not 0.
+
+ When the parts of a message broken up in this manner are put
+ together, the result is a complete RFC 822 format message,
+ which may have its own Content-Type header field, and thus
+ may contain any other data type.
+
+ Message fragmentation and reassembly: The semantics of a
+ reassembled partial message must be those of the "inner"
+ message, rather than of a message containing the inner
+ message. This makes it possible, for example, to send a
+ large audio message as several partial messages, and still
+ have it appear to the recipient as a simple audio message
+ rather than as an encapsulated message containing an audio
+ message. That is, the encapsulation of the message is
+ considered to be "transparent".
+
+ When generating and reassembling the parts of a
+ message/partial message, the headers of the encapsulated
+ message must be merged with the headers of the enclosing
+
+
+
+ Borenstein & Freed [Page 38]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ entities. In this process the following rules must be
+ observed:
+
+ (1) All of the headers from the initial enclosing
+ entity (part one), except those that start with
+ "Content-" and "Message-ID", must be copied, in
+ order, to the new message.
+
+ (2) Only those headers in the enclosed message
+ which start with "Content-" and "Message-ID" must
+ be appended, in order, to the headers of the new
+ message. Any headers in the enclosed message
+ which do not start with "Content-" (except for
+ "Message-ID") will be ignored.
+
+ (3) All of the headers from the second and any
+ subsequent messages will be ignored.
+
+ For example, if an audio message is broken into two parts,
+ the first part might look something like this:
+
+ X-Weird-Header-1: Foo
+ From: Bill host com
+ To: joe otherhost com
+ Subject: Audio mail
+ Message-ID: id1 host com
+ MIME-Version: 1.0
+ Content-type: message/partial;
+ id="ABC host com";
+ number=1; total=2
+
+ X-Weird-Header-1: Bar
+ X-Weird-Header-2: Hello
+ Message-ID: anotherid foo com
+ Content-type: audio/basic
+ Content-transfer-encoding: base64
+
+ ... first half of encoded audio data goes here...
+
+ and the second half might look something like this:
+
+ From: Bill host com
+ To: joe otherhost com
+ Subject: Audio mail
+ MIME-Version: 1.0
+ Message-ID: id2 host com
+ Content-type: message/partial;
+ id="ABC host com"; number=2; total=2
+
+ ... second half of encoded audio data goes here...
+
+ Then, when the fragmented message is reassembled, the
+ resulting message to be displayed to the user should look
+ something like this:
+
+
+
+ Borenstein & Freed [Page 39]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ X-Weird-Header-1: Foo
+ From: Bill host com
+ To: joe otherhost com
+ Subject: Audio mail
+ Message-ID: anotherid foo com
+ MIME-Version: 1.0
+ Content-type: audio/basic
+ Content-transfer-encoding: base64
+
+ ... first half of encoded audio data goes here...
+ ... second half of encoded audio data goes here...
+
+ It should be noted that, because some message transfer
+ agents may choose to automatically fragment large messages,
+ and because such agents may use different fragmentation
+ thresholds, it is possible that the pieces of a partial
+ message, upon reassembly, may prove themselves to comprise a
+ partial message. This is explicitly permitted.
+
+ It should also be noted that the inclusion of a "References"
+ field in the headers of the second and subsequent pieces of
+ a fragmented message that references the Message-Id on the
+ previous piece may be of benefit to mail readers that
+ understand and track references. However, the generation of
+ such "References" fields is entirely optional.
+
+ 7.3.3 The Message/External-Body subtype
+
+ The external-body subtype indicates that the actual body
+ data are not included, but merely referenced. In this case,
+ the parameters describe a mechanism for accessing the
+ external data.
+
+ When a message body or body part is of type
+ "message/external-body", it consists of a header, two
+ consecutive CRLFs, and the message header for the
+ encapsulated message. If another pair of consecutive CRLFs
+ appears, this of course ends the message header for the
+ encapsulated message. However, since the encapsulated
+ message's body is itself external, it does NOT appear in the
+ area that follows. For example, consider the following
+ message:
+
+ Content-type: message/external-body; access-
+ type=local-file;
+ name=/u/nsb/Me.gif
+
+ Content-type: image/gif
+
+ THIS IS NOT REALLY THE BODY!
+
+ The area at the end, which might be called the "phantom
+ body", is ignored for most external-body messages. However,
+ it may be used to contain auxilliary information for some
+
+
+
+ Borenstein & Freed [Page 40]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ such messages, as indeed it is when the access-type is
+ "mail-server". Of the access-types defined by this
+ document, the phantom body is used only when the access-type
+ is "mail-server". In all other cases, the phantom body is
+ ignored.
+
+ The only always-mandatory parameter for message/external-
+ body is "access-type"; all of the other parameters may be
+ mandatory or optional depending on the value of access-type.
+
+ ACCESS-TYPE -- One or more case-insensitive words,
+ comma-separated, indicating supported access
+ mechanisms by which the file or data may be
+ obtained. Values include, but are not limited to,
+ "FTP", "ANON-FTP", "TFTP", "AFS", "LOCAL-FILE",
+ and "MAIL-SERVER". Future values, except for
+ experimental values beginning with "X-", must be
+ registered with IANA, as described in Appendix F .
+
+ In addition, the following two parameters are optional for
+ ALL access-types:
+
+ EXPIRATION -- The date (in the RFC 822 "date-time"
+ syntax, as extended by RFC 1123 to permit 4 digits
+ in the date field) after which the existence of
+ the external data is not guaranteed.
+
+ SIZE -- The size (in octets) of the data. The
+ intent of this parameter is to help the recipient
+ decide whether or not to expend the necessary
+ resources to retrieve the external data.
+
+ PERMISSION -- A field that indicates whether or
+ not it is expected that clients might also attempt
+ to overwrite the data. By default, or if
+ permission is "read", the assumption is that they
+ are not, and that if the data is retrieved once,
+ it is never needed again. If PERMISSION is "read-
+ write", this assumption is invalid, and any local
+ copy must be considered no more than a cache.
+ "Read" and "Read-write" are the only defined
+ values of permission.
+
+ The precise semantics of the access-types defined here are
+ described in the sections that follow.
+
+ 7.3.3.1 The "ftp" and "tftp" access-types
+
+ An access-type of FTP or TFTP indicates that the message
+ body is accessible as a file using the FTP [RFC-959] or TFTP
+ [RFC-783] protocols, respectively. For these access-types,
+ the following additional parameters are mandatory:
+
+
+
+
+
+ Borenstein & Freed [Page 41]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ NAME -- The name of the file that contains the
+ actual body data.
+
+ SITE -- A machine from which the file may be
+ obtained, using the given protocol
+
+ Before the data is retrieved, using these protocols, the
+ user will generally need to be asked to provide a login id
+ and a password for the machine named by the site parameter.
+
+ In addition, the following optional parameters may also
+ appear when the access-type is FTP or ANON-FTP:
+
+ DIRECTORY -- A directory from which the data named
+ by NAME should be retrieved.
+
+ MODE -- A transfer mode for retrieving the
+ information, e.g. "image".
+
+ 7.3.3.2 The "anon-ftp" access-type
+
+ The "anon-ftp" access-type is identical to the "ftp" access
+ type, except that the user need not be asked to provide a
+ name and password for the specified site. Instead, the ftp
+ protocol will be used with login "anonymous" and a password
+ that corresponds to the user's email address.
+
+ 7.3.3.3 The "local-file" and "afs" access-types
+
+ An access-type of "local-file" indicates that the actual
+ body is accessible as a file on the local machine. An
+ access-type of "afs" indicates that the file is accessible
+ via the global AFS file system. In both cases, only a
+ single parameter is required:
+
+ NAME -- The name of the file that contains the
+ actual body data.
+
+ The following optional parameter may be used to describe the
+ locality of reference for the data, that is, the site or
+ sites at which the file is expected to be visible:
+
+ SITE -- A domain specifier for a machine or set of
+ machines that are known to have access to the data
+ file. Asterisks may be used for wildcard matching
+ to a part of a domain name, such as
+ "*.bellcore.com", to indicate a set of machines on
+ which the data should be directly visible, while a
+ single asterisk may be used to indicate a file
+ that is expected to be universally available,
+ e.g., via a global file system.
+
+ 7.3.3.4 The "mail-server" access-type
+
+
+
+
+ Borenstein & Freed [Page 42]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ The "mail-server" access-type indicates that the actual body
+ is available from a mail server. The mandatory parameter
+ for this access-type is:
+
+ SERVER -- The email address of the mail server
+ from which the actual body data can be obtained.
+
+ Because mail servers accept a variety of syntax, some of
+ which is multiline, the full command to be sent to a mail
+ server is not included as a parameter on the content-type
+ line. Instead, it may be provided as the "phantom body"
+ when the content-type is message/external-body and the
+ access-type is mail-server.
+
+ Note that MIME does not define a mail server syntax.
+ Rather, it allows the inclusion of arbitrary mail server
+ commands in the phantom body. Implementations should
+ include the phantom body in the body of the message it sends
+ to the mail server address to retrieve the relevant data.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 43]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ 7.3.3.5 Examples and Further Explanations
+
+ With the emerging possibility of very wide-area file
+ systems, it becomes very hard to know in advance the set of
+ machines where a file will and will not be accessible
+ directly from the file system. Therefore it may make sense
+ to provide both a file name, to be tried directly, and the
+ name of one or more sites from which the file is known to be
+ accessible. An implementation can try to retrieve remote
+ files using FTP or any other protocol, using anonymous file
+ retrieval or prompting the user for the necessary name and
+ password. If an external body is accessible via multiple
+ mechanisms, the sender may include multiple parts of type
+ message/external-body within an entity of type
+ multipart/alternative.
+
+ However, the external-body mechanism is not intended to be
+ limited to file retrieval, as shown by the mail-server
+ access-type. Beyond this, one can imagine, for example,
+ using a video server for external references to video clips.
+
+ If an entity is of type "message/external-body", then the
+ body of the entity will contain the header fields of the
+ encapsulated message. The body itself is to be found in the
+ external location. This means that if the body of the
+ "message/external-body" message contains two consecutive
+ CRLFs, everything after those pairs is NOT part of the
+ message itself. For most message/external-body messages,
+ this trailing area must simply be ignored. However, it is a
+ convenient place for additional data that cannot be included
+ in the content-type header field. In particular, if the
+ "access-type" value is "mail-server", then the trailing area
+ must contain commands to be sent to the mail server at the
+ address given by NAME SITE, where NAME and SITE are the
+ values of the NAME and SITE parameters, respectively.
+
+ The embedded message header fields which appear in the body
+ of the message/external-body data can be used to declare the
+ Content-type of the external body. Thus a complete
+ message/external-body message, referring to a document in
+ PostScript format, might look like this:
+
+ From: Whomever
+ Subject: whatever
+ MIME-Version: 1.0
+ Message-ID: id1 host com
+ Content-Type: multipart/alternative; boundary=42
+
+
+ --42
+ Content-Type: message/external-body;
+ name="BodyFormats.ps";
+
+
+
+
+
+ Borenstein & Freed [Page 44]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ site="thumper.bellcore.com";
+ access-type=ANON-FTP;
+ directory="pub";
+ mode="image";
+ expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
+
+ Content-type: application/postscript
+
+ --42
+ Content-Type: message/external-body;
+ name="/u/nsb/writing/rfcs/RFC-XXXX.ps";
+ site="thumper.bellcore.com";
+ access-type=AFS
+ expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
+
+ Content-type: application/postscript
+
+ --42
+ Content-Type: message/external-body;
+ access-type=mail-server
+ server="listserv bogus bitnet";
+ expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
+
+ Content-type: application/postscript
+
+ get rfc-xxxx doc
+
+ --42--
+
+ Like the message/partial type, the message/external-body
+ type is intended to be transparent, that is, to convey the
+ data type in the external body rather than to convey a
+ message with a body of that type. Thus the headers on the
+ outer and inner parts must be merged using the same rules as
+ for message/partial. In particular, this means that the
+ Content-type header is overridden, but the From and Subject
+ headers are preserved.
+
+ Note that since the external bodies are not transported as
+ mail, they need not conform to the 7-bit and line length
+ requirements, but might in fact be binary files. Thus a
+ Content-Transfer-Encoding is not generally necessary, though
+ it is permitted.
+
+ Note that the body of a message of type "message/external-
+ body" is governed by the basic syntax for an RFC 822
+ message. In particular, anything before the first
+ consecutive pair of CRLFs is header information, while
+ anything after it is body information, which is ignored for
+ most access-types.
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 45]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ 7.4 The Application Content-Type
+
+ The "application" Content-Type is to be used for data which
+ do not fit in any of the other categories, and particularly
+ for data to be processed by mail-based uses of application
+ programs. This is information which must be processed by an
+ application before it is viewable or usable to a user.
+ Expected uses for Content-Type application include mail-
+ based file transfer, spreadsheets, data for mail-based
+ scheduling systems, and languages for "active"
+ (computational) email. (The latter, in particular, can pose
+ security problems which should be understood by
+ implementors, and are considered in detail in the discussion
+ of the application/PostScript content-type.)
+
+ For example, a meeting scheduler might define a standard
+ representation for information about proposed meeting dates.
+ An intelligent user agent would use this information to
+ conduct a dialog with the user, and might then send further
+ mail based on that dialog. More generally, there have been
+ several "active" messaging languages developed in which
+ programs in a suitably specialized language are sent through
+ the mail and automatically run in the recipient's
+ environment.
+
+ Such applications may be defined as subtypes of the
+ "application" Content-Type. This document defines three
+ subtypes: octet-stream, ODA, and PostScript.
+
+ In general, the subtype of application will often be the
+ name of the application for which the data are intended.
+ This does not mean, however, that any application program
+ name may be used freely as a subtype of application. Such
+ usages must be registered with IANA, as described in
+ Appendix F.
+
+ 7.4.1 The Application/Octet-Stream (primary) subtype
+
+ The primary subtype of application, "octet-stream", may be
+ used to indicate that a body contains binary data. The set
+ of possible parameters includes, but is not limited to:
+
+ NAME -- a suggested name for the binary data if
+ stored as a file.
+
+ TYPE -- the general type or category of binary
+ data. This is intended as information for the
+ human recipient rather than for any automatic
+ processing.
+
+ CONVERSIONS -- the set of operations that have
+ been performed on the data before putting it in
+ the mail (and before any Content-Transfer-Encoding
+ that might have been applied). If multiple
+
+
+
+ Borenstein & Freed [Page 46]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ conversions have occurred, they must be separated
+ by commas and specified in the order they were
+ applied -- that is, the leftmost conversion must
+ have occurred first, and conversions are undone
+ from right to left. Note that NO conversion
+ values are defined by this document. Any
+ conversion values that that do not begin with "X-"
+ must be preceded by a published specification and
+ by registration with IANA, as described in
+ Appendix F.
+
+ PADDING -- the number of bits of padding that were
+ appended to the bitstream comprising the actual
+ contents to produce the enclosed byte-oriented
+ data. This is useful for enclosing a bitstream in
+ a body when the total number of bits is not a
+ multiple of the byte size.
+
+ The values for these attributes are left undefined at
+ present, but may require specification in the future. An
+ example of a common (though UNIX-specific) usage might be:
+
+ Content-Type: application/octet-stream;
+ name=foo.tar.Z; type=tar;
+ conversions="x-encrypt,x-compress"
+
+ However, it should be noted that the use of such conversions
+ is explicitly discouraged due to a lack of portability and
+ standardization. The use of uuencode is particularly
+ discouraged, in favor of the Content-Transfer-Encoding
+ mechanism, which is both more standardized and more portable
+ across mail boundaries.
+
+ The recommended action for an implementation that receives
+ application/octet-stream mail is to simply offer to put the
+ data in a file, with any Content-Transfer-Encoding undone,
+ or perhaps to use it as input to a user-specified process.
+
+ To reduce the danger of transmitting rogue programs through
+ the mail, it is strongly recommended that implementations
+ NOT implement a path-search mechanism whereby an arbitrary
+ program named in the Content-Type parameter (e.g., an
+ "interpreter=" parameter) is found and executed using the
+ mail body as input.
+
+ 7.4.2 The Application/PostScript subtype
+
+ A Content-Type of "application/postscript" indicates a
+ PostScript program. The language is defined in
+ [POSTSCRIPT]. It is recommended that Postscript as sent
+ through email should use Postscript document structuring
+ conventions if at all possible, and correctly.
+
+
+
+
+
+ Borenstein & Freed [Page 47]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ The execution of general-purpose PostScript interpreters
+ entails serious security risks, and implementors are
+ discouraged from simply sending PostScript email bodies to
+ "off-the-shelf" interpreters. While it is usually safe to
+ send PostScript to a printer, where the potential for harm
+ is greatly constrained, implementors should consider all of
+ the following before they add interactive display of
+ PostScript bodies to their mail readers.
+
+ The remainder of this section outlines some, though probably
+ not all, of the possible problems with sending PostScript
+ through the mail.
+
+ Dangerous operations in the PostScript language include, but
+ may not be limited to, the PostScript operators deletefile,
+ renamefile, filenameforall, and file. File is only
+ dangerous when applied to something other than standard
+ input or output. Implementations may also define additional
+ nonstandard file operators; these may also pose a threat to
+ security. Filenameforall, the wildcard file search
+ operator, may appear at first glance to be harmless. Note,
+ however, that this operator has the potential to reveal
+ information about what files the recipient has access to,
+ and this information may itself be sensitive. Message
+ senders should avoid the use of potentially dangerous file
+ operators, since these operators are quite likely to be
+ unavailable in secure PostScript implementations. Message-
+ receiving and -displaying software should either completely
+ disable all potentially dangerous file operators or take
+ special care not to delegate any special authority to their
+ operation. These operators should be viewed as being done by
+ an outside agency when interpreting PostScript documents.
+ Such disabling and/or checking should be done completely
+ outside of the reach of the PostScript language itself; care
+ should be taken to insure that no method exists for
+ reenabling full-function versions of these operators.
+
+ The PostScript language provides facilities for exiting the
+ normal interpreter, or server, loop. Changes made in this
+ "outer" environment are customarily retained across
+ documents, and may in some cases be retained semipermanently
+ in nonvolatile memory. The operators associated with exiting
+ the interpreter loop have the potential to interfere with
+ subsequent document processing. As such, their unrestrained
+ use constitutes a threat of service denial. PostScript
+ operators that exit the interpreter loop include, but may
+ not be limited to, the exitserver and startjob operators.
+ Message-sending software should not generate PostScript that
+ depends on exiting the interpreter loop to operate. The
+ ability to exit will probably be unavailable in secure
+ PostScript implementations. Message-receiving and
+ -displaying software should, if possible, disable the
+ ability to make retained changes to the PostScript
+ environment. Eliminate the startjob and exitserver commands.
+
+
+
+ Borenstein & Freed [Page 48]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ If these commands cannot be eliminated, at least set the
+ password associated with them to a hard-to-guess value.
+
+ PostScript provides operators for setting system-wide and
+ device-specific parameters. These parameter settings may be
+ retained across jobs and may potentially pose a threat to
+ the correct operation of the interpreter. The PostScript
+ operators that set system and device parameters include, but
+ may not be limited to, the setsystemparams and setdevparams
+ operators. Message-sending software should not generate
+ PostScript that depends on the setting of system or device
+ parameters to operate correctly. The ability to set these
+ parameters will probably be unavailable in secure PostScript
+ implementations. Message-receiving and -displaying software
+ should, if possible, disable the ability to change system
+ and device parameters. If these operators cannot be
+ disabled, at least set the password associated with them to
+ a hard-to-guess value.
+
+ Some PostScript implementations provide nonstandard
+ facilities for the direct loading and execution of machine
+ code. Such facilities are quite obviously open to
+ substantial abuse. Message-sending software should not
+ make use of such features. Besides being totally hardware-
+ specific, they are also likely to be unavailable in secure
+ implementations of PostScript. Message-receiving and
+ -displaying software should not allow such operators to be
+ used if they exist.
+
+ PostScript is an extensible language, and many, if not most,
+ implementations of it provide a number of their own
+ extensions. This document does not deal with such extensions
+ explicitly since they constitute an unknown factor.
+ Message-sending software should not make use of nonstandard
+ extensions; they are likely to be missing from some
+ implementations. Message-receiving and -displaying software
+ should make sure that any nonstandard PostScript operators
+ are secure and don't present any kind of threat.
+
+ It is possible to write PostScript that consumes huge
+ amounts of various system resources. It is also possible to
+ write PostScript programs that loop infinitely. Both types
+ of programs have the potential to cause damage if sent to
+ unsuspecting recipients. Message-sending software should
+ avoid the construction and dissemination of such programs,
+ which is antisocial. Message-receiving and -displaying
+ software should provide appropriate mechanisms to abort
+ processing of a document after a reasonable amount of time
+ has elapsed. In addition, PostScript interpreters should be
+ limited to the consumption of only a reasonable amount of
+ any given system resource.
+
+ Finally, bugs may exist in some PostScript interpreters
+ which could possibly be exploited to gain unauthorized
+
+
+
+ Borenstein & Freed [Page 49]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ access to a recipient's system. Apart from noting this
+ possibility, there is no specific action to take to prevent
+ this, apart from the timely correction of such bugs if any
+ are found.
+
+ 7.4.3 The Application/ODA subtype
+
+ The "ODA" subtype of application is used to indicate that a
+ body contains information encoded according to the Office
+ Document Architecture [ODA] standards, using the ODIF
+ representation format. For application/oda, the Content-
+ Type line should also specify an attribute/value pair that
+ indicates the document application profile (DAP), using the
+ key word "profile". Thus an appropriate header field might
+ look like this:
+
+ Content-Type: application/oda; profile=Q112
+
+ Consult the ODA standard [ODA] for further information.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 50]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ 7.5 The Image Content-Type
+
+ A Content-Type of "image" indicates that the bodycontains an
+ image. The subtype names the specific image format. These
+ names are case insensitive. Two initial subtypes are "jpeg"
+ for the JPEG format, JFIF encoding, and "gif" for GIF format
+ [GIF].
+
+ The list of image subtypes given here is neither exclusive
+ nor exhaustive, and is expected to grow as more types are
+ registered with IANA, as described in Appendix F.
+
+ 7.6 The Audio Content-Type
+
+ A Content-Type of "audio" indicates that the body contains
+ audio data. Although there is not yet a consensus on an
+ "ideal" audio format for use with computers, there is a
+ pressing need for a format capable of providing
+ interoperable behavior.
+
+ The initial subtype of "basic" is specified to meet this
+ requirement by providing an absolutely minimal lowest common
+ denominator audio format. It is expected that richer
+ formats for higher quality and/or lower bandwidth audio will
+ be defined by a later document.
+
+ The content of the "audio/basic" subtype is audio encoded
+ using 8-bit ISDN u-law [PCM]. When this subtype is present,
+ a sample rate of 8000 Hz and a single channel is assumed.
+
+ 7.7 The Video Content-Type
+
+ A Content-Type of "video" indicates that the body contains a
+ time-varying-picture image, possibly with color and
+ coordinated sound. The term "video" is used extremely
+ generically, rather than with reference to any particular
+ technology or format, and is not meant to preclude subtypes
+ such as animated drawings encoded compactly. The subtype
+ "mpeg" refers to video coded according to the MPEG standard
+ [MPEG].
+
+ Note that although in general this document strongly
+ discourages the mixing of multiple media in a single body,
+ it is recognized that many so-called "video" formats include
+ a representation for synchronized audio, and this is
+ explicitly permitted for subtypes of "video".
+
+ 7.8 Experimental Content-Type Values
+
+ A Content-Type value beginning with the characters "X-" is a
+ private value, to be used by consenting mail systems by
+ mutual agreement. Any format without a rigorous and public
+ definition must be named with an "X-" prefix, and publicly
+ specified values shall never begin with "X-". (Older
+
+
+
+ Borenstein & Freed [Page 51]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ versions of the widely-used Andrew system use the "X-BE2"
+ name, so new systems should probably choose a different
+ name.)
+
+ In general, the use of "X-" top-level types is strongly
+ discouraged. Implementors should invent subtypes of the
+ existing types whenever possible. The invention of new
+ types is intended to be restricted primarily to the
+ development of new media types for email, such as digital
+ odors or holography, and not for new data formats in
+ general. In many cases, a subtype of application will be
+ more appropriate than a new top-level type.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 52]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ Summary
+
+ Using the MIME-Version, Content-Type, and Content-Transfer-
+ Encoding header fields, it is possible to include, in a
+ standardized way, arbitrary types of data objects with RFC
+ 822 conformant mail messages. No restrictions imposed by
+ either RFC 821 or RFC 822 are violated, and care has been
+ taken to avoid problems caused by additional restrictions
+ imposed by the characteristics of some Internet mail
+ transport mechanisms (see Appendix B). The "multipart" and
+ "message" Content-Types allow mixing and hierarchical
+ structuring of objects of different types in a single
+ message. Further Content-Types provide a standardized
+ mechanism for tagging messages or body parts as audio,
+ image, or several other kinds of data. A distinguished
+ parameter syntax allows further specification of data format
+ details, particularly the specification of alternate
+ character sets. Additional optional header fields provide
+ mechanisms for certain extensions deemed desirable by many
+ implementors. Finally, a number of useful Content-Types are
+ defined for general use by consenting user agents, notably
+ text/richtext, message/partial, and message/external-body.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 53]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ Acknowledgements
+
+ This document is the result of the collective effort of a
+ large number of people, at several IETF meetings, on the
+ IETF-SMTP and IETF-822 mailing lists, and elsewhere.
+ Although any enumeration seems doomed to suffer from
+ egregious omissions, the following are among the many
+ contributors to this effort:
+
+ Harald Tveit Alvestrand Timo Lehtinen
+ Randall Atkinson John R. MacMillan
+ Philippe Brandon Rick McGowan
+ Kevin Carosso Leo Mclaughlin
+ Uhhyung Choi Goli Montaser-Kohsari
+ Cristian Constantinof Keith Moore
+ Mark Crispin Tom Moore
+ Dave Crocker Erik Naggum
+ Terry Crowley Mark Needleman
+ Walt Daniels John Noerenberg
+ Frank Dawson Mats Ohrman
+ Hitoshi Doi Julian Onions
+ Kevin Donnelly Michael Patton
+ Keith Edwards David J. Pepper
+ Chris Eich Blake C. Ramsdell
+ Johnny Eriksson Luc Rooijakkers
+ Craig Everhart Marshall T. Rose
+ Patrik Faeltstroem Jonathan Rosenberg
+ Erik E. Fair Jan Rynning
+ Roger Fajman Harri Salminen
+ Alain Fontaine Michael Sanderson
+ James M. Galvin Masahiro Sekiguchi
+ Philip Gladstone Mark Sherman
+ Thomas Gordon Keld Simonsen
+ Phill Gross Bob Smart
+ James Hamilton Peter Speck
+ Steve Hardcastle-Kille Henry Spencer
+ David Herron Einar Stefferud
+ Bruce Howard Michael Stein
+ Bill Janssen Klaus Steinberger
+ Olle Jaernefors Peter Svanberg
+ Risto Kankkunen James Thompson
+ Phil Karn Steve Uhler
+ Alan Katz Stuart Vance
+ Tim Kehres Erik van der Poel
+ Neil Katin Guido van Rossum
+ Kyuho Kim Peter Vanderbilt
+ Anders Klemets Greg Vaudreuil
+ John Klensin Ed Vielmetti
+ Valdis Kletniek Ryan Waldron
+ Jim Knowles Wally Wedel
+ Stev Knowles Sven-Ove Westberg
+ Bob Kummerfeld Brian Wideen
+
+
+
+
+
+ Borenstein & Freed [Page 54]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ Pekka Kytolaakso John Wobus
+ Stellan Lagerstr.m Glenn Wright
+ Vincent Lau Rayan Zachariassen
+ Donald Lindsay David Zimmerman
+ The authors apologize for any omissions from this list,
+ which are certainly unintentional.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 55]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ Appendix A -- Minimal MIME-Conformance
+
+ The mechanisms described in this document are open-ended.
+ It is definitely not expected that all implementations will
+ support all of the Content-Types described, nor that they
+ will all share the same extensions. In order to promote
+ interoperability, however, it is useful to define the
+ concept of "MIME-conformance" to define a certain level of
+ implementation that allows the useful interworking of
+ messages with content that differs from US ASCII text. In
+ this section, we specify the requirements for such
+ conformance.
+
+ A mail user agent that is MIME-conformant MUST:
+
+ 1. Always generate a "MIME-Version: 1.0" header
+ field.
+
+ 2. Recognize the Content-Transfer-Encoding header
+ field, and decode all received data encoded with
+ either the quoted-printable or base64
+ implementations. Encode any data sent that is
+ not in seven-bit mail-ready representation using
+ one of these transformations and include the
+ appropriate Content-Transfer-Encoding header
+ field, unless the underlying transport mechanism
+ supports non-seven-bit data, as SMTP does not.
+
+ 3. Recognize and interpret the Content-Type
+ header field, and avoid showing users raw data
+ with a Content-Type field other than text. Be
+ able to send at least text/plain messages, with
+ the character set specified as a parameter if it
+ is not US-ASCII.
+
+ 4. Explicitly handle the following Content-Type
+ values, to at least the following extents:
+
+ Text:
+ -- Recognize and display "text" mail
+ with the character set "US-ASCII."
+ -- Recognize other character sets at
+ least to the extent of being able
+ to inform the user about what
+ character set the message uses.
+ -- Recognize the "ISO-8859-*" character
+ sets to the extent of being able to
+ display those characters that are
+ common to ISO-8859-* and US-ASCII,
+ namely all characters represented
+ by octet values 0-127.
+ -- For unrecognized subtypes, show or
+ offer to show the user the "raw"
+ version of the data. An ability at
+
+
+
+ Borenstein & Freed [Page 56]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ least to convert "text/richtext" to
+ plain text, as shown in Appendix D,
+ is encouraged, but not required for
+ conformance.
+ Message:
+ --Recognize and display at least the
+ primary (822) encapsulation.
+ Multipart:
+ -- Recognize the primary (mixed)
+ subtype. Display all relevant
+ information on the message level
+ and the body part header level and
+ then display or offer to display
+ each of the body parts
+ individually.
+ -- Recognize the "alternative" subtype,
+ and avoid showing the user
+ redundant parts of
+ multipart/alternative mail.
+ -- Treat any unrecognized subtypes as if
+ they were "mixed".
+ Application:
+ -- Offer the ability to remove either of
+ the two types of Content-Transfer-
+ Encoding defined in this document
+ and put the resulting information
+ in a user file.
+
+ 5. Upon encountering any unrecognized Content-
+ Type, an implementation must treat it as if it had
+ a Content-Type of "application/octet-stream" with
+ no parameter sub-arguments. How such data are
+ handled is up to an implementation, but likely
+ options for handling such unrecognized data
+ include offering the user to write it into a file
+ (decoded from its mail transport format) or
+ offering the user to name a program to which the
+ decoded data should be passed as input.
+ Unrecognized predefined types, which in a MIME-
+ conformant mailer might still include audio,
+ image, or video, should also be treated in this
+ way.
+
+ A user agent that meets the above conditions is said to be
+ MIME-conformant. The meaning of this phrase is that it is
+ assumed to be "safe" to send virtually any kind of
+ properly-marked data to users of such mail systems, because
+ such systems will at least be able to treat the data as
+ undifferentiated binary, and will not simply splash it onto
+ the screen of unsuspecting users. There is another sense
+ in which it is always "safe" to send data in a format that
+ is MIME-conformant, which is that such data will not break
+ or be broken by any known systems that are conformant with
+ RFC 821 and RFC 822. User agents that are MIME-conformant
+
+
+
+ Borenstein & Freed [Page 57]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ have the additional guarantee that the user will not be
+ shown data that were never intended to be viewed as text.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 58]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ Appendix B -- General Guidelines For Sending Email Data
+
+ Internet email is not a perfect, homogeneous system. Mail
+ may become corrupted at several stages in its travel to a
+ final destination. Specifically, email sent throughout the
+ Internet may travel across many networking technologies.
+ Many networking and mail technologies do not support the
+ full functionality possible in the SMTP transport
+ environment. Mail traversing these systems is likely to be
+ modified in such a way that it can be transported.
+
+ There exist many widely-deployed non-conformant MTAs in the
+ Internet. These MTAs, speaking the SMTP protocol, alter
+ messages on the fly to take advantage of the internal data
+ structure of the hosts they are implemented on, or are just
+ plain broken.
+
+ The following guidelines may be useful to anyone devising a
+ data format (Content-Type) that will survive the widest
+ range of networking technologies and known broken MTAs
+ unscathed. Note that anything encoded in the base64
+ encoding will satisfy these rules, but that some well-known
+ mechanisms, notably the UNIX uuencode facility, will not.
+ Note also that anything encoded in the Quoted-Printable
+ encoding will survive most gateways intact, but possibly not
+ some gateways to systems that use the EBCDIC character set.
+
+ (1) Under some circumstances the encoding used for
+ data may change as part of normal gateway or user
+ agent operation. In particular, conversion from
+ base64 to quoted-printable and vice versa may be
+ necessary. This may result in the confusion of
+ CRLF sequences with line breaks in text body
+ parts. As such, the persistence of CRLF as
+ something other than a line break should not be
+ relied on.
+
+ (2) Many systems may elect to represent and store
+ text data using local newline conventions. Local
+ newline conventions may not match the RFC822 CRLF
+ convention -- systems are known that use plain CR,
+ plain LF, CRLF, or counted records. The result is
+ that isolated CR and LF characters are not well
+ tolerated in general; they may be lost or
+ converted to delimiters on some systems, and hence
+ should not be relied on.
+
+ (3) TAB (HT) characters may be misinterpreted or
+ may be automatically converted to variable numbers
+ of spaces. This is unavoidable in some
+ environments, notably those not based on the ASCII
+ character set. Such conversion is STRONGLY
+ DISCOURAGED, but it may occur, and mail formats
+ should not rely on the persistence of TAB (HT)
+
+
+
+ Borenstein & Freed [Page 59]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ characters.
+
+ (4) Lines longer than 76 characters may be wrapped
+ or truncated in some environments. Line wrapping
+ and line truncation are STRONGLY DISCOURAGED, but
+ unavoidable in some cases. Applications which
+ require long lines should somehow differentiate
+ between soft and hard line breaks. (A simple way
+ to do this is to use the quoted-printable
+ encoding.)
+
+ (5) Trailing "white space" characters (SPACE, TAB
+ (HT)) on a line may be discarded by some transport
+ agents, while other transport agents may pad lines
+ with these characters so that all lines in a mail
+ file are of equal length. The persistence of
+ trailing white space, therefore, should not be
+ relied on.
+
+ (6) Many mail domains use variations on the ASCII
+ character set, or use character sets such as
+ EBCDIC which contain most but not all of the US-
+ ASCII characters. The correct translation of
+ characters not in the "invariant" set cannot be
+ depended on across character converting gateways.
+ For example, this situation is a problem when
+ sending uuencoded information across BITNET, an
+ EBCDIC system. Similar problems can occur without
+ crossing a gateway, since many Internet hosts use
+ character sets other than ASCII internally. The
+ definition of Printable Strings in X.400 adds
+ further restrictions in certain special cases. In
+ particular, the only characters that are known to
+ be consistent across all gateways are the 73
+ characters that correspond to the upper and lower
+ case letters A-Z and a-z, the 10 digits 0-9, and
+ the following eleven special characters:
+
+ "'" (ASCII code 39)
+ "(" (ASCII code 40)
+ ")" (ASCII code 41)
+ "+" (ASCII code 43)
+ "," (ASCII code 44)
+ "-" (ASCII code 45)
+ "." (ASCII code 46)
+ "/" (ASCII code 47)
+ ":" (ASCII code 58)
+ "=" (ASCII code 61)
+ "?" (ASCII code 63)
+
+ A maximally portable mail representation, such as
+ the base64 encoding, will confine itself to
+ relatively short lines of text in which the only
+ meaningful characters are taken from this set of
+
+
+
+ Borenstein & Freed [Page 60]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ 73 characters.
+
+ Please note that the above list is NOT a list of recommended
+ practices for MTAs. RFC 821 MTAs are prohibited from
+ altering the character of white space or wrapping long
+ lines. These BAD and illegal practices are known to occur
+ on established networks, and implementions should be robust
+ in dealing with the bad effects they can cause.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 61]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ Appendix C -- A Complex Multipart Example
+
+ What follows is the outline of a complex multipart message.
+ This message has five parts to be displayed serially: two
+ introductory plain text parts, an embedded multipart
+ message, a richtext part, and a closing encapsulated text
+ message in a non-ASCII character set. The embedded
+ multipart message has two parts to be displayed in parallel,
+ a picture and an audio fragment.
+
+ MIME-Version: 1.0
+ From: Nathaniel Borenstein <nsb bellcore com>
+ Subject: A multipart example
+ Content-Type: multipart/mixed;
+ boundary=unique-boundary-1
+
+ This is the preamble area of a multipart message.
+ Mail readers that understand multipart format
+ should ignore this preamble.
+ If you are reading this text, you might want to
+ consider changing to a mail reader that understands
+ how to properly display multipart messages.
+ --unique-boundary-1
+
+ ...Some text appears here...
+ [Note that the preceding blank line means
+ no header fields were given and this is text,
+ with charset US ASCII. It could have been
+ done with explicit typing as in the next part.]
+
+ --unique-boundary-1
+ Content-type: text/plain; charset=US-ASCII
+
+ This could have been part of the previous part,
+ but illustrates explicit versus implicit
+ typing of body parts.
+
+ --unique-boundary-1
+ Content-Type: multipart/parallel;
+ boundary=unique-boundary-2
+
+
+ --unique-boundary-2
+ Content-Type: audio/basic
+ Content-Transfer-Encoding: base64
+
+ ... base64-encoded 8000 Hz single-channel
+ u-law-format audio data goes here....
+
+ --unique-boundary-2
+ Content-Type: image/gif
+ Content-Transfer-Encoding: Base64
+
+
+
+
+
+ Borenstein & Freed [Page 62]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ ... base64-encoded image data goes here....
+
+ --unique-boundary-2--
+
+ --unique-boundary-1
+ Content-type: text/richtext
+
+ This is <bold><italic>richtext.</italic></bold>
+ <nl><nl>Isn't it
+ <bigger><bigger>cool?</bigger></bigger>
+
+ --unique-boundary-1
+ Content-Type: message/rfc822
+
+ From: (name in US-ASCII)
+ Subject: (subject in US-ASCII)
+ Content-Type: Text/plain; charset=ISO-8859-1
+ Content-Transfer-Encoding: Quoted-printable
+
+ ... Additional text in ISO-8859-1 goes here ...
+
+ --unique-boundary-1--
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 63]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ Appendix D -- A Simple Richtext-to-Text Translator in C
+
+ One of the major goals in the design of the richtext subtype
+ of the text Content-Type is to make formatted text so simple
+ that even text-only mailers will implement richtext-to-
+ plain-text translators, thus increasing the likelihood that
+ multifont text will become "safe" to use very widely. To
+ demonstrate this simplicity, what follows is an extremely
+ simple 44-line C program that converts richtext input into
+ plain text output:
+
+ #include <stdio.h>
+ #include <ctype.h>
+ main() {
+ int c, i;
+ char token[50];
+
+ while((c = getc(stdin)) != EOF) {
+ if (c == '<') {
+ for (i=0; (i<49 && (c = getc(stdin)) != '>'
+ && c != EOF); ++i) {
+ token[i] = isupper(c) ? tolower(c) : c;
+ }
+ if (c == EOF) break;
+ if (c != '>') while ((c = getc(stdin)) !=
+ '>'
+ && c != EOF) {;}
+ if (c == EOF) break;
+ token[i] = '\0';
+ if (!strcmp(token, "lt")) {
+ putc('<', stdout);
+ } else if (!strcmp(token, "nl")) {
+ putc('\n', stdout);
+ } else if (!strcmp(token, "/paragraph")) {
+ fputs("\n\n", stdout);
+ } else if (!strcmp(token, "comment")) {
+ int commct=1;
+ while (commct > 0) {
+ while ((c = getc(stdin)) != '<'
+ && c != EOF) ;
+ if (c == EOF) break;
+ for (i=0; (c = getc(stdin)) != '>'
+ && c != EOF; ++i) {
+ token[i] = isupper(c) ?
+ tolower(c) : c;
+ }
+ if (c== EOF) break;
+ token[i] = NULL;
+ if (!strcmp(token, "/comment")) --
+ commct;
+ if (!strcmp(token, "comment"))
+ ++commct;
+
+
+
+
+
+ Borenstein & Freed [Page 64]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ }
+ } /* Ignore all other tokens */
+ } else if (c != '\n') putc(c, stdout);
+ }
+ putc('\n', stdout); /* for good measure */
+ }
+ It should be noted that one can do considerably better than
+ this in displaying richtext data on a dumb terminal. In
+ particular, one can replace font information such as "bold"
+ with textual emphasis (like *this* or _T_H_I_S_). One can
+ also properly handle the richtext formatting commands
+ regarding indentation, justification, and others. However,
+ the above program is all that is necessary in order to
+ present richtext on a dumb terminal.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 65]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ Appendix E -- Collected Grammar
+
+ This appendix contains the complete BNF grammar for all the
+ syntax specified by this document.
+
+ By itself, however, this grammar is incomplete. It refers
+ to several entities that are defined by RFC 822. Rather
+ than reproduce those definitions here, and risk
+ unintentional differences between the two, this document
+ simply refers the reader to RFC 822 for the remaining
+ definitions. Wherever a term is undefined, it refers to the
+ RFC 822 definition.
+
+ attribute := token
+
+ body-part = <"message" as defined in RFC 822,
+ with all header fields optional, and with the
+ specified delimiter not occurring anywhere in
+ the message body, either on a line by itself
+ or as a substring anywhere.>
+
+ boundary := 0*69<bchars> bcharsnospace
+
+ bchars := bcharsnospace / " "
+
+ bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" /
+ "_"
+ / "," / "-" / "." / "/" / ":" / "=" / "?"
+
+ close-delimiter := delimiter "--"
+
+ Content-Description := *text
+
+ Content-ID := msg-id
+
+ Content-Transfer-Encoding := "BASE64" / "QUOTED-
+ PRINTABLE" /
+ "8BIT" / "7BIT" /
+ "BINARY" / x-token
+
+ Content-Type := type "/" subtype *[";" parameter]
+
+ delimiter := CRLF "--" boundary ; taken from Content-Type
+ field.
+ ; when content-type is
+ multipart
+ ; There should be no space
+ ; between "--" and boundary.
+
+ encapsulation := delimiter CRLF body-part
+
+ epilogue := *text ; to be ignored upon
+ receipt.
+
+
+
+
+ Borenstein & Freed [Page 66]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ MIME-Version := 1*text
+
+ multipart-body := preamble 1*encapsulation close-delimiter
+ epilogue
+
+ parameter := attribute "=" value
+
+ preamble := *text ; to be ignored upon
+ receipt.
+
+ subtype := token
+
+ token := 1*<any CHAR except SPACE, CTLs, or tspecials>
+
+ tspecials := "(" / ")" / "<" / ">" / "@" ; Must be in
+ / "," / ";" / ":" / "\" / <"> ; quoted-string,
+ / "/" / "[" / "]" / "?" / "." ; to use within
+ / "=" ; parameter values
+
+
+ type := "application" / "audio" ; case-
+ insensitive
+ / "image" / "message"
+ / "multipart" / "text"
+ / "video" / x-token
+
+ value := token / quoted-string
+
+ x-token := <The two characters "X-" followed, with no
+ intervening white space, by any token>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 67]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ Appendix F -- IANA Registration Procedures
+
+ MIME has been carefully designed to have extensible
+ mechanisms, and it is expected that the set of content-
+ type/subtype pairs and their associated parameters will grow
+ significantly with time. Several other MIME fields, notably
+ character set names, access-type parameters for the
+ message/external-body type, conversions parameters for the
+ application type, and possibly even Content-Transfer-
+ Encoding values, are likely to have new values defined over
+ time. In order to ensure that the set of such values is
+ developed in an orderly, well-specified, and public manner,
+ MIME defines a registration process which uses the Internet
+ Assigned Numbers Authority (IANA) as a central registry for
+ such values.
+
+ In general, parameters in the content-type header field are
+ used to convey supplemental information for various content
+ types, and their use is defined when the content-type and
+ subtype are defined. New parameters should not be defined
+ as a way to introduce new functionality.
+
+ In order to simplify and standardize the registration
+ process, this appendix gives templates for the registration
+ of new values with IANA. Each of these is given in the form
+ of an email message template, to be filled in by the
+ registering party.
+
+ F.1 Registration of New Content-type/subtype Values
+
+ Note that MIME is generally expected to be extended by
+ subtypes. If a new fundamental top-level type is needed,
+ its specification should be published as an RFC or
+ submitted in a form suitable to become an RFC, and be
+ subject to the Internet standards process.
+
+ To: IANA isi edu
+ Subject: Registration of new MIME content-type/subtype
+
+ MIME type name:
+
+ (If the above is not an existing top-level MIME type,
+ please explain why an existing type cannot be used.)
+
+ MIME subtype name:
+
+ Required parameters:
+
+ Optional parameters:
+
+ Encoding considerations:
+
+ Security considerations:
+
+
+
+
+ Borenstein & Freed [Page 68]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ Published specification:
+
+ (The published specification must be an Internet RFC or
+ RFC-to-be if a new top-level type is being defined, and
+ must be a publicly available specification in any
+ case.)
+
+ Person & email address to contact for further
+ information:
+ F.2 Registration of New Character Set Values
+
+ To: IANA isi edu
+ Subject: Registration of new MIME character set value
+
+ MIME character set name:
+
+ Published specification:
+
+ (The published specification must be an Internet RFC or
+ RFC-to-be or an international standard.)
+
+ Person & email address to contact for further
+ information:
+
+ F.3 Registration of New Access-type Values for
+ Message/external-body
+
+ To: IANA isi edu
+ Subject: Registration of new MIME Access-type for
+ Message/external-body content-type
+
+ MIME access-type name:
+
+ Required parameters:
+
+ Optional parameters:
+
+ Published specification:
+
+ (The published specification must be an Internet RFC or
+ RFC-to-be.)
+
+ Person & email address to contact for further
+ information:
+
+
+ F.4 Registration of New Conversions Values for Application
+
+ To: IANA isi edu
+ Subject: Registration of new MIME Conversions value
+ for Application content-type
+
+ MIME Conversions name:
+
+
+
+
+ Borenstein & Freed [Page 69]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ Published specification:
+
+ (The published specification must be an Internet RFC or
+ RFC-to-be.)
+
+ Person & email address to contact for further
+ information:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 70]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ Appendix G -- Summary of the Seven Content-types
+
+ Content-type: text
+
+ Subtypes defined by this document: plain, richtext
+
+ Important Parameters: charset
+
+ Encoding notes: quoted-printable generally preferred if an
+ encoding is needed and the character set is mostly an
+ ASCII superset.
+
+ Security considerations: Rich text formats such as TeX and
+ Troff often contain mechanisms for executing arbitrary
+ commands or file system operations, and should not be
+ used automatically unless these security problems have
+ been addressed. Even plain text may contain control
+ characters that can be used to exploit the capabilities
+ of "intelligent" terminals and cause security
+ violations. User interfaces designed to run on such
+ terminals should be aware of and try to prevent such
+ problems.
+ ________________________________________________________________
+
+ Content-type: multipart
+
+ Subtypes defined by this document: mixed, alternative,
+ digest, parallel.
+
+ Important Parameters: boundary
+
+ Encoding notes: No content-transfer-encoding is permitted.
+
+ ________________________________________________________________
+
+ Content-type: message
+
+ Subtypes defined by this document: rfc822, partial,
+ external-body
+
+ Important Parameters: id, number, total
+
+ Encoding notes: No content-transfer-encoding is permitted.
+
+ ________________________________________________________________
+
+ Content-type: application
+
+ Subtypes defined by this document: octet-stream,
+ postscript, oda
+
+ Important Parameters: profile
+
+
+
+
+
+ Borenstein & Freed [Page 71]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ Encoding notes: base64 generally preferred for octet-stream
+ or other unreadable subtypes.
+
+ Security considerations: This type is intended for the
+ transmission of data to be interpreted by locally-installed
+ programs. If used, for example, to transmit executable
+ binary programs or programs in general-purpose interpreted
+ languages, such as LISP programs or shell scripts, severe
+ security problems could result. In general, authors of
+ mail-reading agents are cautioned against giving their
+ systems the power to execute mail-based application data
+ without carefully considering the security implications.
+ While it is certainly possible to define safe application
+ formats and even safe interpreters for unsafe formats, each
+ interpreter should be evaluated separately for possible
+ security problems.
+ ________________________________________________________________
+
+ Content-type: image
+
+ Subtypes defined by this document: jpeg, gif
+
+ Important Parameters: none
+
+ Encoding notes: base64 generally preferred
+
+ ________________________________________________________________
+
+ Content-type: audio
+
+ Subtypes defined by this document: basic
+
+ Important Parameters: none
+
+ Encoding notes: base64 generally preferred
+
+ ________________________________________________________________
+
+ Content-type: video
+
+ Subtypes defined by this document: mpeg
+
+ Important Parameters: none
+
+ Encoding notes: base64 generally preferred
+
+
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 72]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ Appendix H -- Canonical Encoding Model
+
+
+
+ There was some confusion, in earlier drafts of this memo,
+ regarding the model for when email data was to be converted
+ to canonical form and encoded, and in particular how this
+ process would affect the treatment of CRLFs, given that the
+ representation of newlines varies greatly from system to
+ system. For this reason, a canonical model for encoding is
+ presented below.
+
+ The process of composing a MIME message part can be modelled
+ as being done in a number of steps. Note that these steps
+ are roughly similar to those steps used in RFC1113:
+
+ Step 1. Creation of local form.
+
+ The body part to be transmitted is created in the system's
+ native format. The native character set is used, and where
+ appropriate local end of line conventions are used as well.
+ The may be a UNIX-style text file, or a Sun raster image, or
+ a VMS indexed file, or audio data in a system-dependent
+ format stored only in memory, or anything else that
+ corresponds to the local model for the representation of
+ some form of information.
+
+ Step 2. Conversion to canonical form.
+
+ The entire body part, including "out-of-band" information
+ such as record lengths and possibly file attribute
+ information, is converted to a universal canonical form.
+ The specific content type of the body part as well as its
+ associated attributes dictate the nature of the canonical
+ form that is used. Conversion to the proper canonical form
+ may involve character set conversion, transformation of
+ audio data, compression, or various other operations
+ specific to the various content types.
+
+ For example, in the case of text/plain data, the text must
+ be converted to a supported character set and lines must be
+ delimited with CRLF delimiters in accordance with RFC822.
+ Note that the restriction on line lengths implied by RFC822
+ is eliminated if the next step employs either quoted-
+ printable or base64 encoding.
+
+ Step 3. Apply transfer encoding.
+
+ A Content-Transfer-Encoding appropriate for this body part
+ is applied. Note that there is no fixed relationship
+ between the content type and the transfer encoding. In
+ particular, it may be appropriate to base the choice of
+ base64 or quoted-printable on character frequency counts
+ which are specific to a given instance of body part.
+
+
+
+ Borenstein & Freed [Page 73]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ Step 4. Insertion into message.
+
+ The encoded object is inserted into a MIME message with
+ appropriate body part headers and boundary markers.
+
+ It is vital to note that these steps are only a model; they
+ are specifically NOT a blueprint for how an actual system
+ would be built. In particular, the model fails to account
+ for two common designs:
+
+ 1. In many cases the conversion to a canonical
+ form prior to encoding will be subsumed into the
+ encoder itself, which understands local formats
+ directly. For example, the local newline
+ convention for text bodyparts might be carried
+ through to the encoder itself along with knowledge
+ of what that format is.
+
+ 2. The output of the encoders may have to pass
+ through one or more additional steps prior to
+ being transmitted as a message. As such, the
+ output of the encoder may not be compliant with
+ the formats specified by RFC822. In particular,
+ once again it may be appropriate for the
+ converter's output to be expressed using local
+ newline conventions rather than using the standard
+ RFC822 CRLF delimiters.
+
+ Other implementation variations are conceivable as well.
+ The only important aspect of this discussion is that the
+ resulting messages are consistent with those produced by the
+ model described here.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 74]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ References
+
+ [US-ASCII] Coded Character Set--7-Bit American Standard Code
+ for Information Interchange, ANSI X3.4-1986.
+
+ [ATK] Borenstein, Nathaniel S., Multimedia Applications
+ Development with the Andrew Toolkit, Prentice-Hall, 1990.
+
+ [GIF] Graphics Interchange Format (Version 89a), Compuserve,
+ Inc., Columbus, Ohio, 1990.
+
+ [ISO-2022] International Standard--Information Processing--
+ ISO 7-bit and 8-bit coded character sets--Code extension
+ techniques, ISO 2022:1986.
+
+ [ISO-8859] Information Processing -- 8-bit Single-Byte Coded
+ Graphic Character Sets -- Part 1: Latin Alphabet No. 1, ISO
+ 8859-1:1987. Part 2: Latin alphabet No. 2, ISO 8859-2,
+ 1987. Part 3: Latin alphabet No. 3, ISO 8859-3, 1988. Part
+ 4: Latin alphabet No. 4, ISO 8859-4, 1988. Part 5:
+ Latin/Cyrillic alphabet, ISO 8859-5, 1988. Part 6:
+ Latin/Arabic alphabet, ISO 8859-6, 1987. Part 7:
+ Latin/Greek alphabet, ISO 8859-7, 1987. Part 8:
+ Latin/Hebrew alphabet, ISO 8859-8, 1988. Part 9: Latin
+ alphabet No. 5, ISO 8859-9, 1990.
+
+ [ISO-646] International Standard--Information Processing--
+ ISO 7-bit coded character set for information interchange,
+ ISO 646:1983.
+
+ [MPEG] Video Coding Draft Standard ISO 11172 CD, ISO
+ IEC/TJC1/SC2/WG11 (Motion Picture Experts Group), May, 1991.
+
+ [ODA] ISO 8613; Information Processing: Text and Office
+ System; Office Document Architecture (ODA) and Interchange
+ Format (ODIF), Part 1-8, 1989.
+
+ [PCM] CCITT, Fascicle III.4 - Recommendation G.711, Geneva,
+ 1972, "Pulse Code Modulation (PCM) of Voice Frequencies".
+
+ [POSTSCRIPT] Adobe Systems, Inc., PostScript Language
+ Reference Manual, Addison-Wesley, 1985.
+
+ [X400] Schicker, Pietro, "Message Handling Systems, X.400",
+ Message Handling Systems and Distributed Applications, E.
+ Stefferud, O-j. Jacobsen, and P. Schicker, eds., North-
+ Holland, 1989, pp. 3-41.
+
+ [RFC-783] Sollins, K.R. TFTP Protocol (revision 2). June,
+ 1981, MIT, RFC-783.
+
+ [RFC-821] Postel, J.B. Simple Mail Transfer Protocol.
+ August, 1982, USC/Information Sciences Institute, RFC-821.
+
+
+
+
+ Borenstein & Freed [Page 75]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ [RFC-822] Crocker, D. Standard for the format of ARPA
+ Internet text messages. August, 1982, UDEL, RFC-822.
+
+ [RFC-934] Rose, M.T.; Stefferud, E.A. Proposed standard
+ for message encapsulation. January, 1985, Delaware
+ and NMA, RFC-934.
+
+ [RFC-959] Postel, J.B.; Reynolds, J.K. File Transfer
+ Protocol. October, 1985, USC/Information Sciences
+ Institute, RFC-959.
+
+ [RFC-1049] Sirbu, M.A. Content-Type header field for
+ Internet messages. March, 1988, CMU, RFC-1049.
+
+ [RFC-1113] Linn, J. Privacy enhancement for Internet
+ electronic mail: Part I - message encipherment and
+ authentication procedures. August, 1989, IAB Privacy Task
+ Force, RFC-1113.
+
+ [RFC-1154] Robinson, D.; Ullmann, R. Encoding header field
+ for Internet messages. April, 1990, Prime Computer,
+ Inc., RFC-1154.
+
+ [RFC-1342] Moore, Keith, Representation of Non-Ascii Text in
+ Internet Message Headers. June, 1992, University of
+ Tennessee, RFC-1342.
+
+ Security Considerations
+
+ Security issues are discussed in Section 7.4.2 and in
+ Appendix G. Implementors should pay special attention to
+ the security implications of any mail content-types that can
+ cause the remote execution of any actions in the recipient's
+ environment. In such cases, the discussion of the
+ applicaton/postscript content-type in Section 7.4.2 may
+ serve as a model for considering other content-types with
+ remote execution capabilities.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 76]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+ Authors' Addresses
+
+ For more information, the authors of this document may be
+ contacted via Internet mail:
+
+ Nathaniel S. Borenstein
+ MRE 2D-296, Bellcore
+ 445 South St.
+ Morristown, NJ 07962-1910
+
+ Phone: +1 201 829 4270
+ Fax: +1 201 829 7019
+ Email: nsb bellcore com
+
+
+ Ned Freed
+ Innosoft International, Inc.
+ 250 West First Street
+ Suite 240
+ Claremont, CA 91711
+
+ Phone: +1 714 624 7907
+ Fax: +1 714 621 5319
+ Email: ned innosoft com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page 77]
+
+
+
+
+ RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
+
+
+
+
+
+ THIS PAGE INTENTIONALLY LEFT BLANK.
+
+ Please discard this page and place the following table of
+ contents after the title page.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page i]
+
+
+
+
+
+
+
+
+ Table of Contents
+
+
+ 1 Introduction....................................... 1
+ 2 Notations, Conventions, and Generic BNF Grammar.... 3
+ 3 The MIME-Version Header Field...................... 5
+ 4 The Content-Type Header Field...................... 6
+ 5 The Content-Transfer-Encoding Header Field......... 10
+ 5.1 Quoted-Printable Content-Transfer-Encoding......... 14
+ 5.2 Base64 Content-Transfer-Encoding................... 17
+ 6 Additional Optional Content- Header Fields......... 19
+ 6.1 Optional Content-ID Header Field................... 19
+ 6.2 Optional Content-Description Header Field.......... 19
+ 7 The Predefined Content-Type Values................. 20
+ 7.1 The Text Content-Type.............................. 20
+ 7.1.1 The charset parameter.............................. 20
+ 7.1.2 The Text/plain subtype............................. 23
+ 7.1.3 The Text/richtext subtype.......................... 23
+ 7.2 The Multipart Content-Type......................... 29
+ 7.2.1 Multipart: The common syntax...................... 30
+ 7.2.2 The Multipart/mixed (primary) subtype.............. 34
+ 7.2.3 The Multipart/alternative subtype.................. 34
+ 7.2.4 The Multipart/digest subtype....................... 36
+ 7.2.5 The Multipart/parallel subtype..................... 36
+ 7.3 The Message Content-Type........................... 37
+ 7.3.1 The Message/rfc822 (primary) subtype............... 37
+ 7.3.2 The Message/Partial subtype........................ 37
+ 7.3.3 The Message/External-Body subtype.................. 40
+ 7.4 The Application Content-Type....................... 46
+ 7.4.1 The Application/Octet-Stream (primary) subtype..... 46
+ 7.4.2 The Application/PostScript subtype................. 47
+ 7.4.3 The Application/ODA subtype........................ 50
+ 7.5 The Image Content-Type............................. 51
+ 7.6 The Audio Content-Type............................. 51
+ 7.7 The Video Content-Type............................. 51
+ 7.8 Experimental Content-Type Values................... 51
+ Summary............................................ 53
+ Acknowledgements................................... 54
+ Appendix A -- Minimal MIME-Conformance............. 56
+ Appendix B -- General Guidelines For Sending Email Data59
+ Appendix C -- A Complex Multipart Example.......... 62
+ Appendix D -- A Simple Richtext-to-Text Translator in C64
+ Appendix E -- Collected Grammar.................... 66
+ Appendix F -- IANA Registration Procedures......... 68
+ F.1 Registration of New Content-type/subtype Values..68
+ F.2 Registration of New Character Set Values...... 69
+ F.3 Registration of New Access-type Values for Message/external-body69
+ F.4 Registration of New Conversions Values for Application69
+ Appendix G -- Summary of the Seven Content-types... 71
+ Appendix H -- Canonical Encoding Model............. 73
+ References......................................... 75
+ Security Considerations............................ 76
+ Authors' Addresses................................. 77
+
+
+
+ Borenstein & Freed [Page ii]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Borenstein & Freed [Page iii]
+
diff --git a/rfc/rfc1342.txt b/rfc/rfc1342.txt
new file mode 100644
index 0000000..5315aff
--- /dev/null
+++ b/rfc/rfc1342.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group K. Moore
+Request for Comments: 1342 University of Tennessee
+ June 1992
+
+
+ Representation of Non-ASCII Text in Internet Message Headers
+
+Status of this Memo
+
+ This RFC specifies an IAB standards track protocol for the Internet
+ community, and requests discussion and suggestions for improvements.
+ Please refer to the current edition of the "IAB Official Protocol
+ Standards" for the standardization state and status of this protocol.
+ Distribution of this memo is unlimited.
+
+Abstract
+
+ This memo describes an extension to the message format defined in [1]
+ (known to the IETF Mail Extensions Working Group as "RFC 1341"), to
+ allow the representation of character sets other than ASCII in RFC
+ 822 message headers. The extensions described were designed to be
+ highly compatible with existing Internet mail handling software, and
+ to be easily implemented in mail readers that support RFC 1341.
+
+Introduction
+
+ RFC 1341 describes a mechanism for denoting textual body parts which
+ are coded in various character sets, as well as methods for encoding
+ such body parts as sequences of printable ASCII characters. This
+ memo describes similar techniques to allow the encoding of non-ASCII
+ text in various portions of a RFC 822 [2] message header, in a manner
+ which is unlikely to confuse existing message handling software.
+
+ Like the encoding techniques described in RFC 1341, the techniques
+ outlined here were designed to allow the use of non-ASCII characters
+ in message headers in a way which is unlikely to be disturbed by the
+ quirks of existing Internet mail handling programs. In particular,
+ some mail relaying programs are known to (a) delete some message
+ header fields while retaining others, (b) rearrange the order of
+ addresses in To or Cc fields, (c) rearrange the (vertical) order of
+ header fields, and/or (d) "wrap" message headers at different places
+ than those in the original message. In addition, some mail reading
+ programs are known to have difficulty correctly parsing message
+ headers which, while legal according to RFC 822, make use of
+ backslash-quoting to "hide" special characters such as "<", ",", or
+ or which exploit other infrequently-used features of that
+ specification.
+
+
+
+
+Moore [Page 1]
+
+RFC 1342 Non-ASCII Mail Headers June 1992
+
+
+ While it is unfortunate that these programs do not correctly
+ interpret RFC 822 headers, to "break" these programs would cause
+ severe operational problems for the Internet mail system. The
+ extensions described in this memo therefore do not rely on little-
+ used features of RFC 822. Instead, certain sequences of "ordinary"
+ printable ASCII characters (which are assumed to be unlikely to
+ otherwise appear in message headers) are reserved for use as encoded
+ data. The characters used in these encodings are restricted to those
+ which do not have special meanings in the context in which the
+ encoded text appears.
+
+Encodings
+
+ An "encoded-word" is a sequence of printable ASCII characters that
+ begins with "=?", ends with "?=", and has two "?"s in between. It
+ specifies a character set and an encoding method, and also includes
+ the original text encoded as ASCII characters, according to the rules
+ for that encoding method.
+
+ A mail composer that implements this specification will provide a
+ means of inputing non-ASCII text in header fields, but will translate
+ these fields (or appropriate portions of these fields) into encoded-
+ words before inserting them into the message header.
+
+ A mail reader that implements this specification will recognize
+ encoded-words when they appear in certain portions of the message
+ header. Instead of displaying the encoded-word "as is", it will
+ reverse the encoding and display the original text in the designated
+ character set.
+
+ An "encoded-word" is more precisely defined by the following EBNF
+ grammar, using the notation of RFC 822:
+
+ encoded-word = "=" "?" charset "?" encoding "?" encoded-text "?" "="
+
+ charset = token ; legal charsets defined by RFC 1341
+
+ encoding = token ; Either "B" or "Q"
+
+ token = 1*<Any CHAR except SPACE, CTLs, and tspecials>
+
+ tspecials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" /
+ <"> / "/" / "[" / "]" / "?" / "." / "="
+
+ encoded-text = 1*<Any printable ASCII character other than "?" or
+ ; SPACE> (but see "Use of encoded-words in message
+ ; headers", below)
+
+
+
+
+Moore [Page 2]
+
+RFC 1342 Non-ASCII Mail Headers June 1992
+
+
+ An encoded-word may not be more than 75 characters long, including
+ charset, encoding, encoded-text, and delimiters. If it is desirable
+ to encode more text than will fit in an encoded-word of 75
+ characters, multiple encoded-words (separated by SPACE or newline)
+ may be used. Message header lines that contain one or more encoded-
+ words should be no more than 76 characters long. NOTE: These
+ restrictions are included not only to ease interoperbility through
+ internetwork mail gateways, but also to impose a limit on the amount
+ of lookahead a header parser must employ (while looking for a final
+ ?= delimiter) before it can decide whether a token is an encoded-word
+ or something else.
+
+ Initially, the legal values for "encoding" are "Q" and "B". These
+ encodings are described below. The "Q" encoding is recommended for
+ use with Latin character sets, and the "B" encoding for all others.
+ Nevertheless, a mail reader which claims to recognize encoded-words
+ MUST be able to accept either encoding for any character set which it
+ supports.
+
+ Only a subset of the printable ASCII characters may be used in
+ encoded-text. The SPACE character is not allowed, so that the
+ beginning and end of an encoded-word are obvious. The "?" character
+ is used within an encoded-word to separate the various portions of
+ the encoded-word from one another, and thus cannot appear in the
+ encoded-text portion. Other characters are also illegal in certain
+ contexts. For example, an encoded-word in a "phrase" preceeding an
+ address in a From header field may not contain any of the "specials"
+ defined in RFC 822. Finally, certain other characters are disallowed
+ in some contexts, to ensure reliability for messages that pass
+ through internetwork mail gateways.
+
+ The "B" encoding automatically meets these requirements. The "Q"
+ encoding allows a wide range of printable characters to be used in
+ non-critical locations in the message header (e.g., Subject), with
+ fewer characters available for use in other locations.
+
+The "B" encoding
+
+ The "B" encoding is identical to the "BASE64" encoding defined by RFC
+ 1341.
+
+The "Q" encoding
+
+ The "Q" encoding is similar to the "Quoted-Printable" content-
+ transfer-encoding defined in RFC 1341. It is designed to allow text
+ containing mostly ASCII characters to be decipherable on an ASCII
+ terminal without decoding.
+
+
+
+
+Moore [Page 3]
+
+RFC 1342 Non-ASCII Mail Headers June 1992
+
+
+ 1. Any 8-bit value may be represented by a "=" followed by two
+ hexadecimal digits. For example, if the character set in use
+ were ISO-8859-1, the "=" character would thus be encoded as
+ "=3D", and a SPACE by "=20".
+
+ 2. The 8-bit hexadecimal value 20 (e.g., IS0-8859-1 SPACE) may be
+ represented as "_" (underscore, ASCII 95.). (This character may
+ not pass through some internetwork mail gateways, but its use
+ will greatly enhance readability of "Q" encoded data with mail
+ readers that do not support this encoding.) Note that the "_"
+ always represents hexadecimal 20, even if the SPACE character
+ occupies a different code position in the character set in use.
+
+ 3. 8-bit values which correspond to printable ASCII characters other
+ than "=", "?", "_" (underscore), and SPACE may be represented as
+ those characters. (But see "Use of encoded-words in message
+ headers", below).
+
+Character sets
+
+ In an encoded-word, the character set associated with the unencoded
+ text is specified by a charset. A charset can be any of the
+ character set names allowed in an RFC 1341 "charset" parameter of a
+ "text/plain" body part. (See section 7.1.1 of RFC 1341 for a list of
+ valid charset parameters).
+
+ When there is a possibility of using more than one character set to
+ represent the text in an encoded-word, and in the absence of private
+ agreements between sender and recipients of a message, it is
+ recommended that members of the ISO-8859-* series be used in
+ preference to other character sets. Among the various ISO-8859-*
+ character sets, the lowest-numbered set which contains all of the
+ required characters should be used.
+
+Use of encoded-words in message headers
+
+ A sequence of one or more encoded-words is used to represent non-
+ ASCII textual data within a header field. An encoded-word must be
+ separated from an adjacent encoded-word, "word", "text", "ctext", or
+ "special" by a linear white-space character or a newline. When
+ displaying a particular header field" (in the RFC 822 sense)
+ containing one or more encoded-words, an unencoded SPACE character
+ that immediately follows the encoded-word is not displayed. A
+ newline that immediately follows an encoded-word is not displayed
+ unless the encoded-word is the last token in that "field". (This is
+ to allow the use of multiple encoded-words to represent long strings
+ of unencoded text, without having to separate encoded-words where
+ spaces occur in the unencoded text.)
+
+
+
+Moore [Page 4]
+
+RFC 1342 Non-ASCII Mail Headers June 1992
+
+
+ An encoded-word may appear in a message header or body part header
+ according to the following rules:
+
+- An encoded-word may replace a "text" token (as defined by RFC 822) in:
+ (1) a Subject or Comments header field, (2) any extension message
+ header field, (3) any user-defined message header field, or (4) any
+ RFC 1341 body part header field (such as Content-Description) for
+ which the field body contains only "text"s.
+
+- An encoded-word may appear within a comment delimited by "(" and ")",
+ i.e., wherever a "ctext" is allowed. More precisely, the RFC 822 EBNF
+ definition for "comment" is amended as follows:
+
+ comment = "(" *(ctext / quoted-pair / comment / encoded-word) ")"
+
+ A "Q"-encoded encoded-word which appears in a comment MUST NOT contain
+ the characters "(", ")" or "\".
+
+- As a replacement for a "word" entity within a "phrase", for example,
+ one that precedes an address in a From, To, or Cc header. The EBNF
+ definition for phrase from RFC 822 thus becomes:
+
+ phrase = 1*(encoded-word / word)
+
+ In this case the set of characters that may be used in a "Q"-encoded
+ encoded-word is restricted to: <upper and lower case ASCII letters,
+ decimal digits, "!", "*", "+", "-", "/", "=", and "_" (underscore,
+ ASCII 95.)>.
+
+ These are the ONLY locations where an encoded-word may appear. In
+ particular, an encoded-word MUST NOT appear in any portion of an
+ "address". In addition, an encoded-word MUST NOT be used in a
+ Received header field.
+
+ Whenever such words appear in a header being displayed, an enlightened
+ mail reader will decode the text and render it appropriately.
+
+ Only textual data (printable and white space characters) should be
+ encoded using this scheme. However, since these encoding schemes
+ allow the encoding of arbitrary 8-bit values, mail readers that
+ implement this decoding should also ensure that display of the
+ decoded data on the recipient's terminal will not cause unwanted
+ side-effects.
+
+ Use of these methods to encode non-textual data (e.g., pictures or
+ sounds) is not defined by this memo. Use of encoded-words to
+ represent strings of purely ASCII characters is allowed, but
+ discouraged.
+
+
+
+Moore [Page 5]
+
+RFC 1342 Non-ASCII Mail Headers June 1992
+
+
+Recognition of encoded-words in message headers.
+
+ An encoded-word may be distinguished from an ordinary "word", "text",
+ or "ctext", as follows: An encoded-word begins with "=?", ends with
+ "?=", contains exactly four "?" characters including the delimiters,
+ and is followed by a SPACE or newline. If the "word", "text", or
+ "ctext" does not meet the above tests, it should be displayed as it
+ appears in the message header.
+
+ If the mail reader does not support the character set used, it may
+ either display the encoded-word as ordinary text (i.e., as it appears
+ in the header), or it may substitute an appropriate message
+ indicating that the decoded text could not be displayed.
+
+Conformance
+
+ A mail composing program claiming compliance with this specification
+ MUST ensure that any string of printable ASCII characters in a
+ message header that begins with "=?" and ends with "?=" be a valid
+ encoded-word.
+
+ A mail reading program claiming compliance with this specification
+ must be able to distinguish encoded-words from "text", "ctext", or
+ "word"s anytime they appear in appropriate places in message headers.
+ The program must be able to display unencoded text if the character
+ set is "US-ASCII". For the ISO-8859-* character sets, the mail
+ reading program must at least be able to display the characters which
+ are also in the ASCII set.
+
+Examples
+
+ From: =?US-ASCII?Q?Keith_Moore?= <moore cs utk edu>
+ To: =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?= <keld dkuug dk>
+ CC: =?ISO-8859-1?Q?Andr=E9_?= Pirard <PIRARD vm1 ulg ac be>
+ Subject: =?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=?=
+ =?ISO-8859-2?B?dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg==?=
+
+ From: =?ISO-8859-1?Q?Olle_J=E4rnefors?= <ojarnef admin kth se>
+ To: ietf-822 dimacs rutgers edu, ojarnef admin kth se
+ Subject: Time for ISO 10646?
+
+ To: Dave Crocker <dcrocker mordor stanford edu>
+ Cc: ietf-822 dimacs rutgers edu, paf comsol se
+ From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf nada kth se>
+ Subject: Re: RFC-HDR care and feeding
+
+
+
+
+
+
+Moore [Page 6]
+
+RFC 1342 Non-ASCII Mail Headers June 1992
+
+
+ From: Nathaniel Borenstein <nsb thumper bellcore com>
+ (=?iso-8859-8?b?7eXs+SDv4SDp7Oj08A==?=)
+ To: Greg Vaudreuil <gvaudre NRI Reston VA US>, Ned Freed
+ <ned innosoft com>,
+ Keith Moore <moore cs utk edu>
+ Subject: Test of new header generator
+ MIME-Version: 1.0
+ Content-type: text/plain; charset=ISO-8859-1
+
+References
+
+ [1] Borenstein N., and N. Freed, "MIME (Multipurpose Internet Mail
+ Extensions): Mechanisms for Specifying and Describing the Format
+ of Internet Message Bodies", RFC 1341, Bellcore, Innosoft,
+ June 1992.
+
+ [2] Crocker, D., "Standard for the Format of ARPA Internet Text
+ Messages", RFC 822, UDEL, August 1982.
+
+Security Considerations
+
+ Security issues are not discussed in this memo.
+
+Author's Address
+
+ Keith Moore
+ University of Tennessee
+ 107 Ayres Hall
+ Knoxville TN 37996-1301
+
+ EMail: moore cs utk edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moore [Page 7]
+
\ No newline at end of file
diff --git a/rfc/rfc1522.txt b/rfc/rfc1522.txt
new file mode 100644
index 0000000..25bfd6b
--- /dev/null
+++ b/rfc/rfc1522.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group K. Moore
+Request for Comments: 1522 University of Tennessee
+Obsoletes: 1342 September 1993
+Category: Standards Track
+
+
+ MIME (Multipurpose Internet Mail Extensions) Part Two:
+ Message Header Extensions for Non-ASCII Text
+
+Status of this Memo
+
+ This RFC specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" for the standardization state and status
+ of this protocol. Distribution of this memo is unlimited.
+
+Abstract
+
+ This memo describes an extension to the message format defined in RFC
+ 1521 [1], to allow the representation of character sets other than
+ ASCII in RFC 822 (STD 11) message headers. The extensions described
+ were designed to be highly compatible with existing Internet mail
+ handling software, and to be easily implemented in mail readers that
+ support RFC 1521.
+
+1. Introduction
+
+ RFC 1521 describes a mechanism for denoting textual body parts which
+ are coded in various character sets, as well as methods for encoding
+ such body parts as sequences of printable ASCII characters. This
+ memo describes similar techniques to allow the encoding of non-ASCII
+ text in various portions of a RFC 822 [2] message header, in a manner
+ which is unlikely to confuse existing message handling software.
+
+ Like the encoding techniques described in RFC 1521, the techniques
+ outlined here were designed to allow the use of non-ASCII characters
+ in message headers in a way which is unlikely to be disturbed by the
+ quirks of existing Internet mail handling programs. In particular,
+ some mail relaying programs are known to (a) delete some message
+ header fields while retaining others, (b) rearrange the order of
+ addresses in To or Cc fields, (c) rearrange the (vertical) order of
+ header fields, and/or (d) "wrap" message headers at different places
+ than those in the original message. In addition, some mail reading
+ programs are known to have difficulty correctly parsing message
+ headers which, while legal according to RFC 822, make use of
+ backslash-quoting to "hide" special characters such as "<", ",", or
+ ":", or which exploit other infrequently-used features of that
+
+
+
+Moore [Page 1]
+
+RFC 1522 MIME Part Two September 1993
+
+
+ specification.
+
+ While it is unfortunate that these programs do not correctly
+ interpret RFC 822 headers, to "break" these programs would cause
+ severe operational problems for the Internet mail system. The
+ extensions described in this memo therefore do not rely on little-
+ used features of RFC 822.
+
+ Instead, certain sequences of "ordinary" printable ASCII characters
+ (known as "encoded-words") are reserved for use as encoded data. The
+ syntax of encoded-words is such that they are unlikely to
+ "accidentally" appear as normal text in message headers.
+ Furthermore, the characters used in encoded-words are restricted to
+ those which do not have special meanings in the context in which the
+ encoded-word appears.
+
+ Generally, an "encoded-word" is a sequence of printable ASCII
+ characters that begins with "=?", ends with "?=", and has two "?"s in
+ between. It specifies a character set and an encoding method, and
+ also includes the original text encoded as graphic ASCII characters,
+ according to the rules for that encoding method.
+
+ A mail composer that implements this specification will provide a
+ means of inputting non-ASCII text in header fields, but will
+ translate these fields (or appropriate portions of these fields) into
+ encoded-words before inserting them into the message header.
+
+ A mail reader that implements this specification will recognize
+ encoded-words when they appear in certain portions of the message
+ header. Instead of displaying the encoded-word "as is", it will
+ reverse the encoding and display the original text in the designated
+ character set.
+
+ NOTES
+
+ This memo relies heavily on notation and terms defined STD 11, RFC
+ 822 and RFC 1521. In particular, the syntax for the ABNF used in
+ this memo is defined in STD 11, RFC 822, as well as many of the
+ terms used in the grammar for the header extensions defined here.
+ Successful implementation of this protocol extension requires
+ careful attention to the details of both STD 11, RFC 822 and RFC
+ 1521.
+
+ When the term "ASCII" appears in this memo, it refers to the "7-
+ Bit American Standard Code for Information Interchange", ANSI
+ X3.4-1986. The MIME charset name for this character set is "US-
+ ASCII". When not specifically referring to the MIME charset name,
+ this document uses the term "ASCII", both for brevity and for
+
+
+
+Moore [Page 2]
+
+RFC 1522 MIME Part Two September 1993
+
+
+ consistency with STD 11, RFC 822. However, implementors are
+ warned that the character set name must be spelled "US-ASCII" in
+ MIME message and body part headers.
+
+2. Syntax of encoded-words
+
+ An "encoded-word" is defined by the following ABNF grammar. The
+ notation of RFC 822 is used, with the exception that white space
+ characters MAY NOT appear between components of an encoded-word.
+
+ encoded-word = "=?" charset "?" encoding "?" encoded-text "?="
+
+ charset = token ; see section 3
+
+ encoding = token ; see section 4
+
+ token = 1*<Any CHAR except SPACE, CTLs, and especials>
+
+ especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "
+ <"> / "/" / "[" / "]" / "?" / "." / "="
+
+ encoded-text = 1*<Any printable ASCII character other
+ than "?" or SPACE>
+ ; (but see "Use of encoded-words in message
+ ; headers", section 5)
+
+ Both "encoding" and "charset" names are case-independent. Thus the
+ charset name "ISO-8859-1" is equivalent to "iso-8859-1", and the
+ encoding named "Q" may be spelled either "Q" or "q".
+
+ An encoded-word may not be more than 75 characters long, including
+ charset, encoding, encoded-text, and delimiters. If it is desirable
+ to encode more text than will fit in an encoded-word of 75
+ characters, multiple encoded-words (separated by CRLF SPACE) may be
+ used.
+
+ While there is no limit to the length of a multiple-line header
+ field, each line of a header field that contains one or more
+ encoded-words is limited to 76 characters.
+
+ The length restrictions are included not only to ease
+ interoperability through internetwork mail gateways, but also to
+ impose a limit on the amount of lookahead a header parser must employ
+ (while looking for a final ?= delimiter) before it can decide whether
+ a token is an encoded-word or something else.
+
+ The characters which may appear in encoded-text are further
+ restricted by the rules in section 5.
+
+
+
+Moore [Page 3]
+
+RFC 1522 MIME Part Two September 1993
+
+
+3. Character sets
+
+ The "charset" portion of an encoded-word specifies the character set
+ associated with the unencoded text. A charset can be any of the
+ character set names allowed in an RFC 1521 "charset" parameter of a
+ "text/plain" body part, or any character set name registered with
+ IANA for use with the MIME text/plain content-type [3]. (See section
+ 7.1.1 of RFC 1521 for a list of charsets defined in that document).
+
+ Some character sets use code-switching techniques to switch between
+ "ASCII mode" and other modes. If unencoded text in an encoded-word
+ contains control codes to switch out of ASCII mode, it must also
+ contain additional control codes such that ASCII mode is again
+ selected at the end of the encoded-word. (This rule applies
+ separately to each encoded-word, including adjacent encoded-words
+ within a single header field.)
+
+ When there is a possibility of using more than one character set to
+ represent the text in an encoded-word, and in the absence of private
+ agreements between sender and recipients of a message, it is
+ recommended that members of the ISO-8859-* series be used in
+ preference to other character sets.
+
+4. Encodings
+
+ Initially, the legal values for "encoding" are "Q" and "B". These
+ encodings are described below. The "Q" encoding is recommended for
+ use when most of the characters to be encoded are in the ASCII
+ character set; otherwise, the "B" encoding should be used.
+ Nevertheless, a mail reader which claims to recognize encoded-words
+ MUST be able to accept either encoding for any character set which it
+ supports.
+
+ Only a subset of the printable ASCII characters may be used in
+ encoded-text. Space and tab characters are not allowed, so that the
+ beginning and end of an encoded-word are obvious. The "?" character
+ is used within an encoded-word to separate the various portions of
+ the encoded-word from one another, and thus cannot appear in the
+ encoded-text portion. Other characters are also illegal in certain
+ contexts. For example, an encoded-word in a "phrase" preceding an
+ address in a From header field may not contain any of the "specials"
+ defined in RFC 822. Finally, certain other characters are disallowed
+ in some contexts, to ensure reliability for messages that pass
+ through internetwork mail gateways.
+
+ The "B" encoding automatically meets these requirements. The "Q"
+ encoding allows a wide range of printable characters to be used in
+ non-critical locations in the message header (e.g., Subject), with
+
+
+
+Moore [Page 4]
+
+RFC 1522 MIME Part Two September 1993
+
+
+ fewer characters available for use in other locations.
+
+4.1. The "B" encoding
+
+ The "B" encoding is identical to the "BASE64" encoding defined by RFC
+ 1521.
+
+4.2. The "Q" encoding
+
+ The "Q" encoding is similar to the "Quoted-Printable" content-
+ transfer-encoding defined in RFC 1521. It is designed to allow text
+ containing mostly ASCII characters to be decipherable on an ASCII
+ terminal without decoding.
+
+ (1) Any 8-bit value may be represented by a "=" followed by two
+ hexadecimal digits. For example, if the character set in use
+ were ISO-8859-1, the "=" character would thus be encoded as
+ "=3D", and a SPACE by "=20". (Upper case should be used for
+ hexadecimal digits "A" through "F".)
+
+ (2) The 8-bit hexadecimal value 20 (e.g., ISO-8859-1 SPACE) may be
+ represented as "_" (underscore, ASCII 95.). (This character may
+ not pass through some internetwork mail gateways, but its use
+ will greatly enhance readability of "Q" encoded data with mail
+ readers that do not support this encoding.) Note that the "_"
+ always represents hexadecimal 20, even if the SPACE character
+ occupies a different code position in the character set in use.
+
+ (3) 8-bit values which correspond to printable ASCII characters other
+ than "=", "?", "_" (underscore), and SPACE may be represented as
+ those characters. (But see section 5 for restrictions.)
+
+5. Use of encoded-words in message headers
+
+ An encoded-word may appear in a message header or body part header
+ according to the following rules:
+
+ (1) An encoded-word may replace a "text" token (as defined by RFC
+ 822) in any Subject or Comments header field, any extension
+ message header field, or any RFC 1521 body part field for which
+ the field body is defined as "*text". An encoded-word may also
+ appear in any user-defined ("X-") message or body part header
+ field.
+
+ Ordinary ASCII text and encoded-words may appear together in the
+ same header field. However, an encoded-word that appears in a
+ header field defined as "*text" MUST be separated from any
+ adjacent encoded-word or "text" by linear-white-space.
+
+
+
+Moore [Page 5]
+
+RFC 1522 MIME Part Two September 1993
+
+
+ (2) An encoded-word may appear within a comment delimited by "(" and
+ ")", i.e., wherever a "ctext" is allowed. More precisely, the
+ RFC 822 ABNF definition for "comment" is amended as follows:
+
+ comment = "(" *(ctext / quoted-pair / comment / encoded-word) ")"
+
+ A "Q"-encoded encoded-word which appears in a comment MUST NOT
+ contain the characters "(", ")" or " encoded-word that appears in
+ a "comment" MUST be separated from any adjacent encoded-word or
+ "ctext" by linear-white-space.
+
+ (3) As a replacement for a "word" entity within a "phrase", for
+ example, one that precedes an address in a From, To, or Cc
+ header. The ABNF definition for phrase from RFC 822 thus
+ becomes:
+
+ phrase = 1*(encoded-word / word)
+
+ In this case the set of characters that may be used in a "Q"-
+ encoded encoded-word is restricted to: <upper and lower case
+ ASCII letters, decimal digits, "!", "*", "+", "-", "/", "=", and
+ "_" (underscore, ASCII 95.)>. An encoded-word that appears
+ within a "phrase" MUST be separated from any adjacent "word",
+ "text" or "special" by linear-white-space.
+
+ These are the ONLY locations where an encoded-word may appear. In
+ particular, an encoded-word MUST NOT appear in any portion of an
+ "addr-spec". In addition, an encoded-word MUST NOT be used in a
+ Received header field.
+
+ Each encoded-word MUST encode an integral number of octets. The
+ encoded-text in each encoded-word must be well-formed according to
+ the encoding specified; the encoded-text may not be continued in the
+ next encoded-word. (For example, "=?charset?Q?=?= =?charset?Q?AB?="
+ would be illegal, because the two hex digits "AB" must follow the "="
+ in the same encoded-word.)
+
+ Each encoded-word MUST represent an integral number of characters. A
+ multi-octet character may not be split across adjacent encoded-words.
+
+ Only printable and white space character data should be encoded using
+ this scheme. However, since these encoding schemes allow the
+ encoding of arbitrary octet values, mail readers that implement this
+ decoding should also ensure that display of the decoded data on the
+ recipient's terminal will not cause unwanted side-effects.
+
+ Use of these methods to encode non-textual data (e.g., pictures or
+ sounds) is not defined by this memo. Use of encoded-words to
+
+
+
+Moore [Page 6]
+
+RFC 1522 MIME Part Two September 1993
+
+
+ represent strings of purely ASCII characters is allowed, but
+ discouraged. In rare cases it may be necessary to encode ordinary
+ text that looks like an encoded-word.
+
+6. Support of encoded-words by mail readers
+
+6.1. Recognition of encoded-words in message headers
+
+ A mail reader must parse the message and body part headers according
+ to the rules in RFC 822 to correctly recognize encoded-words.
+
+ Encoded-words are to be recognized as follows:
+
+ (1) Any message or body part header field defined as "*text", or any
+ user-defined header field, should be parsed as follows: Beginning
+ at the start of the field-body and immediately following each
+ occurrence of linear-white-space, each sequence of up to 75
+ printable characters (not containing any linear-white-space)
+ should be examined to see if it is an encoded-word according to
+ the syntax rules in section 2. Any other sequence of printable
+ characters should be treated as ordinary ASCII text.
+
+ (2) Any header field not defined as "*text" should be parsed
+ according to the syntax rules for that header field. However,
+ any "word" that appears within a "phrase" should be treated as an
+ encoded-word if it meets the syntax rules in section 2.
+ Otherwise it should be treated as an ordinary "word".
+
+ (3) Within a "comment", any sequence of up to 75 printable characters
+ (not containing linear-white-space), that meets the syntax rules
+ in section 2, should be treated as an encoded-word. Otherwise it
+ should be treated as normal comment text.
+
+6.2. Display of encoded-words
+
+ Any encoded-words so recognized are decoded, and if possible, the
+ resulting unencoded text is displayed in the original character set.
+
+ When displaying a particular header field that contains multiple
+ encoded-words, any linear-white-space that separates a pair of
+ adjacent encoded-words is ignored. (This is to allow the use of
+ multiple encoded-words to represent long strings of unencoded text,
+ without having to separate encoded-words where spaces occur in the
+ unencoded text.)
+
+ In the event other encodings are defined in the future, and the mail
+ reader does not support the encoding used, it may either (a) display
+ the encoded-word as ordinary text, or (b) substitute an appropriate
+
+
+
+Moore [Page 7]
+
+RFC 1522 MIME Part Two September 1993
+
+
+ message indicating that the text could not be decoded.
+
+ If the mail reader does not support the character set used, it may
+ (a) display the encoded-word as ordinary text (i.e., as it appears in
+ the header), (b) make a "best effort" to display using such
+ characters as are available, or (c) substitute an appropriate message
+ indicating that the decoded text could not be displayed.
+
+ If the character set being used employs code-switching techniques,
+ display of the encoded text implicitly begins in "ASCII mode". In
+ addition, the mail reader must ensure that the output device is once
+ again in "ASCII mode" after the encoded-word is displayed.
+
+6.3. Mail reader handling of incorrectly formed encoded-words
+
+ It is possible that an encoded-word that is legal according to the
+ syntax defined in section 2, is incorrectly formed according to the
+ rules for the encoding being used. For example:
+
+ (1) An encoded-word which contains characters which are not legal for
+ a particular encoding (for example, a '-' in the "B" encoding),
+ is incorrectly formed.
+
+ (2) Any encoded-word which encodes a non-integral number of
+ characters or octets is incorrectly formed.
+
+ A mail reader need not attempt to display the text associated with an
+ encoded-word that is incorrectly formed. However, a mail reader MUST
+ NOT prevent the display or handling of a message because an encoded-
+ word is incorrectly formed.
+
+7. Conformance
+
+ A mail composing program claiming compliance with this specification
+ MUST ensure that any string of non-white-space printable ASCII
+ characters within a "*text" or "*ctext" that begins with "=?" and
+ ends with "?=" be a valid encoded-word. ("begins" means: at the
+ start of the field-body or immediately following linear-white-space;
+ "ends" means: at the end of the field-body or immediately preceding
+ linear-white-space.) In addition, any "word" within a "phrase" that
+ begins with "=?" and ends with "?=" must be a valid encoded-word.
+
+ A mail reading program claiming compliance with this specification
+ must be able to distinguish encoded-words from "text", "ctext", or
+ "word"s, according to the rules in section 6, anytime they appear in
+ appropriate places in message headers. It must support both the "B"
+ and "Q" encodings for any character set which it supports. The
+ program must be able to display the unencoded text if the character
+
+
+
+Moore [Page 8]
+
+RFC 1522 MIME Part Two September 1993
+
+
+ set is "US-ASCII". For the ISO-8859-* character sets, the mail
+ reading program must at least be able to display the characters which
+ are also in the ASCII set.
+
+8. Examples
+
+ From: =?US-ASCII?Q?Keith_Moore?= <moore cs utk edu>
+ To: =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?= <keld dkuug dk>
+ CC: =?ISO-8859-1?Q?Andr=E9_?= Pirard <PIRARD vm1 ulg ac be>
+ Subject: =?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=?=
+ =?ISO-8859-2?B?dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg==?=
+
+ From: =?ISO-8859-1?Q?Olle_J=E4rnefors?= <ojarnef admin kth se>
+ To: ietf-822 dimacs rutgers edu, ojarnef admin kth se
+ Subject: Time for ISO 10646?
+
+ To: Dave Crocker <dcrocker mordor stanford edu>
+ Cc: ietf-822 dimacs rutgers edu, paf comsol se
+ From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf nada kth se>
+ Subject: Re: RFC-HDR care and feeding
+
+ From: Nathaniel Borenstein <nsb thumper bellcore com>
+ (=?iso-8859-8?b?7eXs+SDv4SDp7Oj08A==?=)
+ To: Greg Vaudreuil <gvaudre NRI Reston VA US>, Ned Freed
+ <ned innosoft com>, Keith Moore <moore cs utk edu>
+ Subject: Test of new header generator
+ MIME-Version: 1.0
+ Content-type: text/plain; charset=ISO-8859-1
+
+9. References
+
+ [1] Borenstein N., and N. Freed, "MIME (Multipurpose Internet Mail
+ Extensions) Part One: Mechanisms for Specifying and Describing
+ the Format of Internet Message Bodies", RFC 1521, Bellcore,
+ Innosoft, September 1993.
+
+ [2] Crocker, D., "Standard for the Format of ARPA Internet Text
+ Messages", STD 11, RFC 822, UDEL, August 1982.
+
+ [3] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
+ RFC 1340, USC/Information Sciences Institute, July 1992.
+
+
+
+
+
+
+
+
+
+
+Moore [Page 9]
+
+RFC 1522 MIME Part Two September 1993
+
+
+10. Security Considerations
+
+ Security issues are not discussed in this memo.
+
+11. Author's Address
+
+ Keith Moore
+ University of Tennessee
+ 107 Ayres Hall
+ Knoxville TN 37996-1301
+
+ EMail: moore cs utk edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moore [Page 10]
+
\ No newline at end of file
diff --git a/rfc/rfc1544.txt b/rfc/rfc1544.txt
new file mode 100644
index 0000000..43ff309
--- /dev/null
+++ b/rfc/rfc1544.txt
@@ -0,0 +1,171 @@
+
+
+
+
+
+
+Network Working Group M. Rose
+Request for Comments: 1544 Dover Beach Consulting, Inc.
+Category: Standards Track November 1993
+
+
+ The Content-MD5 Header Field
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Abstract
+
+ This memo specifies an optional header field, Content-MD5, for use
+ with MIME-conformant messages.
+
+Table of Contents
+
+ 1. Introduction .......................................... 1
+ 2. Generation of the Content-MD5 Field ................... 2
+ 3. Processing the Content-MD5 field ...................... 2
+ 4. Security Considerations ............................... 3
+ 5. Acknowledgements ...................................... 3
+ 6. References ............................................ 3
+ 7. Author's Address ...................................... 3
+
+1. Introduction
+
+ Despite all of the mechanisms provided by MIME [1] which attempt to
+ protect data from being damaged in the course of email transport, it
+ is still desirable to have a mechanism for verifying that the data,
+ once decoded, are intact. For this reason, this memo defines the use
+ of an optional header field, Content-MD5, which may be used as a
+ message integrity check (MIC), to verify that the decoded data are
+ the same data that were initially sent.
+
+ MD5 is an algorithm for computing a 128 bit "digest" of arbitrary-
+ length data, with a high degree of confidence that any alterations in
+ the data will be reflected in alterations in the digest. The MD5
+ algorithm itself is defined in [2]. This memo specifies how the
+ algorithm may be used as an integrity check for MIME mail.
+
+
+
+
+
+
+Rose [Page 1]
+
+RFC 1544 Content-MD5 Header Field November 1993
+
+
+2. Generation of the Content-MD5 Field
+
+ The Content-MD5 field is generated by only an originating user agent.
+ Message relays and gateways are expressly forbidden from generating a
+ Content-MD5 field.
+
+ Use of the Content-MD5 field is completely optional, but its use is
+ recommended whenever data integrity is desired, but Privacy-Enhanced
+ Mail services [3] are not available. (Consult Section 4 for further
+ details.) The Content-MD5 field may only be added to MIME entities of
+ a `leaf' nature, i.e., the Content-MD5 field may be used with any
+ content type other than multipart or message/rfc822.
+
+ To generate the value of the Content-MD5 field, the MD5 algorithm is
+ computed on the canonical form of the data. In particular, this
+ means that the sender applies the MD5 algorithm on the raw data,
+ before applying any content-transfer-encoding, and that the receiver
+ also applies the MD5 algorithm on the raw data, after undoing any
+ content-transfer-encoding. For textual data, the MD5 algorithm must
+ be computed on data in which the canonical form for newlines applies,
+ that is, in which each newline is represented by a CR-LF pair.
+
+ The output of the MD5 algorithm is a 128 bit digest. When viewed in
+ network byte order (big-endian order), this yields a sequence of 16
+ octets of binary data. These 16 octets are then encoded according to
+ the base64 algorithm in order to obtain the value that is placed in
+ the Content-MD5 field. Thus, if the application of the MD5 algorithm
+ over the raw data of a MIME entity results in a digest having the
+ (unlikely) value of "Check Integrity!", then that MIME entity's
+ header could contain the field
+
+ Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
+
+ Finally, as discussed in Appendix B of [1], textual data is regularly
+ altered in the normal delivery of mail. Because the addition or
+ deletion of trailing white space will result in a different digest,
+ either the quoted-printable or base64 algorithm should be employed as
+ a content-transfer-encoding when the Content-MD5 field is used.
+
+3. Processing the Content-MD5 field
+
+ If the Content-MD5 field is present, a recipient user agent may
+ choose to use it to verify that the contents of a MIME entity have
+ not been modified during transport. Message relays and gateways are
+ expressly forbidden to alter its processing based on the presence of
+ the Content-MD5 field. However, a message gateway is allowed to
+ remove the Content-MD5 field if the corresponding MIME entity is
+ translated into a different content-type.
+
+
+
+Rose [Page 2]
+
+RFC 1544 Content-MD5 Header Field November 1993
+
+
+4. Security Considerations
+
+ This document specifies a data integrity service that protects data
+ from accidental modification while in transit from the sender to the
+ recipient. A secure data integrity service, such as that provided by
+ Privacy Enhanced Mail [3], is conjectured to protect data from all
+ modifications.
+
+5. Acknowledgements
+
+ This memo is based almost entirely on text originally written by
+ Nathaniel Borenstein of Bellcore. In addition, several improvements
+ were suggested by Keith Moore of the University of Tennessee,
+ Knoxville.
+
+6. References
+
+ [1] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail
+ Extensions) Part One: Mechanisms for Specifying and Describing
+ the Format of Internet Message Bodies", RFC 1521, Bellcore,
+ Innosoft, September 1993.
+
+ [2] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, MIT
+ Laboratory for Computer Science and RSA Data Security, Inc.,
+ April 1992.
+
+ [3] Linn, J., "Privacy Enhancement for Internet Electronic Mail, Part
+ I: Message Encryption and Authentication Procedures", RFC 1421,
+ IAB IRTF PSRG, IETF PEM WG, February 1993.
+
+7. Author's Address
+
+ Marshall T. Rose
+ Dover Beach Consulting, Inc.
+ 420 Whisman Court
+ Mountain View, CA 94043-2112
+
+ Phone: (415) 968-1052
+ EMail: mrose dbc mtview ca us
+
+
+
+
+
+
+
+
+
+
+
+
+Rose [Page 3]
+
\ No newline at end of file
diff --git a/rfc/rfc2110.txt b/rfc/rfc2110.txt
new file mode 100644
index 0000000..4bef6eb
--- /dev/null
+++ b/rfc/rfc2110.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Network Working Group J. Palme
+Request for Comments: 2110 Stockholm University/KTH
+Category: Standards Track A. Hopmann
+ Microsoft Corporation
+ March 1997
+
+
+ MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML)
+
+Status of this Document
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Abstract
+
+ Although HTML [RFC 1866] was designed within the context of MIME,
+ more than the specification of HTML as defined in RFC 1866 is needed
+ for two electronic mail user agents to be able to interoperate using
+ HTML as a document format. These issues include the naming of objects
+ that are normally referred to by URIs, and the means of aggregating
+ objects that go together. This document describes a set of guidelines
+ that will allow conforming mail user agents to be able to send,
+ deliver and display these objects, such as HTML objects, that can
+ contain links represented by URIs. In order to be able to handle
+ inter-linked objects, the document uses the MIME type
+ multipart/related and specifies the MIME content-headers "Content-
+ Location" and "Content-Base".
+
+Table of Contents
+
+ 1. Introduction.............................................. 2
+ 2. Terminology............................................... 3
+ 2.1 Conformance requirement terminology................... 3
+ 2.2 Other terminology..................................... 4
+ 3. Overview.................................................. 5
+ 4. The Content-Location and Content-Base MIME Content Headers 6
+ 4.1 MIME content headers.................................. 6
+ 4.2 The Content-Base header............................... 7
+ 4.3 The Content-Location Header........................... 7
+ 4.4 Encoding of URIs in e-mail headers.................... 8
+ 5. Base URIs for resolution of relative URIs................. 8
+ 6. Sending documents without linked objects.................. 9
+ 7. Use of the Content-Type: Multipart/related................ 9
+ 8. Format of Links to Other Body Parts....................... 11
+
+
+
+Palme & Hopmann Standards Track [Page 1]
+
+RFC 2110 MHTML March 1997
+
+
+ 8.1 General principle..................................... 11
+ 8.2 Use of the Content-Location header.................... 11
+ 8.3 Use of the Content-ID header and CID URLs............. 12
+ 9 Examples................................................... 12
+ 9.1 Example of a HTML body without included linked objects 12
+ 9.2 Example with absolute URIs to an embedded GIF picture 13
+ 9.3 Example with relative URIs to an embedded GIF picture 13
+ 9.4 Example using CID URL and Content-ID header to an
+ embedded GIF picture.................................. 14
+ 10. Content-Disposition header............................... 15
+ 11. Character encoding issues and end-of-line issues......... 15
+ 12. Security Considerations.................................. 16
+ 13. Acknowledgments.......................................... 17
+ 14. References............................................... 18
+ 15. Author's Address......................................... 19
+
+Mailing List Information
+
+ Further discussion on this document should be done through the
+ mailing list MHTML SEGATE SUNET SE
+
+ To subscribe to this list, send a message to
+ LISTSERV SEGATE SUNET SE
+ which contains the text
+ SUB MHTML <your name (not your e-mail address)>
+
+ Archives of this list are available by anonymous ftp from
+ FTP://SEGATE.SUNET.SE/lists/mHTML/
+ The archives are also available by e-mail. Send a message to
+ LISTSERV SEGATE SUNET SE with the text "INDEX MHTML" to get a list
+ of the archive files, and then a new message "GET <file name>" to
+ retrieve the archive files.
+
+ Comments on less important details may also be sent to the editor,
+ Jacob Palme <jpalme dsv su se>.
+
+ More information may also be available at URL:
+ HTTP://www.dsv.su.se/~jpalme/ietf/jp-ietf-home.HTML
+
+1. Introduction
+
+ There are a number of document formats, HTML [HTML2], PDF [PDF] and
+ VRML for example, which provide links using URIs for their
+ resolution. There is an obvious need to be able to send documents in
+ these formats in e-mail [RFC821=SMTP, RFC822]. This document gives
+ additional specifications on how to send such documents in MIME [RFC
+ 1521=MIME1] e-mail messages. This version of this standard was based
+ on full consideration only of the needs for objects with links in the
+
+
+
+Palme & Hopmann Standards Track [Page 2]
+
+RFC 2110 MHTML March 1997
+
+
+ Text/HTML media type (as defined in RFC 1866 [HTML2]), but the
+ standard may still be applicable also to other formats for sets of
+ interlinked objects, linked by URIs. There is no conformance
+ requirement that implementations claiming conformance to this
+ standard are able to handle URI-s in other document formats than
+ HTML.
+
+ URIs in documents in HTML and other similar formats reference other
+ objects and resources, either embedded or directly accessible through
+ hypertext links. When mailing such a document, it is often desirable
+ to also mail all of the additional resources that are referenced in
+ it; those elements are necessary for the complete interpretation of
+ the primary object.
+
+ An alternative way for sending an HTML document or other object
+ containing URIs in e-mail is to only send the URL, and let the
+ recipient look up the document using HTTP. That method is described
+ in [URLBODY] and is not described in this document.
+
+ An informational RFC will at a later time be published as a
+ supplement to this standard. The informational RFC will discuss
+ implementation methods and some implementation problems. Implementors
+ are recommended to read this informational RFC when developing
+ implementations of the MHTML standard. This informational RFC is,
+ when this RFC is published, still in IETF draft status, and will stay
+ that way for at least six months in order to gain more implementation
+ experience before it is published.
+
+2. Terminology
+
+2.1 Conformance requirement terminology
+
+ This specification uses the same words as RFC 1123 [HOSTS] for
+ defining the significance of each particular requirement. These words
+ are:
+
+ MUST This word or the adjective "required" means that the item is
+ an absolute requirement of the specification.
+
+ SHOULD This word or the adjective "recommended" means that there may
+ exist valid reasons in particular circumstances to ignore this
+ item, but the full implications should be understood and the
+ case carefully weighed before choosing a different course.
+
+
+
+
+
+
+
+
+Palme & Hopmann Standards Track [Page 3]
+
+RFC 2110 MHTML March 1997
+
+
+ MAY This word or the adjective "optional" means that this item is
+ truly optional. One vendor may choose to include the item
+ because a particular marketplace requires it or because it
+ enhances the product, for example; another vendor may omit
+ the same item.
+
+ An implementation is not compliant if it fails to satisfy one or more
+ of the MUST requirements for the protocols it implements. An
+ implementation that satisfies all the MUST and all the SHOULD
+ requirements for its protocols is said to be "unconditionally
+ compliant"; one that satisfies all the MUST requirements but not all
+ the SHOULD requirements for its protocols is said to be
+ "conditionally compliant."
+
+2.2 Other terminology
+
+ Most of the terms used in this document are defined in other RFCs.
+
+ Absolute URI, See RFC 1808 [RELURL].
+ AbsoluteURI
+
+ CID See [MIDCID].
+
+ Content-Base See section 4.2 below.
+
+ Content-ID See [MIDCID].
+
+ Content-Location MIME message or content part header with the
+ URI of the MIME message or content part body,
+ defined in section 4.3 below.
+
+ Content-Transfer-Enco Conversion of a text into 7-bit octets as
+ ding specified in [MIME1].
+
+ CR See [RFC822].
+
+ CRLF See [RFC822].
+
+ Displayed text The text shown to the user reading a document
+ with a web browser. This may be different from
+ the HTML markup, see the definition of HTML
+ markup below.
+
+ Header Field in a message or content heading specifying
+ the value of one attribute.
+
+
+
+
+
+
+Palme & Hopmann Standards Track [Page 4]
+
+RFC 2110 MHTML March 1997
+
+
+ Heading Part of a message or content before the first
+ CRLFCRLF, containing formatted fields with
+ attributes of the message or content.
+
+ HTML See RFC 1866 [HTML2].
+
+ HTML Aggregate HTML objects together with some or all objects,
+ to objects which the HTML object contains
+ hyperlinks.
+
+ HTML markup A file containing HTML encodings as specified
+ in [HTML] which may be different from the
+ displayed text which a person using a web
+ browser sees. For example, the HTML markup
+ may contain "<" where the displayed text
+ contains the character "<".
+
+ LF See [RFC822].
+
+ MIC Message Integrity Codes, codes use to verify
+ that a message has not been modified.
+
+ MIME See RFC 1521 [MIME1], [MIME2].
+
+ MUA Messaging User Agent.
+
+ PDF Portable Document Format, see [PDF].
+
+ Relative URI, See RFC 1866 [HTML2] and RFC 1808[RELURL].
+ RelativeURI
+
+ URI, absolute and See RFC 1866 [HTML2].
+ relative
+
+ URL See RFC 1738 [URL].
+
+ URL, relative See [RELURL].
+
+ VRML Virtual Reality Markup Language.
+
+3. Overview
+
+ An aggregate document is a MIME-encoded message that contains a root
+ document as well as other data that is required in order to represent
+ that document (inline pictures, style sheets, applets, etc.).
+ Aggregate documents can also include additional elements that are
+ linked to the first object. It is important to keep in mind the
+ differing needs of several audiences. Mail sending agents might send
+
+
+
+Palme & Hopmann Standards Track [Page 5]
+
+RFC 2110 MHTML March 1997
+
+
+ aggregate documents as an encoding of normal day-to-day electronic
+ mail. Mail sending agents might also send aggregate documents when a
+ user wishes to mail a particular document from the web to someone
+ else. Finally mail sending agents might send aggregate documents as
+ automatic responders, providing access to WWW resources for non-IP
+ connected clients.
+
+ Mail receiving agents also have several differing needs. Some mail
+ receiving agents might be able to receive an aggregate document and
+ display it just as any other text content type would be displayed.
+ Others might have to pass this aggregate document to a browsing
+ program, and provisions need to be made to make this possible.
+
+ Finally several other constraints on the problem arise. It is
+ important that it be possible for a document to be signed and for it
+ to be able to be transmitted to a client and displayed with a minimum
+ risk of breaking the message integrity (MIC) check that is part of
+ the signature.
+
+4. The Content-Location and Content-Base MIME Content Headers
+
+4.1 MIME content headers
+
+ In order to resolve URI references to other body parts, two MIME
+ content headers are defined, Content-Location and Content-Base. Both
+ these headers can occur in any message or content heading, and will
+ then be valid within this heading and for its content.
+
+ In practice, at present only those URIs which are URLs are used, but
+ it is anticipated that other forms of URIs will in the future be
+ used.
+
+ The syntax for these headers is, using the syntax definition tools
+ from [RFC822]:
+
+ content-location ::= "Content-Location:" ( absoluteURI |
+ relativeURI )
+
+ content-base ::= "Content-Base:" absoluteURI
+
+ where URI is at present (June 1996) restricted to the syntax for URLs
+ as defined in RFC 1738 [URL].
+
+ These two headers are valid only for exactly the content heading or
+ message heading where they occurs and its text. They are thus not
+ valid for the parts inside multipart headings, and are thus
+ meaningless in multipart headings.
+
+
+
+
+Palme & Hopmann Standards Track [Page 6]
+
+RFC 2110 MHTML March 1997
+
+
+ These two headers may occur both inside and outside of a
+ multipart/related part.
+
+4.2 The Content-Base header
+
+ The Content-Base gives a base for relative URIs occurring in other
+ heading fields and in HTML documents which do not have any BASE
+ element in its HTML code. Its value MUST be an absolute URI.
+
+ Example showing which Content-Base is valid where:
+
+ Content-Type: Multipart/related; boundary="boundary-example-1";
+ type=Text/HTML; start=foo2*foo3 bar2 net
+ ; A Content-Base header cannot be placed here, since this is a
+ ; multipart MIME object.
+
+ --boundary-example-1
+
+ Part 1:
+ Content-Type: Text/HTML; charset=US-ASCII
+ Content-ID: <foo2*foo3 bar2 net>
+ Content-Location: http://www.ietf.cnir.reston.va.us/images/foo1.bar1
+ ; This Content-Location must contain an absolute URI, since no base
+ ; is valid here.
+
+ --boundary-example-1
+
+ Part 2:
+ Content-Type: Text/HTML; charset=US-ASCII
+ Content-ID: <foo4*foo5 bar2 net>
+ Content-Location: foo1.bar1 ; The Content-Base below applies to
+ ; this relative URI
+ Content-Base: http://www.ietf.cnri.reston.va.us/images/
+
+ --boundary-example-1--
+
+4.3 The Content-Location Header
+
+ The Content-Location header specifies the URI that corresponds to the
+ content of the body part in whose heading the header is placed. Its
+ value CAN be an absolute or relative URI. Any URI or URL scheme may
+ be used, but use of non-standardized URI or URL schemes might entail
+ some risk that recipients cannot handle them correctly.
+
+ The Content-Location header can be used to indicate that the data
+ sent under this heading is also retrievable, in identical format,
+ through normal use of this URI. If used for this purpose, it must
+ contain an absolute URI or be resolvable, through a Content-Base
+
+
+
+Palme & Hopmann Standards Track [Page 7]
+
+RFC 2110 MHTML March 1997
+
+
+ header, into an absolute URI. In this case, the information sent in
+ the message can be seen as a cached version of the original data.
+
+ The header can also be used for data which is not available to some
+ or all recipients of the message, for example if the header refers to
+ an object which is only retrievable using this URI in a restricted
+ domain, such as within a company-internal web space. The header can
+ even contain a fictious URI and need in that case not be globally
+ unique.
+
+ Example:
+
+ Content-Type: Multipart/related; boundary="boundary-example-1";
+ type=Text/HTML
+
+ --boundary-example-1
+
+ Part 1:
+ Content-Type: Text/HTML; charset=US-ASCII
+
+ ... ... <IMG SRC="fiction1/fiction2"> ... ...
+
+ --boundary-example-1
+
+ Part 2:
+ Content-Type: Text/HTML; charset=US-ASCII
+ Content-Location: fiction1/fiction2
+
+ --boundary-example-1--
+
+4.4 Encoding of URIs in e-mail headers
+
+ Since MIME header fields have a limited length and URIs can get quite
+ long, these lines may have to be folded. If such folding is done, the
+ algorithm defined in [URLBODY] section 3.1 should be employed.
+
+5. Base URIs for resolution of relative URIs
+
+ Relative URIs inside contents of MIME body parts are resolved
+ relative to a base URI. In order to determine this base URI, the
+ first-applicable method in the following list applies.
+
+ (a) There is a base specification inside the MIME body part
+ containing the link which resolves relative URIs into absolute
+ URIs. For example, HTML provides the BASE element for this.
+
+ (b) There is a Content-Base header (as defined in section 4.2),
+ specifying the base to be used.
+
+
+
+Palme & Hopmann Standards Track [Page 8]
+
+RFC 2110 MHTML March 1997
+
+
+ (c) There is a Content-Location header in the heading of the body
+ part which can then serve as the base in the same way as the
+ requested URI can serve as a base for relative URIs within a
+ file retrieved via HTTP [HTTP].
+
+ When the methods above do not yield an absolute URI the procedure in
+ section 8.2 for matching relative URIs MUST be followed.
+
+6. Sending documents without linked objects
+
+ If a document, such as an HTML object, is sent without other objects,
+ to which it is linked, it MAY be sent as a Text/HTML body part by
+ itself. In this case, multipart/related need not be used.
+
+ Such a document may either not include any links, or contain links
+ which the recipient resolves via ordinary net look up, or contain
+ links which the recipient cannot resolve.
+
+ Inclusion of links which the recipient has to look up through the net
+ may not work for some recipients, since all e-mail recipients do not
+ have full internet connectivity. Also, such links may work for the
+ sender but not for the recipient, for example when the link refers to
+ an URI within a company-internal network not accessible from outside
+ the company.
+
+ Note that documents with links that the recipient cannot resolve MAY
+ be sent, although this is discouraged. For example, two persons
+ developing a new HTML page may exchange incomplete versions.
+
+7. Use of the Content-Type: Multipart/related
+
+ If a message contains one or more MIME body parts containing links
+ and also contains as separate body parts, data, to which these links
+ (as defined, for example, in RFC 1866 [HTML2]) refers, then this
+ whole set of body parts (referring body parts and referred-to body
+ parts) SHOULD be sent within a multipart/related body part as defined
+ in [REL].
+
+ The root body part of the multipart/related SHOULD be the start
+ object for rendering the object, such as a text/html object, and
+ which contains links to objects in other body parts, or a
+ multipart/alternative of which at least one alternative resolves to
+ such a start object. Implementors are warned, however, that many
+ mail programs treat multipart/alternative as if it had been
+ multipart/mixed (even though MIME [MIME1] requires support for
+ multipart/alternative).
+
+
+
+
+
+Palme & Hopmann Standards Track [Page 9]
+
+RFC 2110 MHTML March 1997
+
+
+ [REL] requires that the type attribute of the "Content-Type:
+ Multipart/related" statement be the type of the root object, and this
+ value can thus be "multipart/alternative". If the root is not the
+ first body part within the multipart/related, [REL] further requires
+ that its Content-ID MUST be given in a start parameter to the
+ "Content-Type: Multipart/related" header.
+
+ When presenting the root body part to the user, the additional body
+ parts within the multipart/related can be used:
+
+ (a) For those recipients who only have e-mail but not full
+ Internet access.
+
+ (b) For those recipients who for other reasons, such as firewalls
+ or the use of company-internal links, cannot retrieve the
+ linked body parts through the net.
+
+ Note that this means that you can, via e-mail, send HTML which
+ includes URIs which the recipient cannot resolve via HTTPor
+ other connectivity-requiring URIs.
+
+ (c) For items which are not available on the web.
+
+ (d) For any recipient to speed up access.
+
+ The type parameter of the "Content-Type: Multipart/related" MUST be
+ the same as the Content-Type of its root.
+
+ When a sending MUA sends objects which were retrieved from the WWW,
+ it SHOULD maintain their WWW URIs. It SHOULD not transform these URIs
+ into some other URI form prior to transmitting them. This will allow
+ the receiving MUA to both verify MICs included with the email
+ message, as well as verify the documents against their WWW
+ counterpoints.
+
+ In certain special cases this will not work if the original HTML
+ document contains URIs as parameters to objects and applets. In such
+ a case, it might be better to rewrite the document before sending it.
+ This problem is discussed in more detail in the informational RFC
+ which will be published as a supplement to this standard.
+
+ This standard does not cover the case where a multipart/related
+ contains links to MIME body parts outside of the current
+ multipart/related or in other MIME messages, even if methods similar
+ to those described in this standard are used. Implementors who
+ provide such links are warned that mailers implementing this standard
+ may not be able to resolve such links.
+
+
+
+
+Palme & Hopmann Standards Track [Page 10]
+
+RFC 2110 MHTML March 1997
+
+
+ Within such a multipart/related, ALL different parts MUST have
+ different Content-Location or Content-ID values.
+
+8. Format of Links to Other Body Parts
+
+8.1 General principle
+
+ A body part, such as a text/HTML body part, may contain hyperlinks to
+ objects which are included as other body parts in the same message
+ and within the same multipart/related content. Often such linked
+ objects are meant to be displayed inline to the reader of the main
+ document; for example, objects referenced with the IMG tag in HTML
+ [RFC 1866=HTML2]. New tags with this property are proposed in the
+ ongoing development of HTML (example: applet, frame).
+
+ In order to send such messages, there is a need to indicate which
+ other body parts are referred to by the links in the body parts
+ containing such links. For example, a body part of Content-Type:
+ Text/HTML often has links to other objects, which might be included
+ in other body parts in the same MIME message. The referencing of
+ other body parts is done in the following way: For each body part
+ containing links and each distinct URI within it, which refers to
+ data which is sent in the same MIME message, there SHOULD be a
+ separate body part within the current multipart/related part of the
+ message containing this data. Each such body part SHOULD contain a
+ Content-Location header (see section 8.2) or a Content-ID header (see
+ section 8.3).
+
+ An e-mail system which claims conformance to this standard MUST
+ support receipt of multipart/related (as defined in section 7) with
+ links between body parts using both the Content-Location (as defined
+ in section 8.2) and the Content-ID method (as defined in section
+ 8.3).
+
+8.2 Use of the Content-Location header
+
+ If there is a Content-Base header, then the recipient MUST employ
+ relative to absolute resolution as defined in RFC 1808 [RELURL] of
+ relative URIs in both the HTML markup and the Content-Location header
+ before matching a hyperlink in the HTML markup to a Content-Location
+ header. The same applies if the Content-Location contains an absolute
+ URI, and the HTML markup contains a BASE element so that relative
+ URIs in the HTML markup can be resolved.
+
+ If there is NO Content-Base header, and the Content-Location header
+ contains a relative URI, then NO relative to absolute resolution
+ SHOULD be performed. Matching the relative URI in the Content-
+ Location header to a hyperlink in an HTML markup text is in this case
+
+
+
+Palme & Hopmann Standards Track [Page 11]
+
+RFC 2110 MHTML March 1997
+
+
+ a two step process. First remove any LWSP from the relative URI which
+ may have been introduced as described in section 4.4. Then perform an
+ exact textual match against the HTML URIs. For this matching process,
+ ignore BASE specifications, such as the BASE element in HTML. Note
+ that this only applies for matching Content-Location headers, not for
+ URL-s in the HTML document which are resolved through network look up
+ at read time.
+
+ The URI in the Content-Location header need not refer to an object
+ which is actually available globally for retrieval using this URI
+ (after resolution of relative URIs). However, URI-s in Content-
+ Location headers (if absolute, or resolvable to absolute URIs) SHOULD
+ still be globally unique.
+
+8.3 Use of the Content-ID header and CID URLs
+
+ When CID (Content-ID) URLs as defined in RFC 1738 [URL] and RFC 1873
+ [MIDCID] are used for links between body parts, the Content-Location
+ statement will normally be replaced by a Content-ID header. Thus, the
+ following two headers are identical in meaning:
+
+ Content-ID: foo bar net
+ Content-Location: CID: foo bar net
+
+ Note: Content-IDs MUST be globally unique [MIME1]. It is thus not
+ permitted to make them unique only within this message or within this
+ multipart/related.
+
+9 Examples
+
+9.1 Example of a HTML body without included linked objects
+
+ The first example is the simplest form of an HTML email message. This
+ is not an aggregate HTML object, but simply a message with a single
+ HTML body part. This message contains a hyperlink but does not
+ provide the ability to resolve the hyperlink. To resolve the
+ hyperlink the receiving client would need either IP access to the
+ Internet, or an electronic mail web gateway.
+
+ From: foo1 bar net
+ To: foo2 bar net
+ Subject: A simple example
+ Mime-Version: 1.0
+ Content-Type: Text/HTML; charset=US-ASCII
+
+
+
+
+
+
+
+Palme & Hopmann Standards Track [Page 12]
+
+RFC 2110 MHTML March 1997
+
+
+ <HTML>
+ <head></head>
+ <body>
+ <h1>Hi there!</h1>
+ An example of an HTML message.<p>
+ Try clicking <a href="http://www.resnova.com/";>here.</a><p>
+ </body></HTML>
+
+9.2 Example with absolute URIs to an embedded GIF picture
+
+ From: foo1 bar net
+ To: foo2 bar net
+ Subject: A simple example
+ Mime-Version: 1.0
+ Content-Type: Multipart/related; boundary="boundary-example-1";
+ type=Text/HTML; start=foo3*foo1 bar net
+
+ --boundary-example-1
+ Content-Type: Text/HTML;charset=US-ASCII
+ Content-ID: <foo3*foo1 bar net>
+
+ ... text of the HTML document, which might contain a hyperlink
+ to the other body part, for example through a statement such as:
+ <IMG SRC="http://www.ietf.cnri.reston.va.us/images/ietflogo.gif";
+ ALT="IETF logo">
+
+ --boundary-example-1
+ Content-Location:
+ http://www.ietf.cnri.reston.va.us/images/ietflogo.gif
+ Content-Type: IMAGE/GIF
+ Content-Transfer-Encoding: BASE64
+
+ R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
+ NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
+ etc...
+
+ --boundary-example-1--
+
+9.3 Example with relative URIs to an embedded GIF picture
+
+ From: foo1 bar net
+ To: foo2 bar net
+ Subject: A simple example
+ Mime-Version: 1.0
+ Content-Base: http://www.ietf.cnri.reston.va.us
+ Content-Type: Multipart/related; boundary="boundary-example-1";
+ type=Text/HTML
+
+
+
+
+Palme & Hopmann Standards Track [Page 13]
+
+RFC 2110 MHTML March 1997
+
+
+ --boundary-example-1
+ Content-Type: Text/HTML; charset=ISO-8859-1
+ Content-Transfer-Encoding: QUOTED-PRINTABLE
+
+ ... text of the HTML document, which might contain a hyperlink
+ to the other body part, for example through a statement such as:
+ <IMG SRC="/images/ietflogo.gif" ALT="IETF logo">
+ Example of a copyright sign encoded with Quoted-Printable: =A9
+ Example of a copyright sign mapped onto HTML markup: ¨
+
+ --boundary-example-1
+ Content-Location: /images/ietflogo.gif
+ Content-Type: IMAGE/GIF
+ Content-Transfer-Encoding: BASE64
+
+ R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
+ NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
+ etc...
+
+ --boundary-example-1--
+
+9.4 Example using CID URL and Content-ID header to an embedded GIF
+ picture
+
+ From: foo1 bar net
+ To: foo2 bar net
+ Subject: A simple example
+ Mime-Version: 1.0
+ Content-Type: Multipart/related; boundary="boundary-example-1";
+ type=Text/HTML
+
+ --boundary-example-1
+ Content-Type: Text/HTML; charset=US-ASCII
+
+ ... text of the HTML document, which might contain a hyperlink
+ to the other body part, for example through a statement such as:
+ <IMG SRC="cid:foo4*foo1@bar.net" ALT="IETF logo">
+
+ --boundary-example-1
+ Content-ID: <foo4*foo1 bar net>
+ Content-Type: IMAGE/GIF
+ Content-Transfer-Encoding: BASE64
+
+ R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
+ NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
+ etc...
+
+ --boundary-example-1--
+
+
+
+Palme & Hopmann Standards Track [Page 14]
+
+RFC 2110 MHTML March 1997
+
+
+10. Content-Disposition header
+
+ Note the specification in [REL] on the relations between Content-
+ Disposition and multipart/related.
+
+11. Character encoding issues and end-of-line issues
+
+ For the encoding of characters in HTML documents and other text
+ documents into a MIME-compatible octet stream, the following
+ mechanisms are relevant:
+
+ - HTML [HTML2, HTML-I18N] as an application of SGML [SGML] allows
+ characters to be denoted by character entities as well as by numeric
+ character references (e.g. "Latin small letter a with acute accent"
+ may be represented by "á" or "á") in the HTML markup.
+
+ - HTML documents, in common with other documents of the MIME
+ "Content-Type text", can be represented in MIME using one of
+ several character encodings. The MIME Content-Type "charset"
+ parameter value indicates the particular encoding used. For the
+ exact meaning and use of the "charset" parameter, please see
+ [MIME-IMB section 4.2].
+
+ Note that the "charset" parameter refers only to the MIME
+ character encoding. For example, the string "á" can be sent
+ in MIME with "charset=US-ASCII", while the raw character "Latin
+ small letter a with acute accent" cannot.
+
+ The above mechanisms are well defined and documented, and therefore
+ not further explained here. In sending a message, all the above
+ mentioned mechanisms MAY be used, and any mixture of them MAY occur
+ when sending the document via e-mail. Receiving mail user agents
+ (together with any Web browser they may use to display the document)
+ MUST be capable of handling any combinations of these mechanisms.
+
+ Also note that:
+
+ - Any documents including HTML documents that contain octet values
+ outside the 7-bit range need a content-transfer-encoding applied
+ before transmission over certain transport protocols
+ [MIME1, chapter 5].
+
+ - The MIME standard [MIME1] requires that documents of "Content-Type:
+ Text MUST be in canonical form before Content-Transfer-Encoding,
+ i.e. that line breaks are encoded as CRLFs, not as bare CRs or bare
+ LFs or something else. This is in contrast to [HTTP] where section
+ 3.6.1 allows other representations of line breaks.
+
+
+
+
+Palme & Hopmann Standards Track [Page 15]
+
+RFC 2110 MHTML March 1997
+
+
+ Note that this might cause problems with integrity checks based on
+ checksums, which might not be preserved when moving a document from
+ the HTTP to the MIME environment. If a document has to be converted
+ in such a way that a checksum integrity check becomes invalid, then
+ this integrity check header SHOULD be removed from the document.
+
+ Other sources of problems are Content-Encoding used in HTTP but not
+ allowed in MIME, and charsets that are not able to represent line
+ breaks as CRLF. A good overview of the differences between HTTP and
+ MIME with regards to "Content-Type: Text" can be found in [HTTP],
+ appendix C.
+
+ If the original document has line breaks in the canonical form
+ (CRLF), then the document SHOULD remain unconverted so that integrity
+ check sums are not invalidated.
+
+ A provider of HTML documents who wants his documents to be
+ transferable via both HTTP and SMTP without invalidating checksum
+ integrity checks, should always provide original documents in the
+ canonical form with CRLF for line breaks.
+
+ Some transport mechanisms may specify a default "charset" parameter
+ if none is supplied [HTTP, MIME1]. Because the default differs for
+ different mechanisms, when HTML is transferred through mail, the
+ charset parameter SHOULD be included, rather than relying on the
+ default.
+
+12. Security Considerations
+
+ Some Security Considerations include the potential to mail someone an
+ object, and claim that it is represented by a particular URI (by
+ giving it a Content-Location header). There can be no assurance that
+ a WWW request for that same URI would normally result in that same
+ object. It might be unsuitable to cache the data in such a way that
+ the cached data can be used for retrieval of this URI from other
+ messages or message parts than those included in the same message as
+ the Content-Location header. Because of this problem, receiving User
+ Agents SHOULD not cache this data in the same way that data that was
+ retrieved through an HTTP or FTP request might be cached.
+
+ URLs, especially File URLs, may in their name contain company-
+ internal information, which may then inadvertently be revealed to
+ recipients of documents containing such URLs.
+
+ One way of implementing messages with linked body parts is to handle
+ the linked body parts in a combined mail and WWW proxy server. The
+ mail client is only given the start body part, which it passes to a
+ web browser. This web browser requests the linked parts from the
+
+
+
+Palme & Hopmann Standards Track [Page 16]
+
+RFC 2110 MHTML March 1997
+
+
+ proxy server. If this method is used, and if the combined server is
+ used by more than one user, then methods must be employed to ensure
+ that body parts of a message to one person is not retrievable by
+ another person. Use of passwords (also known as tickets or magic
+ cookies) is one way of achieving this. Note that some caching WWW
+ proxy servers may not distinguish between cached objects from e-mail
+ and HTTP, which may be a security risk.
+
+ In addition, by allowing people to mail aggregate objects, we are
+ opening the door to other potential security problems that until now
+ were only problems for WWW users. For example, some HTML documents
+ now either themselves contain executable content (JavaScript) or
+ contain links to executable content (The "INSERT" specification,
+ Java). It would be exceedingly dangerous for a receiving User Agent
+ to execute content received through a mail message without careful
+ attention to restrictions on the capabilities of that executable
+ content.
+
+ Some WWW applications hide passwords and tickets (access tokens to
+ information which may not be available to anyone) and other sensitive
+ information in hidden fields in the web documents or in on-the-fly
+ constructed URLs. If a person gets such a document, and forwards it
+ via e-mail, the person may inadvertently disclose sensitive
+ information.
+
+13. Acknowledgments
+
+ Harald T. Alvestrand, Richard Baker, Dave Crocker, Martin J. Duerst,
+ Lewis Geer, Roy Fielding, Al Gilman, Paul Hoffman, Richard W.
+ Jesmajian, Mark K. Joseph, Greg Herlihy, Valdis Kletnieks, Daniel
+ LaLiberte, Ed Levinson, Jay Levitt, Albert Lunde, Larry Masinter,
+ Keith Moore, Gavin Nicol, Pete Resnick, Jon Smirl, Einar Stefferud,
+ Jamie Zawinski, Steve Zilles and several other people have helped us
+ with preparing this document. I alone take responsibility for any
+ errors which may still be in the document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Palme & Hopmann Standards Track [Page 17]
+
+RFC 2110 MHTML March 1997
+
+
+14. References
+
+Ref. Author, title
+--------- --------------------------------------------------------
+
+[CONDISP] R. Troost, S. Dorner: "Communicating Presentation
+ Information in Internet Messages: The
+ Content-Disposition Header", RFC 1806, June 1995.
+
+[HOSTS] R. Braden (editor): "Requirements for Internet Hosts --
+ Application and Support", STD-3, RFC 1123, October 1989.
+
+[HTML-I18N] F. Yergeau, G. Nicol, G. Adams, & M. Duerst:
+ "Internationalization of the Hypertext Markup
+ Language". RFC 2070, January 1997.
+
+[HTML2] T. Berners-Lee, D. Connolly: "Hypertext Markup Language
+ - 2.0", RFC 1866, November 1995.
+
+[HTTP] T. Berners-Lee, R. Fielding, H. Frystyk: Hypertext
+ Transfer Protocol -- HTTP/1.0. RFC 1945, May 1996.
+
+[MD5] R. Rivest: "The MD5 Message-Digest Algorithm", RFC 1321,
+ April 1992.
+
+[MIDCID] E. Levinson: "Content-ID and Message-ID Uniform
+ Resource Locators". RFC 2111, February 1997.
+
+[MIME-IMB] N. Freed & N. Borenstein: "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format of Internet Message
+ Bedies". RFC 2045, November 1996.
+
+[MIME1] N. Borenstein & N. Freed: "MIME (Multipurpose Internet
+ Mail Extensions) Part One: Mechanisms for Specifying and
+ Describing the Format of Internet Message Bodies", RFC
+ 1521, Sept 1993.
+
+[MIME2] N. Borenstein & N. Freed: "Multipurpose Internet Mail
+ Extensions (MIME) Part Two: Media Types". RFC 2046,
+ November 1996.
+
+[NEWS] M.R. Horton, R. Adams: "Standard for interchange of
+ USENET messages", RFC 1036, December 1987.
+
+
+
+
+
+
+
+
+Palme & Hopmann Standards Track [Page 18]
+
+RFC 2110 MHTML March 1997
+
+
+[PDF] Bienz, T., Cohn, R. and Meehan, J.: "Portable Document
+ Format Reference Manual, Version 1.1", Adboe Systems
+ Inc.
+
+[REL] Edward Levinson: "The MIME Multipart/Related Content-
+ Type". RFC 2112, February 1997.
+
+[RELURL] R. Fielding: "Relative Uniform Resource Locators", RFC
+ 1808, June 1995.
+
+[RFC822] D. Crocker: "Standard for the format of ARPA Internet
+ text messages." STD 11, RFC 822, August 1982.
+
+[SGML] ISO 8879. Information Processing -- Text and Office -
+ Standard Generalized Markup Language (SGML),
+ 1986. <URL:http://www.iso.ch/cate/d16387.html>
+
+[SMTP] J. Postel: "Simple Mail Transfer Protocol", STD 10, RFC
+ 821, August 1982.
+
+[URL] T. Berners-Lee, L. Masinter, M. McCahill: "Uniform
+ Resource Locators (URL)", RFC 1738, December 1994.
+
+[URLBODY] N. Freed and Keith Moore: "Definition of the URL MIME
+ External-Body Access-Type", RFC 2017, October 1996.
+
+15. Author's Address
+
+ For contacting the editors, preferably write to Jacob Palme rather
+ than Alex Hopmann.
+
+ Jacob Palme Phone: +46-8-16 16 67
+ Stockholm University and KTH Fax: +46-8-783 08 29
+ Electrum 230 E-mail: jpalme dsv su se
+ S-164 40 Kista, Sweden
+
+ Alex Hopmann E-mail: alexhop microsoft com
+ Microsoft Corporation
+ 3590 North First Street
+ Suite 300
+ San Jose
+ CA 95134
+ Working group chairman:
+
+ Einar Stefferud <stef nma com>
+
+
+
+
+
+
+Palme & Hopmann Standards Track [Page 19]
+
diff --git a/rfc/rfc2112.txt b/rfc/rfc2112.txt
new file mode 100644
index 0000000..8ef5b5f
--- /dev/null
+++ b/rfc/rfc2112.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group E. Levinson
+Request for Comments: 2112 XIson, Inc.
+Category: Standards Track March 1997
+Obsoletes: 1872
+
+
+ The MIME Multipart/Related Content-type
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Abstract
+
+ The Multipart/Related content-type provides a common mechanism for
+ representing objects that are aggregates of related MIME body parts.
+ This document defines the Multipart/Related content-type and provides
+ examples of its use.
+
+1. Introduction
+
+ Several applications of MIME, including MIME-PEM, and MIME-Macintosh
+ and other proposals, require multiple body parts that make sense only
+ in the aggregate. The present approach to these compound objects has
+ been to define specific multipart subtypes for each new object. In
+ keeping with the MIME philosophy of having one mechanism to achieve
+ the same goal for different purposes, this document describes a
+ single mechanism for such aggregate or compound objects.
+
+ The Multipart/Related content-type addresses the MIME representation
+ of compound objects. The object is categorized by a "type"
+ parameter. Additional parameters are provided to indicate a specific
+ starting body part or root and auxiliary information which may be
+ required when unpacking or processing the object.
+
+ Multipart/Related MIME entities may contain Content-Disposition
+ headers that provide suggestions for the storage and display of a
+ body part. Multipart/Related processing takes precedence over
+ Content-Disposition; the interaction between them is discussed in
+ section 4.
+
+ Responsibility for the display or processing of a Multipart/Related's
+ constituent entities rests with the application that handles the
+ compound object.
+
+
+
+Levinson Standards Track [Page 1]
+
+RFC 2112 MIME Multipart/Related Content-type March 1997
+
+
+2. Multipart/Related Registration Information
+
+ The following form is copied from RFC 1590, Appendix A.
+
+
+ To: IANA isi edu Subject: Registration of new Media Type content-
+ type/subtype
+
+ Media Type name: Multipart
+
+ Media subtype name: Related
+
+ Required parameters: Type, a media type/subtype.
+
+ Optional parameters: Start
+ Start-info
+
+ Encoding considerations: Multipart content-types cannot have
+ encodings.
+
+ Security considerations: Depends solely on the referenced type.
+
+ Published specification: RFC-REL (this document).
+
+ Person & email address to contact for further information:
+ Edward Levinson
+ 47 Clive Street
+ Metuchen, NJ 08840-1060
+ +1 908 494 1606
+ XIson cnj digex net
+
+3. Intended usage
+
+ The Multipart/Related media type is intended for compound objects
+ consisting of several inter-related body parts. For a
+ Multipart/Related object, proper display cannot be achieved by
+ individually displaying the constituent body parts. The content-type
+ of the Multipart/Related object is specified by the type parameter.
+ The "start" parameter, if given, points, via a content-ID, to the
+ body part that contains the object root. The default root is the
+ first body part within the Multipart/Related body.
+
+
+
+
+
+
+
+
+
+
+Levinson Standards Track [Page 2]
+
+RFC 2112 MIME Multipart/Related Content-type March 1997
+
+
+ The relationships among the body parts of a compound object
+ distinguishes it from other object types. These relationships are
+ often represented by links internal to the object's components that
+ reference the other components. Within a single operating
+ environment the links are often file names, such links may be
+ represented within a MIME message using content-IDs or the value of
+ some other "Content-" headers.
+
+3.1. The Type Parameter
+
+ The type parameter must be specified and its value is the MIME media
+ type of the "root" body part. It permits a MIME user agent to
+ determine the content-type without reference to the enclosed body
+ part. If the value of the type parameter and the root body part's
+ content-type differ then the User Agent's behavior is undefined.
+
+3.2. The Start Parameter
+
+ The start parameter, if given, is the content-ID of the compound
+ object's "root". If not present the "root" is the first body part in
+ the Multipart/Related entity. The "root" is the element the
+ applications processes first.
+
+3.3. The Start-Info Parameter
+
+ Additional information can be provided to an application by the
+ start-info parameter. It contains either a string or points, via a
+ content-ID, to another MIME entity in the message. A typical use
+ might be to provide additional command line parameters or a MIME
+ entity giving auxiliary information for processing the compound
+ object.
+
+ Applications that use Multipart/Related must specify the
+ interpretation of start-info. User Agents shall provide the
+ parameter's value to the processing application. Processes can
+ distinguish a start-info reference from a token or quoted-string by
+ examining the first non-white-space character, "<" indicates a
+ reference.
+
+3.4. Syntax
+
+ related-param := [ ";" "start" "=" cid ]
+ [ ";" "start-info" "="
+ ( cid-list / value ) ]
+ [ ";" "type" "=" type "/" subtype ]
+ ; order independent
+
+ cid-list := cid cid-list
+
+
+
+Levinson Standards Track [Page 3]
+
+RFC 2112 MIME Multipart/Related Content-type March 1997
+
+
+ cid := msg-id ; c.f. [822]
+
+ value := token / quoted-string ; c.f. [MIME]
+ ; value cannot begin with "<"
+
+ Note that the parameter values will usually require quoting. Msg-id
+ contains the special characters "<", ">", "@", and perhaps other
+ special characters. If msg-id contains quoted-strings, those quote
+ marks must be escaped. Similarly, the type parameter contains the
+ special character "/".
+
+4. Handling Content-Disposition Headers
+
+ Content-Disposition Headers [DISP] suggest presentation styles for
+ MIME body parts. [DISP] describes two presentation styles, called
+ the disposition type, INLINE and ATTACHMENT. These, used within a
+ multipart entity, allow the sender to suggest presentation
+ information. [DISP] also provides for an optional storage (file)
+ name. Content-Disposition headers could appear in one or more body
+ parts contained within a Multipart/Related entity.
+
+ Using Content-Disposition headers in addition to Multipart/Related
+ provides presentation information to User Agents that do not
+ recognize Multipart/Related. They will treat the multipart as
+ Multipart/Mixed and they may find the Content-Disposition information
+ useful.
+
+ With Multipart/Related however, the application processing the
+ compound object determines the presentation style for all the
+ contained parts. In that context the Content-Disposition header
+ information is redundant or even misleading. Hence, User Agents that
+ understand Multipart/Related shall ignore the disposition type within
+ a Multipart/Related body part.
+
+ It may be possible for a User Agent capable of handling both
+ Multipart/Related and Content-Disposition headers to provide the
+ invoked application the Content-Disposition header's optional
+ filename parameter to the Multipart/Related. The use of that
+ information will depend on the specific application and should be
+ specified when describing the handling of the corresponding compound
+ object. Such descriptions would be appropriate in an RFC registering
+ that object's media type.
+
+
+
+
+
+
+
+
+
+Levinson Standards Track [Page 4]
+
+RFC 2112 MIME Multipart/Related Content-type March 1997
+
+
+5. Examples
+
+5.1 Application/X-FixedRecord
+
+ The X-FixedRecord content-type consists of one or more octet-streams
+ and a list of the lengths of each record. The root, which lists the
+ record lengths of each record within the streams. The record length
+ list, type Application/X-FixedRecord, consists of a set of INTEGERs
+ in ASCII format, one per line. Each INTEGER gives the number of
+ octets from the octet-stream body part that constitute the next
+ "record".
+
+ The example below, uses a single data block.
+
+ Content-Type: Multipart/Related; boundary=example-1
+ start="<950120 aaCC XIson com>";
+ type="Application/X-FixedRecord"
+ start-info="-o ps"
+
+ --example-1
+ Content-Type: Application/X-FixedRecord
+ Content-ID: <950120 aaCC XIson com>
+
+ 25
+ 10
+ 34
+ 10
+ 25
+ 21
+ 26
+ 10
+ --example-1
+ Content-Type: Application/octet-stream
+ Content-Description: The fixed length records
+ Content-Transfer-Encoding: base64
+ Content-ID: <950120 aaCB XIson com>
+
+ T2xkIE1hY0RvbmFsZCBoYWQgYSBmYXJtCkUgSS
+ BFIEkgTwpBbmQgb24gaGlzIGZhcm0gaGUgaGFk
+ IHNvbWUgZHVja3MKRSBJIEUgSSBPCldpdGggYS
+ BxdWFjayBxdWFjayBoZXJlLAphIHF1YWNrIHF1
+ YWNrIHRoZXJlLApldmVyeSB3aGVyZSBhIHF1YW
+ NrIHF1YWNrCkUgSSBFIEkgTwo=
+
+ --example-1--
+
+
+
+
+
+
+Levinson Standards Track [Page 5]
+
+RFC 2112 MIME Multipart/Related Content-type March 1997
+
+
+5.2 Text/X-Okie
+
+ The Text/X-Okie is an invented markup language permitting the
+ inclusion of images with text. A feature of this example is the
+ inclusion of two additional body parts, both picture. They are
+ referred to internally by the encapsulated document via each
+ picture's body part content-ID. Usage of "cid:", as in this example,
+ may be useful for a variety of compound objects. It is not, however,
+ a part of the Multipart/Related specification.
+
+ Content-Type: Multipart/Related; boundary=example-2;
+ start="<950118 AEBH XIson com>"
+ type="Text/x-Okie"
+
+ --example-2
+ Content-Type: Text/x-Okie; charset=iso-8859-1;
+ declaration="<950118 AEB0 XIson com>"
+ Content-ID: <950118 AEBH XIson com>
+ Content-Description: Document
+
+ {doc}
+ This picture was taken by an automatic camera mounted ...
+ {image file=cid:<950118 AECB XIson com>}
+ {para}
+ Now this is an enlargement of the area ...
+ {image file=cid:<950118:AFDH XIson com>}
+ {/doc}
+ --example-2
+ Content-Type: image/jpeg
+ Content-ID: <950118 AFDH XIson com>
+ Content-Transfer-Encoding: BASE64
+ Content-Description: Picture A
+
+ [encoded jpeg image]
+ --example-2
+ Content-Type: image/jpeg
+ Content-ID: <950118 AECB XIson com>
+ Content-Transfer-Encoding: BASE64
+ Content-Description: Picture B
+
+ [encoded jpeg image]
+ --example-2--
+
+
+
+
+
+
+
+
+
+Levinson Standards Track [Page 6]
+
+RFC 2112 MIME Multipart/Related Content-type March 1997
+
+
+5.3 Content-Disposition
+
+ In the above example each image body part could also have a Content-
+ Disposition header. For example,
+
+ ...
+ --example-2
+ Content-Type: image/jpeg
+ Content-ID: <950118 AECB XIson com>
+ Content-Transfer-Encoding: BASE64
+ Content-Description: Picture B
+ Content-Disposition: INLINE
+
+ [encoded jpeg image]
+ --example-2--
+
+ User Agents that recognize Multipart/Related will ignore the
+ Content-Disposition header's disposition type. Other User Agents
+ will process the Multipart/Related as Multipart/Mixed and may make
+ use of that header's information.
+
+6. User Agent Requirements
+
+ User agents that do not recognize Multipart/Related shall, in
+ accordance with [MIME], treat the entire entity as Multipart/Mixed.
+ MIME User Agents that do recognize Multipart/Related entities but are
+ unable to process the given type should give the user the option of
+ suppressing the entire Multipart/Related body part shall be.
+
+ Existing MIME-capable mail user agents (MUAs) handle the existing
+ media types in a straightforward manner. For discrete media types
+ (e.g. text, image, etc.) the body of the entity can be directly
+ passed to a display process. Similarly the existing composite
+ subtypes can be reduced to handing one or more discrete types.
+ Handling Multipart/Related differs in that processing cannot be
+ reduced to handling the individual entities.
+
+ The following sections discuss what information the processing
+ application requires.
+
+ It is possible that an application specific "receiving agent" will
+ manipulate the entities for display prior to invoking actual
+ application process. Okie, above, is an example of this; it may need
+ a receiving agent to parse the document and substitute local file
+ names for the originator's file names. Other applications may just
+ require a table showing the correspondence between the local file
+ names and the originator's. The receiving agent takes responsibility
+ for such processing.
+
+
+
+Levinson Standards Track [Page 7]
+
+RFC 2112 MIME Multipart/Related Content-type March 1997
+
+
+6.1 Data Requirements
+
+ MIME-capable mail user agents (MUAs) are required to provide the
+ application:
+
+ (a) the bodies of the MIME entities and the entity Content-*
+ headers,
+
+ (b) the parameters of the Multipart/Related Content-type
+ header, and
+
+ (c) the correspondence between each body's local file name,
+ that body's header data, and, if present, the body part's
+ content-ID.
+
+6.2 Storing Multipart/Related Entities
+
+ The Multipart/Related media type will be used for objects that have
+ internal linkages between the body parts. When the objects are
+ stored the linkages may require processing by the application or its
+ receiving agent.
+
+6.3 Recursion
+
+ MIME is a recursive structure. Hence one must expect a
+ Multipart/Related entity to contain other Multipart/Related entities.
+ When a Multipart/Related entity is being processed for display or
+ storage, any enclosed Multipart/Related entities shall be processed
+ as though they were being stored.
+
+6.4 Configuration Considerations
+
+ It is suggested that MUAs that use configuration mechanisms, see
+ [CFG] for an example, refer to Multipart/Related as
+ Multipart/Related/<type>, were <type> is the value of the "type"
+ parameter.
+
+7. Security considerations
+
+ Security considerations relevant to Multipart/Related are identical
+ to those of the underlying content-type.
+
+
+
+
+
+
+
+
+
+
+Levinson Standards Track [Page 8]
+
+RFC 2112 MIME Multipart/Related Content-type March 1997
+
+
+8. Acknowledgments
+
+ This proposal is the result of conversations the author has had with
+ many people. In particular, Harald A. Alvestrand, James Clark,
+ Charles Goldfarb, Gary Houston, Ned Freed, Ray Moody, and Don
+ Stinchfield, provided both encouragement and invaluable help. The
+ author, however, take full responsibility for all errors contained in
+ this document.
+
+9. References
+
+ [822] Crocker, D., "Standard for the Format of ARPA
+ Internet Text Messages", August 1982, University
+ of Delaware, RFC 822.
+
+ [CID] E. Levinson, J. Clark, "Message/External-Body
+ Content-ID Access Type", 12/26/1995, RFC 1873
+ Levinson, E., "Message/External-Body Content-ID
+ Access Type", February 1997, RFC 2111.
+
+ [CFG] Borenstein, N., "A User Agent Configuration
+ Mechanism For Multimedia Mail Format
+ Information", September 23, 1993, RFC 1524
+
+ [DISP] R. Troost, S. Dorner, "Communicating Presentation
+ Information in Internet Messages: The Content-
+ Disposition Header", June 7, 1995, RFC 1806
+
+ [MIME] Borenstein, N. and Freed, N., "MIME (Multipurpose
+ Internet Mail Extensions): Mechanisms for
+ Specifying and Describing the Format of Internet
+ Message Bodies", June 1992, RFC 1341.
+
+9. Author's Address
+
+ Edward Levinson
+ XIson, Inc.
+ 47 Clive Street
+ Metuchen, NJ 08840-1060
+ USA
+ +1 908 549 3716
+ <XIson cnj digex com>
+
+
+
+
+
+
+
+
+
+Levinson Standards Track [Page 9]
+
diff --git a/rfc/rfc3850.txt b/rfc/rfc3850.txt
new file mode 100644
index 0000000..cdaa2ec
--- /dev/null
+++ b/rfc/rfc3850.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group B. Ramsdell, Editor
+Request for Comments: 3850 Sendmail, Inc.
+Obsoletes: 2632 July 2004
+Category: Standards Track
+
+
+ Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1
+ Certificate Handling
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004).
+
+Abstract
+
+ This document specifies conventions for X.509 certificate usage by
+ Secure/Multipurpose Internet Mail Extensions (S/MIME) agents. S/MIME
+ provides a method to send and receive secure MIME messages, and
+ certificates are an integral part of S/MIME agent processing. S/MIME
+ agents validate certificates as described in RFC 3280, the Internet
+ X.509 Public Key Infrastructure Certificate and CRL Profile. S/MIME
+ agents must meet the certificate processing requirements in this
+ document as well as those in RFC 3280.
+
+Table of Contents
+
+ 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 1.1. Definitions. . . . . . . . . . . . . . . . . . . . . . . 2
+ 1.2. Compatibility with Prior Practice of S/MIME. . . . . . . 3
+ 1.3. Terminology. . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.4. Changes Since S/MIME v3 (RFC 2632) . . . . . . . . . . . 3
+ 2. CMS Options. . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2.1 . CertificateRevocationLists . . . . . . . . . . . . . . . 4
+ 2.2. CertificateChoices . . . . . . . . . . . . . . . . . . . 4
+ 2.3. CertificateSet . . . . . . . . . . . . . . . . . . . . . 5
+ 3. Using Distinguished Names for Internet Mail . . . . . . . . . . 6
+ 4. Certificate Processing . . . . . . . . . . . . . . . . . . . . 7
+ 4.1. Certificate Revocation Lists . . . . . . . . . . . . . . 8
+ 4.2. Certification Path Validation. . . . . . . . . . . . . . 8
+ 4.3. Certificate and CRL Signing Algorithms . . . . . . . . . 9
+
+
+
+Ramsdell Standards Track [Page 1]
+
+RFC 3850 S/MIME 3.1 Certificate Handling July 2004
+
+
+ 4.4. PKIX Certificate Extensions. . . . . . . . . . . . . . . 9
+ 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 11
+ A. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+ A.1. Normative References . . . . . . . . . . . . . . . . . . 13
+ A.2. Informative References . . . . . . . . . . . . . . . . . 14
+ B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
+ C. Editor's Address . . . . . . . . . . . . . . . . . . . . . . . 15
+ Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 16
+
+1. Overview
+
+ S/MIME (Secure/Multipurpose Internet Mail Extensions), described in
+ [SMIME-MSG], provides a method to send and receive secure MIME
+ messages. Before using a public key to provide security services,
+ the S/MIME agent MUST verify that the public key is valid. S/MIME
+ agents MUST use PKIX certificates to validate public keys as
+ described in the Internet X.509 Public Key Infrastructure (PKIX)
+ Certificate and CRL Profile [KEYM]. S/MIME agents MUST meet the
+ certificate processing requirements documented in this document in
+ addition to those stated in [KEYM].
+
+ This specification is compatible with the Cryptographic Message
+ Syntax [CMS] in that it uses the data types defined by CMS. It also
+ inherits all the varieties of architectures for certificate-based key
+ management supported by CMS.
+
+1.1. Definitions
+
+ For the purposes of this document, the following definitions apply.
+
+ ASN.1: Abstract Syntax Notation One, as defined in ITU-T X.208
+ [X.208-88].
+
+ Attribute Certificate (AC): An X.509 AC is a separate structure from
+ a subject's public key X.509 Certificate. A subject may have
+ multiple X.509 ACs associated with each of its public key X.509
+ Certificates. Each X.509 AC binds one or more Attributes with one of
+ the subject's public key X.509 Certificates. The X.509 AC syntax is
+ defined in [ACAUTH].
+
+ Certificate: A type that binds an entity's name to a public key with
+ a digital signature. This type is defined in the Internet X.509
+ Public Key Infrastructure (PKIX) Certificate and CRL Profile [KEYM].
+ This type also contains the distinguished name of the certificate
+ issuer (the signer), an issuer-specific serial number, the issuer's
+ signature algorithm identifier, a validity period, and extensions
+ also defined in that document.
+
+
+
+
+Ramsdell Standards Track [Page 2]
+
+RFC 3850 S/MIME 3.1 Certificate Handling July 2004
+
+
+ Certificate Revocation List (CRL): A type that contains information
+ about certificates whose validity an issuer has prematurely revoked.
+ The information consists of an issuer name, the time of issue, the
+ next scheduled time of issue, a list of certificate serial numbers
+ and their associated revocation times, and extensions as defined in
+ [KEYM]. The CRL is signed by the issuer. The type intended by this
+ specification is the one defined in [KEYM].
+
+ Receiving agent: software that interprets and processes S/MIME CMS
+ objects, MIME body parts that contain CMS objects, or both.
+
+ Sending agent: software that creates S/MIME CMS objects, MIME body
+ parts that contain CMS objects, or both.
+
+ S/MIME agent: user software that is a receiving agent, a sending
+ agent, or both.
+
+1.2. Compatibility with Prior Practice of S/MIME
+
+ S/MIME version 3.1 agents should attempt to have the greatest
+ interoperability possible with agents for prior versions of S/MIME.
+ S/MIME version 2 is described in RFC 2311 through RFC 2315, inclusive
+ and S/MIME version 3 is described in RFC 2630 through RFC 2634
+ inclusive. RFC 2311 also has historical information about the
+ development of S/MIME.
+
+1.3. Terminology
+
+ 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 [MUSTSHOULD].
+
+1.4. Changes Since S/MIME v3 (RFC 2632)
+
+ Version 1 and Version 2 CRLs MUST be supported.
+
+ Multiple CA certificates with the same subject and public key, but
+ with overlapping validity periods, MUST be supported.
+
+ Version 2 attribute certificates SHOULD be supported, and version 1
+ attributes certificates MUST NOT be used.
+
+ The use of the MD2 digest algorithm for certificate signatures is
+ discouraged and security language added.
+
+ Clarified use of email address use in certificates. Certificates
+ that do not contain an email address have no requirements for
+ verifying the email address associated with the certificate.
+
+
+
+Ramsdell Standards Track [Page 3]
+
+RFC 3850 S/MIME 3.1 Certificate Handling July 2004
+
+
+ Receiving agents SHOULD display certificate information when
+ displaying the results of signature verification.
+
+ Receiving agents MUST NOT accept a signature made with a certificate
+ that does not have the digitalSignature or nonRepudiation bit set.
+
+ Clarifications for the interpretation of the key usage and extended
+ key usage extensions.
+
+2. CMS Options
+
+ The CMS message format allows for a wide variety of options in
+ content and algorithm support. This section puts forth a number of
+ support requirements and recommendations in order to achieve a base
+ level of interoperability among all S/MIME implementations. Most of
+ the CMS format for S/MIME messages is defined in [SMIME-MSG].
+
+2.1. CertificateRevocationLists
+
+ Receiving agents MUST support the Certificate Revocation List (CRL)
+ format defined in [KEYM]. If sending agents include CRLs in outgoing
+ messages, the CRL format defined in [KEYM] MUST be used. In all
+ cases, both v1 and v2 CRLs MUST be supported.
+
+ All agents MUST be capable of performing revocation checks using CRLs
+ as specified in [KEYM]. All agents MUST perform revocation status
+ checking in accordance with [KEYM]. Receiving agents MUST recognize
+ CRLs in received S/MIME messages.
+
+ Agents SHOULD store CRLs received in messages for use in processing
+ later messages.
+
+2.2. CertificateChoices
+
+ Receiving agents MUST support v1 X.509 and v3 X.509 identity
+ certificates as profiled in [KEYM]. End entity certificates MAY
+ include an Internet mail address, as described in section 3.
+
+ Receiving agents SHOULD support X.509 version 2 attribute
+ certificates. See [ACAUTH] for details about the profile for
+ attribute certificates.
+
+2.2.1. Historical Note About CMS Certificates
+
+ The CMS message format supports a choice of certificate formats for
+ public key content types: PKIX, PKCS #6 Extended Certificates [PKCS6]
+ and PKIX Attribute Certificates.
+
+
+
+
+Ramsdell Standards Track [Page 4]
+
+RFC 3850 S/MIME 3.1 Certificate Handling July 2004
+
+
+ The PKCS #6 format is not in widespread use. In addition, PKIX
+ certificate extensions address much of the same functionality and
+ flexibility as was intended in the PKCS #6. Thus, sending and
+ receiving agents MUST NOT use PKCS #6 extended certificates.
+
+ X.509 version 1 attribute certificates are also not widely
+ implemented, and have been superseded with version 2 attribute
+ certificates. Sending agents MUST NOT send version 1 attribute
+ certificates.
+
+2.3. CertificateSet
+
+ Receiving agents MUST be able to handle an arbitrary number of
+ certificates of arbitrary relationship to the message sender and to
+ each other in arbitrary order. In many cases, the certificates
+ included in a signed message may represent a chain of certification
+ from the sender to a particular root. There may be, however,
+ situations where the certificates in a signed message may be
+ unrelated and included for convenience.
+
+ Sending agents SHOULD include any certificates for the user's public
+ key(s) and associated issuer certificates. This increases the
+ likelihood that the intended recipient can establish trust in the
+ originator's public key(s). This is especially important when
+ sending a message to recipients that may not have access to the
+ sender's public key through any other means or when sending a signed
+ message to a new recipient. The inclusion of certificates in
+ outgoing messages can be omitted if S/MIME objects are sent within a
+ group of correspondents that has established access to each other's
+ certificates by some other means such as a shared directory or manual
+ certificate distribution. Receiving S/MIME agents SHOULD be able to
+ handle messages without certificates using a database or directory
+ lookup scheme.
+
+ A sending agent SHOULD include at least one chain of certificates up
+ to, but not including, a Certificate Authority (CA) that it believes
+ that the recipient may trust as authoritative. A receiving agent
+ MUST be able to handle an arbitrarily large number of certificates
+ and chains.
+
+ Agents MAY send CA certificates, that is, certificates which can be
+ considered the "root" of other chains, and which MAY be self-signed.
+ Note that receiving agents SHOULD NOT simply trust any self-signed
+ certificates as valid CAs, but SHOULD use some other mechanism to
+ determine if this is a CA that should be trusted. Also note that
+ when certificates contain DSA public keys the parameters may be
+ located in the root certificate. This would require that the
+ recipient possess both the end-entity certificate as well as the root
+
+
+
+Ramsdell Standards Track [Page 5]
+
+RFC 3850 S/MIME 3.1 Certificate Handling July 2004
+
+
+ certificate to perform a signature verification, and is a valid
+ example of a case where transmitting the root certificate may be
+ required.
+
+ Receiving agents MUST support chaining based on the distinguished
+ name fields. Other methods of building certificate chains MAY be
+ supported.
+
+ Receiving agents SHOULD support the decoding of X.509 attribute
+ certificates included in CMS objects. All other issues regarding the
+ generation and use of X.509 attribute certificates are outside of the
+ scope of this specification. One specification that addresses
+ attribute certificate use is defined in [SECLABEL].
+
+3. Using Distinguished Names for Internet Mail
+
+ End-entity certificates MAY contain an Internet mail address as
+ described in [RFC-2822]. The address must be an "addr-spec" as
+ defined in Section 3.4.1 of that specification. The email address
+ SHOULD be in the subjectAltName extension, and SHOULD NOT be in the
+ subject distinguished name.
+
+ Receiving agents MUST recognize and accept certificates that contain
+ no email address. Agents are allowed to provide an alternative
+ mechanism for associating an email address with a certificate that
+ does not contain an email address, such as through the use of the
+ agent's address book, if available. Receiving agents MUST recognize
+ email addresses in the subjectAltName field. Receiving agents MUST
+ recognize email addresses in the Distinguished Name field in the PKCS
+ #9 [PKCS9] emailAddress attribute:
+
+ pkcs-9-at-emailAddress OBJECT IDENTIFIER ::=
+ {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1 }
+
+ Note that this attribute MUST be encoded as IA5String.
+
+ Sending agents SHOULD make the address in the From or Sender header
+ in a mail message match an Internet mail address in the signer's
+ certificate. Receiving agents MUST check that the address in the
+ From or Sender header of a mail message matches an Internet mail
+ address, if present, in the signer's certificate, if mail addresses
+ are present in the certificate. A receiving agent SHOULD provide
+ some explicit alternate processing of the message if this comparison
+ fails, which may be to display a message that shows the recipient the
+ addresses in the certificate or other certificate details.
+
+
+
+
+
+
+Ramsdell Standards Track [Page 6]
+
+RFC 3850 S/MIME 3.1 Certificate Handling July 2004
+
+
+ A receiving agent SHOULD display a subject name or other certificate
+ details when displaying an indication of successful or unsuccessful
+ signature verification.
+
+ All subject and issuer names MUST be populated (i.e., not an empty
+ SEQUENCE) in S/MIME-compliant X.509 identity certificates, except
+ that the subject DN in a user's (i.e., end-entity) certificate MAY be
+ an empty SEQUENCE in which case the subjectAltName extension will
+ include the subject's identifier and MUST be marked as critical.
+
+4. Certificate Processing
+
+ A receiving agent needs to provide some certificate retrieval
+ mechanism in order to gain access to certificates for recipients of
+ digital envelopes. There are many ways to implement certificate
+ retrieval mechanisms. X.500 directory service is an excellent
+ example of a certificate retrieval-only mechanism that is compatible
+ with classic X.500 Distinguished Names. Another method under
+ consideration by the IETF is to provide certificate retrieval
+ services as part of the existing Domain Name System (DNS). Until
+ such mechanisms are widely used, their utility may be limited by the
+ small number of correspondent's certificates that can be retrieved.
+ At a minimum, for initial S/MIME deployment, a user agent could
+ automatically generate a message to an intended recipient requesting
+ that recipient's certificate in a signed return message.
+
+ Receiving and sending agents SHOULD also provide a mechanism to allow
+ a user to "store and protect" certificates for correspondents in such
+ a way so as to guarantee their later retrieval. In many
+ environments, it may be desirable to link the certificate
+ retrieval/storage mechanisms together in some sort of certificate
+ database. In its simplest form, a certificate database would be
+ local to a particular user and would function in a similar way as an
+ "address book" that stores a user's frequent correspondents. In this
+ way, the certificate retrieval mechanism would be limited to the
+ certificates that a user has stored (presumably from incoming
+ messages). A comprehensive certificate retrieval/storage solution
+ may combine two or more mechanisms to allow the greatest flexibility
+ and utility to the user. For instance, a secure Internet mail agent
+ may resort to checking a centralized certificate retrieval mechanism
+ for a certificate if it can not be found in a user's local
+ certificate storage/retrieval database.
+
+ Receiving and sending agents SHOULD provide a mechanism for the
+ import and export of certificates, using a CMS certs-only message.
+ This allows for import and export of full certificate chains as
+ opposed to just a single certificate. This is described in [SMIME-
+ MSG].
+
+
+
+Ramsdell Standards Track [Page 7]
+
+RFC 3850 S/MIME 3.1 Certificate Handling July 2004
+
+
+ Agents MUST handle multiple valid Certification Authority (CA)
+ certificates containing the same subject name and the same public
+ keys but with overlapping validity intervals.
+
+4.1. Certificate Revocation Lists
+
+ In general, it is always better to get the latest CRL information
+ from a CA than to get information stored away from incoming messages.
+ A receiving agent SHOULD have access to some certificate revocation
+ list (CRL) retrieval mechanism in order to gain access to certificate
+ revocation information when validating certification paths. A
+ receiving or sending agent SHOULD also provide a mechanism to allow a
+ user to store incoming certificate revocation information for
+ correspondents in such a way so as to guarantee its later retrieval.
+
+ Receiving and sending agents SHOULD retrieve and utilize CRL
+ information every time a certificate is verified as part of a
+ certification path validation even if the certificate was already
+ verified in the past. However, in many instances (such as off-line
+ verification) access to the latest CRL information may be difficult
+ or impossible. The use of CRL information, therefore, may be
+ dictated by the value of the information that is protected. The
+ value of the CRL information in a particular context is beyond the
+ scope of this specification but may be governed by the policies
+ associated with particular certification paths.
+
+ All agents MUST be capable of performing revocation checks using CRLs
+ as specified in [KEYM]. All agents MUST perform revocation status
+ checking in accordance with [KEYM]. Receiving agents MUST recognize
+ CRLs in received S/MIME messages.
+
+4.2. Certification Path Validation
+
+ In creating a user agent for secure messaging, certificate, CRL, and
+ certification path validation SHOULD be highly automated while still
+ acting in the best interests of the user. Certificate, CRL, and path
+ validation MUST be performed as per [KEYM] when validating a
+ correspondent's public key. This is necessary before using a public
+ key to provide security services such as: verifying a signature;
+ encrypting a content-encryption key (ex: RSA); or forming a pairwise
+ symmetric key (ex: Diffie-Hellman) to be used to encrypt or decrypt a
+ content-encryption key.
+
+ Certificates and CRLs are made available to the path validation
+ procedure in two ways: a) incoming messages, and b) certificate and
+ CRL retrieval mechanisms. Certificates and CRLs in incoming messages
+ are not required to be in any particular order nor are they required
+ to be in any way related to the sender or recipient of the message
+
+
+
+Ramsdell Standards Track [Page 8]
+
+RFC 3850 S/MIME 3.1 Certificate Handling July 2004
+
+
+ (although in most cases they will be related to the sender).
+ Incoming certificates and CRLs SHOULD be cached for use in path
+ validation and optionally stored for later use. This temporary
+ certificate and CRL cache SHOULD be used to augment any other
+ certificate and CRL retrieval mechanisms for path validation on
+ incoming signed messages.
+
+4.3. Certificate and CRL Signing Algorithms
+
+ Certificates and Certificate Revocation Lists (CRLs) are signed by
+ the certificate issuer. A receiving agent MUST be capable of
+ verifying the signatures on certificates and CRLs made with
+ id-dsa-with-sha1 [CMSALG].
+
+ A receiving agent MUST be capable of verifying the signatures on
+ certificates and CRLs made with md5WithRSAEncryption and
+ sha1WithRSAEncryption signature algorithms with key sizes from 512
+ bits to 2048 bits described in [CMSALG].
+
+ Because of the security issues surrounding MD2 [RC95], and in light
+ of current use, md2WithRSAEncryption MAY be supported.
+
+4.4. PKIX Certificate Extensions
+
+ PKIX describes an extensible framework in which the basic certificate
+ information can be extended and how such extensions can be used to
+ control the process of issuing and validating certificates. The PKIX
+ Working Group has ongoing efforts to identify and create extensions
+ which have value in particular certification environments. Further,
+ there are active efforts underway to issue PKIX certificates for
+ business purposes. This document identifies the minimum required set
+ of certificate extensions which have the greatest value in the S/MIME
+ environment. The syntax and semantics of all the identified
+ extensions are defined in [KEYM].
+
+ Sending and receiving agents MUST correctly handle the basic
+ constraints, key usage, authority key identifier, subject key
+ identifier, and subject alternative names certificate extensions when
+ they appear in end-entity and CA certificates. Some mechanism SHOULD
+ exist to gracefully handle other certificate extensions when they
+ appear in end-entity or CA certificates.
+
+ Certificates issued for the S/MIME environment SHOULD NOT contain any
+ critical extensions (extensions that have the critical field set to
+ TRUE) other than those listed here. These extensions SHOULD be
+ marked as non-critical unless the proper handling of the extension is
+
+
+
+
+
+Ramsdell Standards Track [Page 9]
+
+RFC 3850 S/MIME 3.1 Certificate Handling July 2004
+
+
+ deemed critical to the correct interpretation of the associated
+ certificate. Other extensions may be included, but those extensions
+ SHOULD NOT be marked as critical.
+
+ Interpretation and syntax for all extensions MUST follow [KEYM],
+ unless otherwise specified here.
+
+4.4.1. Basic Constraints Certificate Extension
+
+ The basic constraints extension serves to delimit the role and
+ position that an issuing authority or end-entity certificate plays in
+ a certification path.
+
+ For example, certificates issued to CAs and subordinate CAs contain a
+ basic constraint extension that identifies them as issuing authority
+ certificates. End-entity certificates contain an extension that
+ constrains the certificate from being an issuing authority
+ certificate.
+
+ Certificates SHOULD contain a basicConstraints extension in CA
+ certificates, and SHOULD NOT contain that extension in end entity
+ certificates.
+
+4.4.2. Key Usage Certificate Extension
+
+ The key usage extension serves to limit the technical purposes for
+ which a public key listed in a valid certificate may be used.
+ Issuing authority certificates may contain a key usage extension that
+ restricts the key to signing certificates, certificate revocation
+ lists and other data.
+
+ For example, a certification authority may create subordinate issuer
+ certificates which contain a key usage extension which specifies that
+ the corresponding public key can be used to sign end user
+ certificates and sign CRLs.
+
+ If a key usage extension is included in a PKIX certificate, then it
+ MUST be marked as critical.
+
+ S/MIME receiving agents MUST NOT accept the signature of a message if
+ it was verified using a certificate which contains the key usage
+ extension without either the digitalSignature or nonRepudiation bit
+ set. Sometimes S/MIME is used as a secure message transport for
+ applications beyond interpersonal messaging. In such cases, the
+ S/MIME-enabled application can specify additional requirements
+ concerning the digitalSignature or nonRepudiation bits within this
+ extension.
+
+
+
+
+Ramsdell Standards Track [Page 10]
+
+RFC 3850 S/MIME 3.1 Certificate Handling July 2004
+
+
+ If the key usage extension is not specified, receiving clients MUST
+ presume that the digitalSignature and nonRepudiation bits are set.
+
+4.4.3. Subject Alternative Name Extension
+
+ The subject alternative name extension is used in S/MIME as the
+ preferred means to convey the RFC-2822 email address(es) that
+ correspond(s) to the entity for this certificate. Any RFC-2822 email
+ addresses present MUST be encoded using the rfc822Name CHOICE of the
+ GeneralName type. Since the SubjectAltName type is a SEQUENCE OF
+ GeneralName, multiple RFC-2822 email addresses MAY be present.
+
+4.4.4. Extended Key Usage Extension
+
+ The extended key usage extension also serves to limit the technical
+ purposes for which a public key listed in a valid certificate may be
+ used. The set of technical purposes for the certificate therefore
+ are the intersection of the uses indicated in the key usage and
+ extended key usage extensions.
+
+ For example, if the certificate contains a key usage extension
+ indicating digital signature and an extended key usage extension
+ which includes the email protection OID, then the certificate may be
+ used for signing but not encrypting S/MIME messages. If the
+ certificate contains a key usage extension indicating digital
+ signature, but no extended key usage extension then the certificate
+ may also be used to sign but not encrypt S/MIME messages.
+
+ If the extended key usage extension is present in the certificate
+ then interpersonal message S/MIME receiving agents MUST check that it
+ contains either the emailProtection or the anyExtendedKeyUsage OID as
+ defined in [KEYM]. S/MIME uses other than interpersonal messaging
+ MAY require the explicit presence of the extended key usage extension
+ or other OIDs to be present in the extension or both.
+
+5. Security Considerations
+
+ All of the security issues faced by any cryptographic application
+ must be faced by a S/MIME agent. Among these issues are protecting
+ the user's private key, preventing various attacks, and helping the
+ user avoid mistakes such as inadvertently encrypting a message for
+ the wrong recipient. The entire list of security considerations is
+ beyond the scope of this document, but some significant concerns are
+ listed here.
+
+ When processing certificates, there are many situations where the
+ processing might fail. Because the processing may be done by a user
+ agent, a security gateway, or other program, there is no single way
+
+
+
+Ramsdell Standards Track [Page 11]
+
+RFC 3850 S/MIME 3.1 Certificate Handling July 2004
+
+
+ to handle such failures. Just because the methods to handle the
+ failures has not been listed, however, the reader should not assume
+ that they are not important. The opposite is true: if a certificate
+ is not provably valid and associated with the message, the processing
+ software should take immediate and noticeable steps to inform the end
+ user about it.
+
+ Some of the many places where signature and certificate checking
+ might fail include:
+
+ - no Internet mail addresses in a certificate matches the sender of
+ a message, if the certificate contains at least one mail address
+ - no certificate chain leads to a trusted CA
+ - no ability to check the CRL for a certificate
+ - an invalid CRL was received
+ - the CRL being checked is expired
+ - the certificate is expired
+ - the certificate has been revoked
+
+ There are certainly other instances where a certificate may be
+ invalid, and it is the responsibility of the processing software to
+ check them all thoroughly, and to decide what to do if the check
+ fails.
+
+ At the Selected Areas in Cryptography '95 conference in May 1995,
+ Rogier and Chauvaud presented an attack on MD2 that can nearly find
+ collisions [RC95]. Collisions occur when one can find two different
+ messages that generate the same message digest. A checksum operation
+ in MD2 is the only remaining obstacle to the success of the attack.
+ For this reason, the use of MD2 for new applications is discouraged.
+ It is still reasonable to use MD2 to verify existing signatures, as
+ the ability to find collisions in MD2 does not enable an attacker to
+ find new messages having a previously computed hash value.
+
+ It is possible for there to be multiple unexpired CRLs for a CA. If
+ an agent is consulting CRLs for certificate validation, it SHOULD
+ make sure that the most recently issued CRL for that CA is consulted,
+ since an S/MIME message sender could deliberately include an older
+ unexpired CRL in an S/MIME message. This older CRL might not include
+ recent revoked certificates, which might lead an agent to accept a
+ certificate that has been revoked in a subsequent CRL.
+
+ When determining the time for a certificate validity check, agents
+ have to be careful to use a reliable time. Unless it is from a
+ trusted agent, this time MUST NOT be the SigningTime attribute found
+ in an S/MIME message. For most sending agents, the SigningTime
+ attribute could be deliberately set to direct the receiving agent to
+
+
+
+
+Ramsdell Standards Track [Page 12]
+
+RFC 3850 S/MIME 3.1 Certificate Handling July 2004
+
+
+ check a CRL that could have out-of-date revocation status for a
+ certificate, or cause an improper result when checking the Validity
+ field of a certificate.
+
+A. References
+
+A.1. Normative References
+
+ [ACAUTH] Farrell, S. and R. Housley, "An Internet Attribute
+ Certificate Profile for Authorization", RFC 3281, April
+ 2002.
+
+ [CMS] Housely, R., "Cryptographic Message Syntax (CMS)", RFC
+ 3852, July 2004.
+
+ [CMSALG] Housley, R., "Cryptographic Message Syntax (CMS)
+ Algorithms", RFC 3370, August 2002.
+
+ [KEYM] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
+ X.509 Public Key Infrastructure Certificate and
+ Certificate Revocation List (CRL) Profile", RFC 3280,
+ April 2002.
+
+ [KEYMALG] Bassham, L., Polk, W., and R. Housley, "Algorithms and
+ Identifiers for the Internet X.509 Public Key
+ Infrastructure Certificate and Certificate Revocation
+ List (CRL) Profile", RFC 3279, April 2002.
+
+ [MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [PKCS9] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object
+ Classes and Attribute Types Version 2.0", RFC 2985,
+ November 2000.
+
+ [RFC-2822], Resnick, P., "Internet Message Format", RFC 2822, April
+ 2001.
+
+ [SMIME-MSG] Ramsdell, B., Ed., "S/MIME Version 3.1 Message
+ Specification", RFC 3851, July 2004.
+
+ [x.208-88] ITU-T. Recommendation X.208: Specification of Abstract
+ Syntax Notation One (ASN.1). 1988.
+
+
+
+
+
+
+
+
+Ramsdell Standards Track [Page 13]
+
+RFC 3850 S/MIME 3.1 Certificate Handling July 2004
+
+
+A.2. Informative References
+
+ [CERTV2] Dusse, S., Hoffman, P., Ramsdell, B., and J. Weinstein,
+ "S/MIME Version 2 Certificate Handling", RFC 2312, March
+ 1998.
+
+ [PKCS6] RSA Laboratories, "PKCS #6: Extended-Certificate Syntax
+ Standard", November 1993.
+
+ [RC95] Rogier, N. and Chauvaud, P., "The compression function
+ of MD2 is not collision free," Presented at Selected
+ Areas in Cryptography '95, May 1995.
+
+ [SECLABEL] Nicolls, W., "Implementing Company Classification Policy
+ with the S/MIME Security Label", RFC 3114, May 2002.
+
+ [X.500] ITU-T Recommendation X.500 (1997) | ISO/IEC 9594-1:1997,
+ Information technology - Open Systems Interconnection -
+ The Directory: Overview of concepts, models and
+ services.
+
+ [X.501] ITU-T Recommendation X.501 (1997) | ISO/IEC 9594-2:1997,
+ Information technology - Open Systems Interconnection -
+ The Directory: Models.
+
+ [X.509] ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1997,
+ Information technology - Open Systems Interconnection -
+ The Directory: Authentication framework.
+
+ [X.520] ITU-T Recommendation X.520 (1997) | ISO/IEC 9594-6:1997,
+ Information technology - Open Systems Interconnection -
+ The Directory: Selected attribute types.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ramsdell Standards Track [Page 14]
+
+RFC 3850 S/MIME 3.1 Certificate Handling July 2004
+
+
+B. Acknowledgements
+
+ Many thanks go out to the other authors of the S/MIME v2 RFC: Steve
+ Dusse, Paul Hoffman and Jeff Weinstein. Without v2, there wouldn't
+ be a v3.
+
+ A number of the members of the S/MIME Working Group have also worked
+ very hard and contributed to this document. Any list of people is
+ doomed to omission and for that I apologize. In alphabetical order,
+ the following people stand out in my mind due to the fact that they
+ made direct contributions to this document.
+
+ Bill Flanigan
+ Trevor Freeman
+ Elliott Ginsburg
+ Paul Hoffman
+ Russ Housley
+ David P. Kemp
+ Michael Myers
+ John Pawling
+ Denis Pinkas
+ Jim Schaad
+
+C. Editor's Address
+
+ Blake Ramsdell
+ Sendmail, Inc.
+ 704 228th Ave NE #775
+ Sammamish, WA 98074
+
+ EMail: blake sendmail com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ramsdell Standards Track [Page 15]
+
+RFC 3850 S/MIME 3.1 Certificate Handling July 2004
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at ietf-
+ ipr ietf org
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+Ramsdell Standards Track [Page 16]
+
diff --git a/rfc/rfc3851.txt b/rfc/rfc3851.txt
new file mode 100644
index 0000000..1c9843d
--- /dev/null
+++ b/rfc/rfc3851.txt
@@ -0,0 +1,2019 @@
+
+
+
+
+
+
+Network Working Group B. Ramsdell, Editor
+Request for Comments: 3851 Sendmail, Inc.
+Obsoletes: 2633 July 2004
+Category: Standards Track
+
+
+ Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1
+ Message Specification
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004).
+
+Abstract
+
+ This document defines Secure/Multipurpose Internet Mail Extensions
+ (S/MIME) version 3.1. S/MIME provides a consistent way to send and
+ receive secure MIME data. Digital signatures provide authentication,
+ message integrity, and non-repudiation with proof of origin.
+ Encryption provides data confidentiality. Compression can be used to
+ reduce data size. This document obsoletes RFC 2633.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 1.1. Specification Overview . . . . . . . . . . . . . . . . . 3
+ 1.2. Terminology. . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.3. Definitions. . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.4. Compatibility with Prior Practice of S/MIME. . . . . . . 5
+ 1.5. Changes Since S/MIME v3. . . . . . . . . . . . . . . . . 5
+ 2. CMS Options. . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 2.1. DigestAlgorithmIdentifier. . . . . . . . . . . . . . . . 5
+ 2.2. SignatureAlgorithmIdentifier . . . . . . . . . . . . . . 6
+ 2.3. KeyEncryptionAlgorithmIdentifier . . . . . . . . . . . . 6
+ 2.4. General Syntax . . . . . . . . . . . . . . . . . . . . . 6
+ 2.5. Attributes and the SignerInfo Type . . . . . . . . . . . 7
+ 2.6. SignerIdentifier SignerInfo Type . . . . . . . . . . . . 11
+ 2.7. ContentEncryptionAlgorithmIdentifier . . . . . . . . . . 12
+ 3. Creating S/MIME Messages . . . . . . . . . . . . . . . . . . . 14
+
+
+
+
+Ramsdell Standards Track [Page 1]
+
+RFC 3851 S/MIME 3.1 Message Specification July 2004
+
+
+ 3.1. Preparing the MIME Entity for Signing, Enveloping
+ or Compressing . . . . . . . . . . . . . . . . . . . . . 14
+ 3.2. The application/pkcs7-mime Type. . . . . . . . . . . . . 19
+ 3.3. Creating an Enveloped-only Message . . . . . . . . . . . 21
+ 3.4. Creating a Signed-only Message . . . . . . . . . . . . . 22
+ 3.5. Creating an Compressed-only Message. . . . . . . . . . . 26
+ 3.6. Multiple Operations. . . . . . . . . . . . . . . . . . . 27
+ 3.7. Creating a Certificate Management Messagetoc . . . . . . 27
+ 3.8. Registration Requests. . . . . . . . . . . . . . . . . . 28
+ 3.9. Identifying an S/MIME Message. . . . . . . . . . . . . . 28
+ 4. Certificate Processing . . . . . . . . . . . . . . . . . . . . 29
+ 4.1. Key Pair Generation. . . . . . . . . . . . . . . . . . . 29
+ 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 29
+ A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . . 31
+ B. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
+ B.1. Normative References . . . . . . . . . . . . . . . . . . 32
+ B.2. Informative References . . . . . . . . . . . . . . . . . 34
+ C. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
+ D. Editor's Address . . . . . . . . . . . . . . . . . . . . . . . 35
+ Full Copyright Statement . . . . . . . . . . . . . . . . . . . 36
+
+1. Introduction
+
+ S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a
+ consistent way to send and receive secure MIME data. Based on the
+ popular Internet MIME standard, S/MIME provides the following
+ cryptographic security services for electronic messaging
+ applications: authentication, message integrity and non-repudiation
+ of origin (using digital signatures), and data confidentiality (using
+ encryption).
+
+ S/MIME can be used by traditional mail user agents (MUAs) to add
+ cryptographic security services to mail that is sent, and to
+ interpret cryptographic security services in mail that is received.
+ However, S/MIME is not restricted to mail; it can be used with any
+ transport mechanism that transports MIME data, such as HTTP. As
+ such, S/MIME takes advantage of the object-based features of MIME and
+ allows secure messages to be exchanged in mixed-transport systems.
+
+ Further, S/MIME can be used in automated message transfer agents that
+ use cryptographic security services that do not require any human
+ intervention, such as the signing of software-generated documents and
+ the encryption of FAX messages sent over the Internet.
+
+
+
+
+
+
+
+
+Ramsdell Standards Track [Page 2]
+
+RFC 3851 S/MIME 3.1 Message Specification July 2004
+
+
+1.1. Specification Overview
+
+ This document describes a protocol for adding cryptographic signature
+ and encryption services to MIME data. The MIME standard [MIME-SPEC]
+ provides a general structure for the content type of Internet
+ messages and allows extensions for new content type applications.
+
+ This specification defines how to create a MIME body part that has
+ been cryptographically enhanced according to CMS [CMS], which is
+ derived from PKCS #7 [PKCS-7]. This specification also defines the
+ application/pkcs7-mime MIME type that can be used to transport those
+ body parts.
+
+ This document also discusses how to use the multipart/signed MIME
+ type defined in [MIME-SECURE] to transport S/MIME signed messages.
+ multipart/signed is used in conjunction with the application/pkcs7-
+ signature MIME type, which is used to transport a detached S/MIME
+ signature.
+
+ In order to create S/MIME messages, an S/MIME agent MUST follow the
+ specifications in this document, as well as the specifications listed
+ in the Cryptographic Message Syntax document [CMS] [CMSALG].
+
+ Throughout this specification, there are requirements and
+ recommendations made for how receiving agents handle incoming
+ messages. There are separate requirements and recommendations for
+ how sending agents create outgoing messages. In general, the best
+ strategy is to "be liberal in what you receive and conservative in
+ what you send". Most of the requirements are placed on the handling
+ of incoming messages while the recommendations are mostly on the
+ creation of outgoing messages.
+
+ The separation for requirements on receiving agents and sending
+ agents also derives from the likelihood that there will be S/MIME
+ systems that involve software other than traditional Internet mail
+ clients. S/MIME can be used with any system that transports MIME
+ data. An automated process that sends an encrypted message might not
+ be able to receive an encrypted message at all, for example. Thus,
+ the requirements and recommendations for the two types of agents are
+ listed separately when appropriate.
+
+1.2. Terminology
+
+ 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 [MUSTSHOULD].
+
+
+
+
+
+Ramsdell Standards Track [Page 3]
+
+RFC 3851 S/MIME 3.1 Message Specification July 2004
+
+
+1.3. Definitions
+
+ For the purposes of this specification, the following definitions
+ apply.
+
+ ASN.1: Abstract Syntax Notation One, as defined in CCITT X.208
+ [X.208-88].
+
+ BER: Basic Encoding Rules for ASN.1, as defined in CCITT X.209
+ [X.209-88].
+
+ Certificate: A type that binds an entity's name to a public key with
+ a digital signature.
+
+ DER: Distinguished Encoding Rules for ASN.1, as defined in CCITT
+ X.509 [X.509-88].
+
+ 7-bit data: Text data with lines less than 998 characters long, where
+ none of the characters have the 8th bit set, and there are no NULL
+ characters. <CR> and <LF> occur only as part of a <CR><LF> end of
+ line delimiter.
+
+ 8-bit data: Text data with lines less than 998 characters, and where
+ none of the characters are NULL characters. <CR> and <LF> occur only
+ as part of a <CR><LF> end of line delimiter.
+
+ Binary data: Arbitrary data.
+
+ Transfer Encoding: A reversible transformation made on data so 8-bit
+ or binary data can be sent via a channel that only transmits 7-bit
+ data.
+
+ Receiving agent: Software that interprets and processes S/MIME CMS
+ objects, MIME body parts that contain CMS content types, or both.
+
+ Sending agent: Software that creates S/MIME CMS content types, MIME
+ body parts that contain CMS content types, or both.
+
+ S/MIME agent: User software that is a receiving agent, a sending
+ agent, or both.
+
+
+
+
+
+
+
+
+
+
+
+Ramsdell Standards Track [Page 4]
+
+RFC 3851 S/MIME 3.1 Message Specification July 2004
+
+
+1.4. Compatibility with Prior Practice of S/MIME
+
+ S/MIME version 3.1 agents SHOULD attempt to have the greatest
+ interoperability possible with agents for prior versions of S/MIME.
+ S/MIME version 2 is described in RFC 2311 through RFC 2315, inclusive
+ and S/MIME version 3 is described in RFC 2630 through RFC 2634
+ inclusive. RFC 2311 also has historical information about the
+ development of S/MIME.
+
+1.5. Changes Since S/MIME v3
+
+ The RSA public key algorithm was changed to a MUST implement key
+ wrapping algorithm, and the Diffie-Hellman algorithm changed to a
+ SHOULD implement.
+
+ The AES symmetric encryption algorithm has been included as a SHOULD
+ implement.
+
+ The RSA public key algorithm was changed to a MUST implement
+ signature algorithm.
+
+ Ambiguous language about the use of "empty" SignedData messages to
+ transmit certificates was clarified to reflect that transmission of
+ certificate revocation lists is also allowed.
+
+ The use of binary encoding for some MIME entities is now explicitly
+ discussed.
+
+ Header protection through the use of the message/rfc822 MIME type has
+ been added.
+
+ Use of the CompressedData CMS type is allowed, along with required
+ MIME type and file extension additions.
+
+2. CMS Options
+
+ CMS allows for a wide variety of options in content and algorithm
+ support. This section puts forth a number of support requirements
+ and recommendations in order to achieve a base level of
+ interoperability among all S/MIME implementations. [CMSALG] provides
+ additional details regarding the use of the cryptographic algorithms.
+
+2.1. DigestAlgorithmIdentifier
+
+ Sending and receiving agents MUST support SHA-1 [CMSALG]. Receiving
+ agents SHOULD support MD5 [CMSALG] for the purpose of providing
+ backward compatibility with MD5-digested S/MIME v2 SignedData
+ objects.
+
+
+
+Ramsdell Standards Track [Page 5]
+
+RFC 3851 S/MIME 3.1 Message Specification July 2004
+
+
+2.2. SignatureAlgorithmIdentifier
+
+ Receiving agents MUST support id-dsa-with-sha1 defined in [CMSALG].
+ The algorithm parameters MUST be absent (not encoded as NULL).
+ Receiving agents MUST support rsaEncryption, defined in [CMSALG].
+
+ Sending agents MUST support either id-dsa-with-sha1 or rsaEncryption.
+
+ If using rsaEncryption, sending and receiving agents MUST support the
+ digest algorithms in section 2.1 as specified.
+
+ Note that S/MIME v3 clients might only implement signing or signature
+ verification using id-dsa-with-sha1, and might also use id-dsa as an
+ AlgorithmIdentifier in this field. Receiving clients SHOULD
+ recognize id-dsa as equivalent to id-dsa-with-sha1, and sending
+ clients MUST use id-dsa-with-sha1 if using that algorithm. Also note
+ that S/MIME v2 clients are only required to verify digital signatures
+ using the rsaEncryption algorithm with SHA-1 or MD5, and might not
+ implement id-dsa-with-sha1 or id-dsa at all.
+
+2.3. KeyEncryptionAlgorithmIdentifier
+
+ Sending and receiving agents MUST support rsaEncryption, defined in
+ [CMSALG].
+
+ Sending and receiving agents SHOULD support Diffie-Hellman defined in
+ [CMSALG], using the ephemeral-static mode.
+
+ Note that S/MIME v3 clients might only implement key encryption and
+ decryption using the Diffie-Hellman algorithm. Also note that S/MIME
+ v2 clients are only capable of decrypting content-encryption keys
+ using the rsaEncryption algorithm.
+
+2.4. General Syntax
+
+ There are several CMS content types. Of these, only the Data,
+ SignedData, EnvelopedData, and CompressedData content types are
+ currently used for S/MIME.
+
+2.4.1. Data Content Type
+
+ Sending agents MUST use the id-data content type identifier to
+ identify the "inner" MIME message content. For example, when
+ applying a digital signature to MIME data, the CMS SignedData
+ encapContentInfo eContentType MUST include the id-data object
+ identifier and the MIME content MUST be stored in the SignedData
+ encapContentInfo eContent OCTET STRING (unless the sending agent is
+ using multipart/signed, in which case the eContent is absent, per
+
+
+
+Ramsdell Standards Track [Page 6]
+
+RFC 3851 S/MIME 3.1 Message Specification July 2004
+
+
+ section 3.4.3 of this document). As another example, when applying
+ encryption to MIME data, the CMS EnvelopedData encryptedContentInfo
+ contentType MUST include the id-data object identifier and the
+ encrypted MIME content MUST be stored in the EnvelopedData
+ encryptedContentInfo encryptedContent OCTET STRING.
+
+2.4.2. SignedData Content Type
+
+ Sending agents MUST use the SignedData content type to apply a
+ digital signature to a message or, in a degenerate case where there
+ is no signature information, to convey certificates. Applying a
+ signature to a message provides authentication, message integrity,
+ and non-repudiation of origin.
+
+2.4.3. EnvelopedData Content Type
+
+ This content type is used to apply data confidentiality to a message.
+ A sender needs to have access to a public key for each intended
+ message recipient to use this service.
+
+2.4.4. CompressedData Content Type
+
+ This content type is used to apply data compression to a message.
+ This content type does not provide authentication, message integrity,
+ non-repudiation, or data confidentiality, and is only used to reduce
+ message size.
+
+ See section 3.6 for further guidance on the use of this type in
+ conjunction with other CMS types.
+
+2.5. Attributes and the SignerInfo Type
+
+ The SignerInfo type allows the inclusion of unsigned and signed
+ attributes to be included along with a signature.
+
+ Receiving agents MUST be able to handle zero or one instance of each
+ of the signed attributes listed here. Sending agents SHOULD generate
+ one instance of each of the following signed attributes in each
+ S/MIME message:
+
+ - signingTime (section 2.5.1 in this document)
+ - sMIMECapabilities (section 2.5.2 in this document)
+ - sMIMEEncryptionKeyPreference (section 2.5.3 in this document)
+ - id-messageDigest (section 11.2 in [CMS])
+ - id-contentType (section 11.1 in [CMS])
+
+
+
+
+
+
+Ramsdell Standards Track [Page 7]
+
+RFC 3851 S/MIME 3.1 Message Specification July 2004
+
+
+ Further, receiving agents SHOULD be able to handle zero or one
+ instance in the signingCertificate signed attribute, as defined in
+ section 5 of [ESS].
+
+ Sending agents SHOULD generate one instance of the signingCertificate
+ signed attribute in each SignerInfo structure.
+
+ Additional attributes and values for these attributes might be
+ defined in the future. Receiving agents SHOULD handle attributes or
+ values that it does not recognize in a graceful manner.
+
+ Interactive sending agents that include signed attributes that are
+ not listed here SHOULD display those attributes to the user, so that
+ the user is aware of all of the data being signed.
+
+2.5.1. Signing-Time Attribute
+
+ The signing-time attribute is used to convey the time that a message
+ was signed. The time of signing will most likely be created by a
+ message originator and therefore is only as trustworthy as the
+ originator.
+
+ Sending agents MUST encode signing time through the year 2049 as
+ UTCTime; signing times in 2050 or later MUST be encoded as
+ GeneralizedTime. When the UTCTime CHOICE is used, S/MIME agents MUST
+ interpret the year field (YY) as follows:
+
+ if YY is greater than or equal to 50, the year is interpreted as
+ 19YY; if YY is less than 50, the year is interpreted as 20YY.
+
+2.5.2. SMIMECapabilities Attribute
+
+ The SMIMECapabilities attribute includes signature algorithms (such
+ as "sha1WithRSAEncryption"), symmetric algorithms (such as "DES-
+ EDE3-CBC"), and key encipherment algorithms (such as
+ "rsaEncryption"). There are also several identifiers which indicate
+ support for other optional features such as binary encoding and
+ compression. The SMIMECapabilities were designed to be flexible and
+ extensible so that, in the future, a means of identifying other
+ capabilities and preferences such as certificates can be added in a
+ way that will not cause current clients to break.
+
+ If present, the SMIMECapabilities attribute MUST be a
+ SignedAttribute; it MUST NOT be an UnsignedAttribute. CMS defines
+ SignedAttributes as a SET OF Attribute. The SignedAttributes in a
+ signerInfo MUST NOT include multiple instances of the
+ SMIMECapabilities attribute. CMS defines the ASN.1 syntax for
+ Attribute to include attrValues SET OF AttributeValue. A
+
+
+
+Ramsdell Standards Track [Page 8]
+
+RFC 3851 S/MIME 3.1 Message Specification July 2004
+
+
+ SMIMECapabilities attribute MUST only include a single instance of
+ AttributeValue. There MUST NOT be zero or multiple instances of
+ AttributeValue present in the attrValues SET OF AttributeValue.
+
+ The semantics of the SMIMECapabilities attribute specify a partial
+ list as to what the client announcing the SMIMECapabilities can
+ support. A client does not have to list every capability it
+ supports, and need not list all its capabilities so that the
+ capabilities list doesn't get too long. In an SMIMECapabilities
+ attribute, the object identifiers (OIDs) are listed in order of their
+ preference, but SHOULD be separated logically along the lines of
+ their categories (signature algorithms, symmetric algorithms, key
+ encipherment algorithms, etc.)
+
+ The structure of the SMIMECapabilities attribute is to facilitate
+ simple table lookups and binary comparisons in order to determine
+ matches. For instance, the DER-encoding for the SMIMECapability for
+ DES EDE3 CBC MUST be identically encoded regardless of the
+ implementation. Because of the requirement for identical encoding,
+ individuals documenting algorithms to be used in the
+ SMIMECapabilities attribute SHOULD explicitly document the correct
+ byte sequence for the common cases.
+
+ For any capability, the associated parameters for the OID MUST
+ specify all of the parameters necessary to differentiate between two
+ instances of the same algorithm. For instance, the number of rounds
+ and the block size for RC5 needs to be specified in addition to the
+ key length.
+
+ The OIDs that correspond to algorithms SHOULD use the same OID as the
+ actual algorithm, except in the case where the algorithm usage is
+ ambiguous from the OID. For instance, in an earlier specification,
+ rsaEncryption was ambiguous because it could refer to either a
+ signature algorithm or a key encipherment algorithm. In the event
+ that an OID is ambiguous, it needs to be arbitrated by the maintainer
+ of the registered SMIMECapabilities list as to which type of
+ algorithm will use the OID, and a new OID MUST be allocated under the
+ smimeCapabilities OID to satisfy the other use of the OID.
+
+ The registered SMIMECapabilities list specifies the parameters for
+ OIDs that need them, most notably key lengths in the case of
+ variable-length symmetric ciphers. In the event that there are no
+ differentiating parameters for a particular OID, the parameters MUST
+ be omitted, and MUST NOT be encoded as NULL.
+
+
+
+
+
+
+
+Ramsdell Standards Track [Page 9]
+
+RFC 3851 S/MIME 3.1 Message Specification July 2004
+
+
+ Additional values for the SMIMECapabilities attribute might be
+ defined in the future. Receiving agents MUST handle a
+ SMIMECapabilities object that has values that it does not recognize
+ in a graceful manner.
+
+ Section 2.7.1 explains a strategy for caching capabilities.
+
+2.5.2.1. SMIMECapability For the RC2 Algorithm
+
+ For the RC2 algorithm preference SMIMECapability, the capabilityID
+ MUST be set to the value rc2-cbc as defined in [CMSALG]. The
+ parameters field MUST contain SMIMECapabilitiesParametersForRC2CBC
+ (see appendix A).
+
+ Please note that the SMIMECapabilitiesParametersForRC2CBC is a single
+ INTEGER which contains the effective key length (NOT the
+ corresponding RC2 parameter version value). So, for example, for RC2
+ with a 128-bit effective key length, the parameter would be encoded
+ as the INTEGER value 128, NOT the corresponding parameter version of
+ 58.
+
+2.5.3. Encryption Key Preference Attribute
+
+ The encryption key preference attribute allows the signer to
+ unambiguously describe which of the signer's certificates has the
+ signer's preferred encryption key. This attribute is designed to
+ enhance behavior for interoperating with those clients that use
+ separate keys for encryption and signing. This attribute is used to
+ convey to anyone viewing the attribute which of the listed
+ certificates is appropriate for encrypting a session key for future
+ encrypted messages.
+
+ If present, the SMIMEEncryptionKeyPreference attribute MUST be a
+ SignedAttribute; it MUST NOT be an UnsignedAttribute. CMS defines
+ SignedAttributes as a SET OF Attribute. The SignedAttributes in a
+ signerInfo MUST NOT include multiple instances of the
+ SMIMEEncryptionKeyPreference attribute. CMS defines the ASN.1 syntax
+ for Attribute to include attrValues SET OF AttributeValue. A
+ SMIMEEncryptionKeyPreference attribute MUST only include a single
+ instance of AttributeValue. There MUST NOT be zero or multiple
+ instances of AttributeValue present in the attrValues SET OF
+ AttributeValue.
+
+ The sending agent SHOULD include the referenced certificate in the
+ set of certificates included in the signed message if this attribute
+ is used. The certificate MAY be omitted if it has been previously
+ made available to the receiving agent. Sending agents SHOULD use
+ this attribute if the commonly used or preferred encryption
+
+
+
+Ramsdell Standards Track [Page 10]
+
+RFC 3851 S/MIME 3.1 Message Specification July 2004
+
+
+ certificate is not the same as the certificate used to sign the
+ message.
+
+ Receiving agents SHOULD store the preference data if the signature on
+ the message is valid and the signing time is greater than the
+ currently stored value. (As with the SMIMECapabilities, the clock
+ skew SHOULD be checked and the data not used if the skew is too
+ great.) Receiving agents SHOULD respect the sender's encryption key
+ preference attribute if possible. This, however, represents only a
+ preference and the receiving agent can use any certificate in
+ replying to the sender that is valid.
+
+ Section 2.7.1 explains a strategy for caching preference data.
+
+2.5.3.1. Selection of Recipient Key Management Certificate
+
+ In order to determine the key management certificate to be used when
+ sending a future CMS EnvelopedData message for a particular
+ recipient, the following steps SHOULD be followed:
+
+ - If an SMIMEEncryptionKeyPreference attribute is found in a
+ SignedData object received from the desired recipient, this
+ identifies the X.509 certificate that SHOULD be used as the X.509
+ key management certificate for the recipient.
+
+ - If an SMIMEEncryptionKeyPreference attribute is not found in a
+ SignedData object received from the desired recipient, the set of
+ X.509 certificates SHOULD be searched for a X.509 certificate with
+ the same subject name as the signing of a X.509 certificate which
+ can be used for key management.
+
+ - Or use some other method of determining the user's key management
+ key. If a X.509 key management certificate is not found, then
+ encryption cannot be done with the signer of the message. If
+ multiple X.509 key management certificates are found, the S/MIME
+ agent can make an arbitrary choice between them.
+
+2.6. SignerIdentifier SignerInfo Type
+
+ S/MIME v3.1 implementations MUST support both issuerAndSerialNumber
+ as well as subjectKeyIdentifier. Messages that use the
+ subjectKeyIdentifier choice cannot be read by S/MIME v2 clients.
+
+ It is important to understand that some certificates use a value for
+ subjectKeyIdentifier that is not suitable for uniquely identifying a
+ certificate. Implementations MUST be prepared for multiple
+ certificates for potentially different entities to have the same
+ value for subjectKeyIdentifier, and MUST be prepared to try each
+
+
+
+Ramsdell Standards Track [Page 11]
+
+RFC 3851 S/MIME 3.1 Message Specification July 2004
+
+
+ matching certificate during signature verification before indicating
+ an error condition.
+
+2.7. ContentEncryptionAlgorithmIdentifier
+
+ Sending and receiving agents MUST support encryption and decryption
+ with DES EDE3 CBC, hereinafter called "tripleDES" [CMSALG].
+ Receiving agents SHOULD support encryption and decryption using the
+ RC2 [CMSALG] or a compatible algorithm at a key size of 40 bits,
+ hereinafter called "RC2/40". Sending and receiving agents SHOULD
+ support encryption and decryption with AES [CMSAES] at a key size of
+ 128, 192, and 256 bits.
+
+2.7.1. Deciding Which Encryption Method To Use
+
+ When a sending agent creates an encrypted message, it has to decide
+ which type of encryption to use. The decision process involves using
+ information garnered from the capabilities lists included in messages
+ received from the recipient, as well as out-of-band information such
+ as private agreements, user preferences, legal restrictions, and so
+ on.
+
+ Section 2.5.2 defines a method by which a sending agent can
+ optionally announce, among other things, its decrypting capabilities
+ in its order of preference. The following method for processing and
+ remembering the encryption capabilities attribute in incoming signed
+ messages SHOULD be used.
+
+ - If the receiving agent has not yet created a list of capabilities
+ for the sender's public key, then, after verifying the signature
+ on the incoming message and checking the timestamp, the receiving
+ agent SHOULD create a new list containing at least the signing
+ time and the symmetric capabilities.
+
+ - If such a list already exists, the receiving agent SHOULD verify
+ that the signing time in the incoming message is greater than the
+ signing time stored in the list and that the signature is valid.
+ If so, the receiving agent SHOULD update both the signing time and
+ capabilities in the list. Values of the signing time that lie far
+ in the future (that is, a greater discrepancy than any reasonable
+ clock skew), or a capabilities list in messages whose signature
+ could not be verified, MUST NOT be accepted.
+
+ The list of capabilities SHOULD be stored for future use in creating
+ messages.
+
+ Before sending a message, the sending agent MUST decide whether it is
+ willing to use weak encryption for the particular data in the
+
+
+
+Ramsdell Standards Track [Page 12]
+
+RFC 3851 S/MIME 3.1 Message Specification July 2004
+
+
+ message. If the sending agent decides that weak encryption is
+ unacceptable for this data, then the sending agent MUST NOT use a
+ weak algorithm such as RC2/40. The decision to use or not use weak
+ encryption overrides any other decision in this section about which
+ encryption algorithm to use.
+
+ Sections 2.7.2.1 through 2.7.2.4 describe the decisions a sending
+ agent SHOULD use in deciding which type of encryption will be applied
+ to a message. These rules are ordered, so the sending agent SHOULD
+ make its decision in the order given.
+
+2.7.1.1. Rule 1: Known Capabilities
+
+ If the sending agent has received a set of capabilities from the
+ recipient for the message the agent is about to encrypt, then the
+ sending agent SHOULD use that information by selecting the first
+ capability in the list (that is, the capability most preferred by the
+ intended recipient) that the sending agent knows how to encrypt. The
+ sending agent SHOULD use one of the capabilities in the list if the
+ agent reasonably expects the recipient to be able to decrypt the
+ message.
+
+2.7.1.2. Rule 2: Unknown Capabilities, Unknown Version of S/MIME
+
+ If the following two conditions are met:
+ - the sending agent has no knowledge of the encryption capabilities
+ of the recipient,
+ - and the sending agent has no knowledge of the version of S/MIME of
+ the recipient,
+ then the sending agent SHOULD use tripleDES because it is a stronger
+ algorithm and is required by S/MIME v3. If the sending agent chooses
+ not to use tripleDES in this step, it SHOULD use RC2/40.
+
+2.7.2. Choosing Weak Encryption
+
+ Like all algorithms that use 40 bit keys, RC2/40 is considered by
+ many to be weak encryption. A sending agent that is controlled by a
+ human SHOULD allow a human sender to determine the risks of sending
+ data using RC2/40 or a similarly weak encryption algorithm before
+ sending the data, and possibly allow the human to use a stronger
+ encryption method such as tripleDES.
+
+2.7.3. Multiple Recipients
+
+ If a sending agent is composing an encrypted message to a group of
+ recipients where the encryption capabilities of some of the
+ recipients do not overlap, the sending agent is forced to send more
+ than one message. Please note that if the sending agent chooses to
+
+
+
+Ramsdell Standards Track [Page 13]
+
+RFC 3851 S/MIME 3.1 Message Specification July 2004
+
+
+ send a message encrypted with a strong algorithm, and then send the
+ same message encrypted with a weak algorithm, someone watching the
+ communications channel could learn the contents of the strongly-
+ encrypted message simply by decrypting the weakly-encrypted message.
+
+3. Creating S/MIME Messages
+
+ This section describes the S/MIME message formats and how they are
+ created. S/MIME messages are a combination of MIME bodies and CMS
+ content types. Several MIME types as well as several CMS content
+ types are used. The data to be secured is always a canonical MIME
+ entity. The MIME entity and other data, such as certificates and
+ algorithm identifiers, are given to CMS processing facilities which
+ produce a CMS object. Finally, the CMS object is wrapped in MIME.
+ The Enhanced Security Services for S/MIME [ESS] document provides
+ descriptions of how nested, secured S/MIME messages are formatted.
+ ESS provides a description of how a triple-wrapped S/MIME message is
+ formatted using multipart/signed and application/pkcs7-mime for the
+ signatures.
+
+ S/MIME provides one format for enveloped-only data, several formats
+ for signed-only data, and several formats for signed and enveloped
+ data. Several formats are required to accommodate several
+ environments, in particular for signed messages. The criteria for
+ choosing among these formats are also described.
+
+ The reader of this section is expected to understand MIME as
+ described in [MIME-SPEC] and [MIME-SECURE].
+
+3.1. Preparing the MIME Entity for Signing, Enveloping or Compressing
+
+ S/MIME is used to secure MIME entities. A MIME entity can be a sub-
+ part, sub-parts of a message, or the whole message with all its sub-
+ parts. A MIME entity that is the whole message includes only the
+ MIME headers and MIME body, and does not include the RFC-822 headers.
+ Note that S/MIME can also be used to secure MIME entities used in
+ applications other than Internet mail. If protection of the RFC-822
+ headers is required, the use of the message/rfc822 MIME type is
+ explained later in this section.
+
+ The MIME entity that is secured and described in this section can be
+ thought of as the "inside" MIME entity. That is, it is the
+ "innermost" object in what is possibly a larger MIME message.
+ Processing "outside" MIME entities into CMS content types is
+ described in Section 3.2, 3.4, and elsewhere.
+
+ The procedure for preparing a MIME entity is given in [MIME-SPEC].
+ The same procedure is used here with some additional restrictions
+
+
+
+Ramsdell Standards Track [Page 14]
+
+RFC 3851 S/MIME 3.1 Message Specification July 2004
+
+
+ when signing. Description of the procedures from [MIME-SPEC] are
+ repeated here, but it is suggested that the reader refer to that
+ document for the exact procedure. This section also describes
+ additional requirements.
+
+ A single procedure is used for creating MIME entities that are to
+ have any combination of signing, enveloping, and compressing applied.
+ Some additional steps are recommended to defend against known
+ corruptions that can occur during mail transport that are of
+ particular importance for clear-signing using the multipart/signed
+ format. It is recommended that these additional steps be performed
+ on enveloped messages, or signed and enveloped messages, so that the
+ message can be forwarded to any environment without modification.
+
+ These steps are descriptive rather than prescriptive. The
+ implementer is free to use any procedure as long as the result is the
+ same.
+
+ Step 1. The MIME entity is prepared according to the local
+ conventions.
+
+ Step 2. The leaf parts of the MIME entity are converted to canonical
+ form.
+
+ Step 3. Appropriate transfer encoding is applied to the leaves of
+ the MIME entity.
+
+ When an S/MIME message is received, the security services on the
+ message are processed, and the result is the MIME entity. That MIME
+ entity is typically passed to a MIME-capable user agent where, it is
+ further decoded and presented to the user or receiving application.
+
+ In order to protect outer, non-content related message headers (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 headers. It is up
+ to the receiving client to decide how to present these "inner"
+ headers along with the unprotected "outer" headers.
+
+ 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.
+
+
+
+
+
+
+
+Ramsdell Standards Track [Page 15]
+
+RFC 3851 S/MIME 3.1 Message Specification July 2004
+
+
+3.1.1. Canonicalization
+
+ Each MIME entity MUST be converted to a canonical form that is
+ uniquely and unambiguously representable in the environment where the
+ signature is created and the environment where the signature will be
+ verified. MIME entities MUST be canonicalized for enveloping and
+ compressing as well as signing.
+
+ The exact details of canonicalization depend on the actual MIME type
+ and subtype of an entity, and are not described here. Instead, the
+ standard for the particular MIME type SHOULD be consulted. For
+ example, canonicalization of type text/plain is different from
+ canonicalization of audio/basic. Other than text types, most types
+ have only one representation regardless of computing platform or
+ environment which can be considered their canonical representation.
+ In general, canonicalization will be performed by the non-security
+ part of the sending agent rather than the S/MIME implementation.
+
+ The most common and important canonicalization is for text, which is
+ often represented differently in different environments. MIME
+ entities of major type "text" MUST have both their line endings and
+ character set canonicalized. The line ending MUST be the pair of
+ characters <CR><LF>, and the charset SHOULD be a registered charset
+ [CHARSETS]. The details of the canonicalization are specified in
+ [MIME-SPEC]. The chosen charset SHOULD be named in the charset
+ parameter so that the receiving agent can unambiguously determine the
+ charset used.
+
+ Note that some charsets such as ISO-2022 have multiple
+ representations for the same characters. When preparing such text
+ for signing, the canonical representation specified for the charset
+ MUST be used.
+
+3.1.2. Transfer Encoding
+
+ When generating any of the secured MIME entities below, except the
+ signing using the multipart/signed format, no transfer encoding is
+ required at all. S/MIME implementations MUST be able to deal with
+ binary MIME objects. If no Content-Transfer-Encoding header is
+ present, the transfer encoding is presumed to be 7BIT.
+
+ S/MIME implementations SHOULD however use transfer encoding described
+ in section 3.1.3 for all MIME entities they secure. The reason for
+ securing only 7-bit MIME entities, even for enveloped data that are
+ not exposed to the transport, is that it allows the MIME entity to be
+ handled in any environment without changing it. For example, a
+ trusted gateway might remove the envelope, but not the signature, of
+ a message, and then forward the signed message on to the end
+
+
+
+Ramsdell Standards Track [Page 16]
+
+RFC 3851 S/MIME 3.1 Message Specification July 2004
+
+
+ recipient so that they can verify the signatures directly. If the
+ transport internal to the site is not 8-bit clean, such as on a
+ wide-area network with a single mail gateway, verifying the signature
+ will not be possible unless the original MIME entity was only 7-bit
+ data.
+
+ S/MIME implementations which "know" that all intended recipient(s)
+ are capable of handling inner (all but the outermost) binary MIME
+ objects SHOULD use binary encoding as opposed to a 7-bit-safe
+ transfer encoding for the inner entities. The use of a 7-bit-safe
+ encoding (such as base64) would unnecessarily expand the message
+ size. Implementations MAY "know" that recipient implementations are
+ capable of handling inner binary MIME entities either by interpreting
+ the id-cap-preferBinaryInside sMIMECapabilities attribute, by prior
+ agreement, or by other means.
+
+ If one or more intended recipients are unable to handle inner binary
+ MIME objects, or if this capability is unknown for any of the
+ intended recipients, S/MIME implementations SHOULD use transfer
+ encoding described in section 3.1.3 for all MIME entities they
+ secure.
+
+3.1.3. Transfer Encoding for Signing Using multipart/signed
+
+ If a multipart/signed entity is ever to be transmitted over the
+ standard Internet SMTP infrastructure or other transport that is
+ constrained to 7-bit text, it MUST have transfer encoding applied so
+ that it is represented as 7-bit text. MIME entities that are 7-bit
+ data already need no transfer encoding. Entities such as 8-bit text
+ and binary data can be encoded with quoted-printable or base-64
+ transfer encoding.
+
+ The primary reason for the 7-bit requirement is that the Internet
+ mail transport infrastructure cannot guarantee transport of 8-bit or
+ binary data. Even though many segments of the transport
+ infrastructure now handle 8-bit and even binary data, it is sometimes
+ not possible to know whether the transport path is 8-bit clean. If a
+ mail message with 8-bit data were to encounter a message transfer
+ agent that can not transmit 8-bit or binary data, the agent has three
+ options, none of which are acceptable for a clear-signed message:
+
+ - The agent could change the transfer encoding; this would
+ invalidate the signature.
+ - The agent could transmit the data anyway, which would most likely
+ result in the 8th bit being corrupted; this too would invalidate
+ the signature.
+ - The agent could return the message to the sender.
+
+
+
+
+Ramsdell Standards Track [Page 17]
+
+RFC 3851 S/MIME 3.1 Message Specification July 2004
+
+
+ [MIME-SECURE] prohibits an agent from changing the transfer encoding
+ of the first part of a multipart/signed message. If a compliant
+ agent that can not transmit 8-bit or binary data encounters a
+ multipart/signed message with 8-bit or binary data in the first part,
+ it would have to return the message to the sender as undeliverable.
+
+3.1.4. Sample Canonical MIME Entity
+
+ This example shows a multipart/mixed message with full transfer
+ encoding. This message contains a text part and an attachment. The
+ sample message text includes characters that are not US-ASCII and
+ thus need to be transfer encoded. Though not shown here, the end of
+ each line is <CR><LF>. The line ending of the MIME headers, the
+ text, and transfer encoded parts, all MUST be <CR><LF>.
+
+ Note that this example is not of an S/MIME message.
+
+ Content-Type: multipart/mixed; boundary=bar
+
+ --bar
+ Content-Type: text/plain; charset=iso-8859-1
+ Content-Transfer-Encoding: quoted-printable
+
+ =A1Hola Michael!
+
+ How do you like the new S/MIME specification?
+
+ It's generally a good idea to encode lines that begin with
+ From=20because some mail transport agents will insert a greater-
+ than (>) sign, thus invalidating the signature.
+
+ Also, in some cases it might be desirable to encode any =20
+ trailing whitespace that occurs on lines in order to ensure =20
+ that the message signature is not invalidated when passing =20
+ a gateway that modifies such whitespace (like BITNET). =20
+
+ --bar
+ Content-Type: image/jpeg
+ Content-Transfer-Encoding: base64
+
+ iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
+ jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
+ uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
+ HOxEa44b+EI=
+
+ --bar--
+
+
+
+
+
+Ramsdell Standards Track [Page 18]
+
+RFC 3851 S/MIME 3.1 Message Specification July 2004
+
+
+3.2. The application/pkcs7-mime Type
+
+ The application/pkcs7-mime type is used to carry CMS content types
+ including EnvelopedData, SignedData, and CompressedData. The details
+ of constructing these entities is described in subsequent sections.
+ This section describes the general characteristics of the
+ application/pkcs7-mime type.
+
+ The carried CMS object always contains a MIME entity that is prepared
+ as described in section 3.1 if the eContentType is id-data. Other
+ contents MAY be carried when the eContentType contains different
+ values. See [ESS] for an example of this with signed receipts.
+
+ Since CMS content types are binary data, in most cases base-64
+ transfer encoding is appropriate, in particular, when used with SMTP
+ transport. The transfer encoding used depends on the transport
+ through which the object is to be sent, and is not a characteristic
+ of the MIME type.
+
+ Note that this discussion refers to the transfer encoding of the CMS
+ object or "outside" MIME entity. It is completely distinct from, and
+ unrelated to, the transfer encoding of the MIME entity secured by the
+ CMS object, the "inside" object, which is described in section 3.1.
+
+ Because there are several types of application/pkcs7-mime objects, a
+ sending agent SHOULD do as much as possible to help a receiving agent
+ know about the contents of the object without forcing the receiving
+ agent to decode the ASN.1 for the object. The MIME headers of all
+ application/pkcs7-mime objects SHOULD include the optional "smime-
+ type" parameter, as described in the following sections.
+
+3.2.1. The name and filename Parameters
+
+ For the application/pkcs7-mime, sending agents SHOULD emit the
+ optional "name" parameter to the Content-Type field for compatibility
+ with older systems. Sending agents SHOULD also emit the optional
+ Content-Disposition field [CONTDISP] with the "filename" parameter.
+ If a sending agent emits the above parameters, the value of the
+ parameters SHOULD be a file name with the appropriate extension:
+
+
+
+
+
+
+
+
+
+
+
+
+Ramsdell Standards Track [Page 19]
+
+RFC 3851 S/MIME 3.1 Message Specification July 2004
+
+
+ MIME Type File Extension
+
+ application/pkcs7-mime (SignedData, EnvelopedData) .p7m
+
+ application/pkcs7-mime (degenerate SignedData .p7c
+ certificate management message)
+
+ application/pkcs7-mime (CompressedData) .p7z
+
+ application/pkcs7-signature (SignedData) .p7s
+
+ In addition, the file name SHOULD be limited to eight characters
+ followed by a three letter extension. The eight character filename
+ base can be any distinct name; the use of the filename base "smime"
+ SHOULD be used to indicate that the MIME entity is associated with
+ S/MIME.
+
+ Including a file name serves two purposes. It facilitates easier use
+ of S/MIME objects as files on disk. It also can convey type
+ information across gateways. When a MIME entity of type
+ application/pkcs7-mime (for example) arrives at a gateway that has no
+ special knowledge of S/MIME, it will default the entity's MIME type
+ to application/octet-stream and treat it as a generic attachment,
+ thus losing the type information. However, the suggested filename
+ for an attachment is often carried across a gateway. This often
+ allows the receiving systems to determine the appropriate application
+ to hand the attachment off to, in this case, a stand-alone S/MIME
+ processing application. Note that this mechanism is provided as a
+ convenience for implementations in certain environments. A proper
+ S/MIME implementation MUST use the MIME types and MUST NOT rely on
+ the file extensions.
+
+3.2.2. The smime-type parameter
+
+ The application/pkcs7-mime content type defines the optional "smime-
+ type" parameter. The intent of this parameter is to convey details
+ about the security applied (signed or enveloped) along with
+ information about the contained content. This specification defines
+ the following smime-types.
+
+
+
+
+
+
+
+
+
+
+
+
+Ramsdell Standards Track [Page 20]
+
+RFC 3851 S/MIME 3.1 Message Specification July 2004
+
+
+ Name CMS type Inner Content
+
+ enveloped-data EnvelopedData id-data
+
+ signed-data SignedData id-data
+
+ certs-only SignedData none
+
+ compressed-data CompressedData id-data
+
+ In order for consistency to be obtained with future specifications,
+ the following guidelines SHOULD be followed when assigning a new
+ smime-type parameter.
+
+ 1. If both signing and encryption can be applied to the content, then
+ two values for smime-type SHOULD be assigned "signed-*" and
+ "encrypted-*". If one operation can be assigned then this can be
+ omitted. Thus since "certs-only" can only be signed, "signed-" is
+ omitted.
+
+ 2. A common string for a content OID SHOULD be assigned. We use
+ "data" for the id-data content OID when MIME is the inner content.
+
+ 3. If no common string is assigned. Then the common string of
+ "OID.<oid>" is recommended (for example, "OID.1.3.6.1.5.5.7.6.1"
+ would be DES40).
+
+ It is explicitly intended that this field be a suitable hint for mail
+ client applications to indicate whether a message is "signed" or
+ "encrypted" without having to tunnel into the CMS payload.
+
+3.3. Creating an Enveloped-only Message
+
+ This section describes the format for enveloping a MIME entity
+ without signing it. It is important to note that sending enveloped
+ but not signed messages does not provide for data integrity. It is
+ possible to replace ciphertext in such a way that the processed
+ message will still be valid, but the meaning can be altered.
+
+ Step 1. The MIME entity to be enveloped is prepared according to
+ section 3.1.
+
+ Step 2. The MIME entity and other required data is processed into a
+ CMS object of type EnvelopedData. In addition to encrypting a copy
+ of the content-encryption key for each recipient, a copy of the
+ content-encryption key SHOULD be encrypted for the originator and
+ included in the EnvelopedData (see [CMS] Section 6).
+
+
+
+
+Ramsdell Standards Track [Page 21]
+
+RFC 3851 S/MIME 3.1 Message Specification July 2004
+
+
+ Step 3. The EnvelopedData object is wrapped in a CMS ContentInfo
+ object.
+
+ Step 4. The ContentInfo object is inserted into an
+ application/pkcs7-mime MIME entity.
+
+ The smime-type parameter for enveloped-only messages is "enveloped-
+ data". The file extension for this type of message is ".p7m".
+
+ A sample message would be:
+
+ Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
+ name=smime.p7m
+ Content-Transfer-Encoding: base64
+ Content-Disposition: attachment; filename=smime.p7m
+
+ rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
+ 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
+ f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
+ 0GhIGfHfQbnj756YT64V
+
+3.4. Creating a Signed-only Message
+
+ There are two formats for signed messages defined for S/MIME:
+ application/pkcs7-mime with SignedData, and multipart/signed. In
+ general, the multipart/signed form is preferred for sending, and
+ receiving agents MUST be able to handle both.
+
+3.4.1. Choosing a Format for Signed-only Messages
+
+ There are no hard-and-fast rules when a particular signed-only format
+ is chosen because it depends on the capabilities of all the receivers
+ and the relative importance of receivers with S/MIME facilities being
+ able to verify the signature versus the importance of receivers
+ without S/MIME software being able to view the message.
+
+ Messages signed using the multipart/signed format can always be
+ viewed by the receiver whether they have S/MIME software or not.
+ They can also be viewed whether they are using a MIME-native user
+ agent or they have messages translated by a gateway. In this
+ context, "be viewed" means the ability to process the message
+ essentially as if it were not a signed message, including any other
+ MIME structure the message might have.
+
+
+
+
+
+
+
+
+Ramsdell Standards Track [Page 22]
+
+RFC 3851 S/MIME 3.1 Message Specification July 2004
+
+
+ Messages signed using the SignedData format cannot be viewed by a
+ recipient unless they have S/MIME facilities. However, the
+ SignedData format protects the message content from being changed by
+ benign intermediate agents. Such agents might do line wrapping or
+ content-transfer encoding changes which would break the signature.
+
+3.4.2. Signing Using application/pkcs7-mime with SignedData
+
+ This signing format uses the application/pkcs7-mime MIME type. The
+ steps to create this format are:
+
+ Step 1. The MIME entity is prepared according to section 3.1.
+
+ Step 2. The MIME entity and other required data is processed into a
+ CMS object of type SignedData.
+
+ Step 3. The SignedData object is wrapped in a CMS ContentInfo
+ object.
+
+ Step 4. The ContentInfo object is inserted into an
+ application/pkcs7-mime MIME entity.
+
+ The smime-type parameter for messages using application/pkcs7-mime
+ with SignedData is "signed-data". The file extension for this type
+ of message is ".p7m".
+
+ A sample message would be:
+
+ Content-Type: application/pkcs7-mime; smime-type=signed-data;
+ name=smime.p7m
+ Content-Transfer-Encoding: base64
+ Content-Disposition: attachment; filename=smime.p7m
+
+ 567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7
+ 77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH
+ HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh
+ 6YT64V0GhIGfHfQbnj75
+
+3.4.3. Signing Using the multipart/signed Format
+
+ This format is a clear-signing format. Recipients without any S/MIME
+ or CMS processing facilities are able to view the message. It makes
+ use of the multipart/signed MIME type described in [MIME-SECURE].
+ The multipart/signed MIME type has two parts. The first part
+ contains the MIME entity that is signed; the second part contains the
+ "detached signature" CMS SignedData object in which the
+ encapContentInfo eContent field is absent.
+
+
+
+
+Ramsdell Standards Track [Page 23]
+
+RFC 3851 S/MIME 3.1 Message Specification July 2004
+
+
+3.4.3.1. The application/pkcs7-signature MIME Type
+
+ This MIME type always contains a CMS ContentInfo containing a single
+ CMS object of type SignedData. The SignedData encapContentInfo
+ eContent field MUST be absent. The signerInfos field contains the
+ signatures for the MIME entity.
+
+ The file extension for signed-only messages using application/pkcs7-
+ signature is ".p7s".
+
+3.4.3.2. Creating a multipart/signed Message
+
+ Step 1. The MIME entity to be signed is prepared according to
+ section 3.1, taking special care for clear-signing.
+
+ Step 2. The MIME entity is presented to CMS processing in order to
+ obtain an object of type SignedData in which the encapContentInfo
+ eContent field is absent.
+
+ Step 3. The MIME entity is inserted into the first part of a
+ multipart/signed message with no processing other than that described
+ in section 3.1.
+
+ Step 4. Transfer encoding is applied to the "detached signature" CMS
+ SignedData object and it is inserted into a MIME entity of type
+ application/pkcs7-signature.
+
+ Step 5. The MIME entity of the application/pkcs7-signature is
+ inserted into the second part of the multipart/signed entity.
+
+ The multipart/signed Content type has two required parameters: the
+ protocol parameter and the micalg parameter.
+
+ The protocol parameter MUST be "application/pkcs7-signature". Note
+ that quotation marks are required around the protocol parameter
+ because MIME requires that the "/" character in the parameter value
+ MUST be quoted.
+
+ The micalg parameter allows for one-pass processing when the
+ signature is being verified. The value of the micalg parameter is
+ dependent on the message digest algorithm(s) used in the calculation
+ of the Message Integrity Check. If multiple message digest
+ algorithms are used they MUST be separated by commas per [MIME-
+ SECURE]. The values to be placed in the micalg parameter SHOULD be
+ from the following:
+
+
+
+
+
+
+Ramsdell Standards Track [Page 24]
+
+RFC 3851 S/MIME 3.1 Message Specification July 2004
+
+
+ Algorithm Value
+ used
+
+ MD5 md5
+ SHA-1 sha1
+ SHA-256 sha256
+ SHA-384 sha384
+ SHA-512 sha512
+ Any other (defined separately in algorithm profile or "unknown"
+ if not defined)
+
+ (Historical note: some early implementations of S/MIME emitted and
+ expected "rsa-md5" and "rsa-sha1" for the micalg parameter.)
+ Receiving agents SHOULD be able to recover gracefully from a micalg
+ parameter value that they do not recognize.
+
+ The SHA-256, SHA-384, and SHA-512 algorithms [FIPS180-2] are not
+ currently recommended in S/MIME, and are included here for
+ completeness.
+
+3.4.3.3. Sample multipart/signed Message
+
+ Content-Type: multipart/signed;
+ protocol="application/pkcs7-signature";
+ micalg=sha1; boundary=boundary42
+
+ --boundary42
+ Content-Type: text/plain
+
+ This is a clear-signed message.
+
+ --boundary42
+ Content-Type: application/pkcs7-signature; name=smime.p7s
+ Content-Transfer-Encoding: base64
+ Content-Disposition: attachment; filename=smime.p7s
+
+ ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
+ 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
+ n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
+ 7GhIGfHfYT64VQbnj756
+
+ --boundary42--
+
+
+
+
+
+
+
+
+
+Ramsdell Standards Track [Page 25]
+
+RFC 3851 S/MIME 3.1 Message Specification July 2004
+
+
+ The content that is digested (the first part of the multipart/signed)
+ are the bytes:
+
+ 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 74 65 78 74 2f 70 6c 61 69
+ 6e 0d 0a 0d 0a 54 68 69 73 20 69 73 20 61 20 63 6c 65 61 72 2d 73 69
+ 67 6e 65 64 20 6d 65 73 73 61 67 65 2e 0d 0a
+
+3.5. Creating an Compressed-only Message
+
+ This section describes the format for compressing a MIME entity.
+ Please note that versions of S/MIME prior to 3.1 did not specify any
+ use of CompressedData, and will not recognize it. The use of a
+ capability to indicate the ability to receive CompressedData is
+ described in [CMSCOMPR] and is the preferred method for
+ compatibility.
+
+ Step 1. The MIME entity to be compressed is prepared according to
+ section 3.1.
+
+ Step 2. The MIME entity and other required data is processed into a
+ CMS object of type CompressedData.
+
+ Step 3. The CompressedData object is wrapped in a CMS ContentInfo
+ object.
+
+ Step 4. The ContentInfo object is inserted into an
+ application/pkcs7-mime MIME entity.
+
+ The smime-type parameter for compressed-only messages is
+ "compressed-data". The file extension for this type of message is
+ ".p7z".
+
+ A sample message would be:
+
+ Content-Type: application/pkcs7-mime; smime-type=compressed-data;
+ name=smime.p7z
+ Content-Transfer-Encoding: base64
+ Content-Disposition: attachment; filename=smime.p7z
+
+ rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
+ 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
+ f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
+ 0GhIGfHfQbnj756YT64V
+
+
+
+
+
+
+
+
+Ramsdell Standards Track [Page 26]
+
+RFC 3851 S/MIME 3.1 Message Specification July 2004
+
+
+3.6. Multiple Operations
+
+ The signed-only, encrypted-only, and compressed-only MIME formats can
+ be nested. This works because these formats are all MIME entities
+ that encapsulate other MIME entities.
+
+ An S/MIME implementation MUST be able to receive and process
+ arbitrarily nested S/MIME within reasonable resource limits of the
+ recipient computer.
+
+ It is possible to apply any of the signing, encrypting, and
+ compressing operations in any order. It is up to the implementer and
+ the user to choose. When signing first, the signatories are then
+ securely obscured by the enveloping. When enveloping first the
+ signatories are exposed, but it is possible to verify signatures
+ without removing the enveloping. This can be useful in an
+ environment were automatic signature verification is desired, as no
+ private key material is required to verify a signature.
+
+ There are security ramifications to choosing whether to sign first or
+ encrypt first. A recipient of a message that is encrypted and then
+ signed can validate that the encrypted block was unaltered, but
+ cannot determine any relationship between the signer and the
+ unencrypted contents of the message. A recipient of a message that
+ is signed-then-encrypted can assume that the signed message itself
+ has not been altered, but that a careful attacker could have changed
+ the unauthenticated portions of the encrypted message.
+
+ When using compression, keep the following guidelines in mind:
+
+ - Compression of binary encoded encrypted data is discouraged, since
+ it will not yield significant compression. Base64 encrypted data
+ could very well benefit, however.
+ - If a lossy compression algorithm is used with signing, you will
+ need to compress first, then sign.
+
+3.7. Creating a Certificate Management Message
+
+ The certificate management message or MIME entity is used to
+ transport certificates and/or certificate revocation lists, such as
+ in response to a registration request.
+
+ Step 1. The certificates and/or certificate revocation lists are
+ made available to the CMS generating process which creates a CMS
+ object of type SignedData. The SignedData encapContentInfo eContent
+ field MUST be absent and signerInfos field MUST be empty.
+
+
+
+
+
+Ramsdell Standards Track [Page 27]
+
+RFC 3851 S/MIME 3.1 Message Specification July 2004
+
+
+ Step 2. The SignedData object is wrapped in a CMS ContentInfo
+ object.
+
+ Step 3. The ContentInfo object is enclosed in an application/pkcs7-
+ mime MIME entity.
+
+ The smime-type parameter for a certificate management message is
+ "certs-only". The file extension for this type of message is ".p7c".
+
+3.8. Registration Requests
+
+ A sending agent that signs messages MUST have a certificate for the
+ signature so that a receiving agent can verify the signature. There
+ are many ways of getting certificates, such as through an exchange
+ with a certificate authority, through a hardware token or diskette,
+ and so on.
+
+ S/MIME v2 [SMIMEV2] specified a method for "registering" public keys
+ with certificate authorities using an application/pkcs10 body part.
+ Since that time, the IETF PKIX Working Group has developed other
+ methods for requesting certificates. However, S/MIME v3.1 does not
+ require a particular certificate request mechanism.
+
+3.9. Identifying an S/MIME Message
+
+ Because S/MIME takes into account interoperation in non-MIME
+ environments, several different mechanisms are employed to carry the
+ type information, and it becomes a bit difficult to identify S/MIME
+ messages. The following table lists criteria for determining whether
+ or not a message is an S/MIME message. A message is considered an
+ S/MIME message if it matches any of the criteria listed below.
+
+ The file suffix in the table below comes from the "name" parameter in
+ the content-type header, or the "filename" parameter on the content-
+ disposition header. These parameters that give the file suffix are
+ not listed below as part of the parameter section.
+
+ MIME type: application/pkcs7-mime
+ parameters: any
+ file suffix: any
+
+ MIME type: multipart/signed
+ parameters: protocol="application/pkcs7-signature"
+ file suffix: any
+
+ MIME type: application/octet-stream
+ parameters: any
+ file suffix: p7m, p7s, p7c, p7z
+
+
+
+Ramsdell Standards Track [Page 28]
+
+RFC 3851 S/MIME 3.1 Message Specification July 2004
+
+
+4. Certificate Processing
+
+ A receiving agent MUST provide some certificate retrieval mechanism
+ in order to gain access to certificates for recipients of digital
+ envelopes. This specification does not cover how S/MIME agents
+ handle certificates, only what they do after a certificate has been
+ validated or rejected. S/MIME certificate issues are covered in
+ [CERT31].
+
+ At a minimum, for initial S/MIME deployment, a user agent could
+ automatically generate a message to an intended recipient requesting
+ that recipient's certificate in a signed return message. Receiving
+ and sending agents SHOULD also provide a mechanism to allow a user to
+ "store and protect" certificates for correspondents in such a way so
+ as to guarantee their later retrieval.
+
+4.1. Key Pair Generation
+
+ All generated key pairs MUST be generated from a good source of non-
+ deterministic random input [RANDOM] and the private key MUST be
+ protected in a secure fashion.
+
+ If an S/MIME agent needs to generate an RSA key pair, then the S/MIME
+ agent or some related administrative utility or function SHOULD
+ generate RSA key pairs using the following guidelines. A user agent
+ SHOULD generate RSA key pairs at a minimum key size of 768 bits. A
+ user agent MUST NOT generate RSA key pairs less than 512 bits long.
+ Creating keys longer than 1024 bits can cause some older S/MIME
+ receiving agents to not be able to verify signatures, but gives
+ better security and is therefore valuable. A receiving agent SHOULD
+ be able to verify signatures with keys of any size over 512 bits.
+ Some agents created in the United States have chosen to create 512
+ bit keys in order to get more advantageous export licenses. However,
+ 512 bit keys are considered by many to be cryptographically insecure.
+ Implementers SHOULD be aware that multiple (active) key pairs can be
+ associated with a single individual. For example, one key pair can
+ be used to support confidentiality, while a different key pair can be
+ used for authentication.
+
+5. Security Considerations
+
+ 40-bit encryption is considered weak by most cryptographers. Using
+ weak cryptography in S/MIME offers little actual security over
+ sending plaintext. However, other features of S/MIME, such as the
+ specification of tripleDES and the ability to announce stronger
+ cryptographic capabilities to parties with whom you communicate,
+ allow senders to create messages that use strong encryption. Using
+ weak cryptography is never recommended unless the only alternative is
+
+
+
+Ramsdell Standards Track [Page 29]
+
+RFC 3851 S/MIME 3.1 Message Specification July 2004
+
+
+ no cryptography. When feasible, sending and receiving agents SHOULD
+ inform senders and recipients of the relative cryptographic strength
+ of messages.
+
+ It is impossible for most software or people to estimate the value of
+ a message. Further, it is impossible for most software or people to
+ estimate the actual cost of decrypting a message that is encrypted
+ with a key of a particular size. Further, it is quite difficult to
+ determine the cost of a failed decryption if a recipient cannot
+ decode a message. Thus, choosing between different key sizes (or
+ choosing whether to just use plaintext) is also impossible. However,
+ decisions based on these criteria are made all the time, and
+ therefore this specification gives a framework for using those
+ estimates in choosing algorithms.
+
+ If a sending agent is sending the same message using different
+ strengths of cryptography, an attacker watching the communications
+ channel might be able to determine the contents of the strongly-
+ encrypted message by decrypting the weakly-encrypted version. In
+ other words, a sender SHOULD NOT send a copy of a message using
+ weaker cryptography than they would use for the original of the
+ message.
+
+ Modification of the ciphertext can go undetected if authentication is
+ not also used, which is the case when sending EnvelopedData without
+ wrapping it in SignedData or enclosing SignedData within it.
+
+ See RFC 3218 [MMA] for more information about thwarting the adaptive
+ chosen ciphertext vulnerability in PKCS #1 Version 1.5
+ implementations.
+
+ In some circumstances the use of the Diffie-Hellman key agreement
+ scheme in a prime order subgroup of a large prime p is vulnerable to
+ certain attacks known as "small-subgroup" attacks. Methods exist,
+ however, to prevent these attacks. These methods are described in
+ RFC 2785 [DHSUB].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ramsdell Standards Track [Page 30]
+
+RFC 3851 S/MIME 3.1 Message Specification July 2004
+
+
+A. ASN.1 Module
+
+SecureMimeMessageV3dot1
+ { iso(1) member-body(2) us(840) rsadsi(113549)
+ pkcs(1) pkcs-9(9) smime(16) modules(0) msg-v3dot1(21) }
+
+DEFINITIONS IMPLICIT TAGS ::=
+BEGIN
+
+IMPORTS
+-- Cryptographic Message Syntax
+ SubjectKeyIdentifier, IssuerAndSerialNumber,
+ RecipientKeyIdentifier
+ FROM CryptographicMessageSyntax
+ { iso(1) member-body(2) us(840) rsadsi(113549)
+ pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2001(14) };
+
+
+-- id-aa is the arc with all new authenticated and unauthenticated
+-- attributes produced the by S/MIME Working Group
+
+id-aa OBJECT IDENTIFIER ::= {iso(1) member-body(2) usa(840)
+ rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) attributes(2)}
+
+-- S/MIME Capabilities provides a method of broadcasting the symmetric
+-- capabilities understood. Algorithms SHOULD be ordered by
+-- preference and grouped by type
+
+smimeCapabilities OBJECT IDENTIFIER ::=
+ {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15}
+
+SMIMECapability ::= SEQUENCE {
+ capabilityID OBJECT IDENTIFIER,
+ parameters ANY DEFINED BY capabilityID OPTIONAL }
+
+SMIMECapabilities ::= SEQUENCE OF SMIMECapability
+
+-- Encryption Key Preference provides a method of broadcasting the
+-- preferred encryption certificate.
+
+id-aa-encrypKeyPref OBJECT IDENTIFIER ::= {id-aa 11}
+
+SMIMEEncryptionKeyPreference ::= CHOICE {
+ issuerAndSerialNumber [0] IssuerAndSerialNumber,
+ receipentKeyId [1] RecipientKeyIdentifier,
+ subjectAltKeyIdentifier [2] SubjectKeyIdentifier
+}
+
+
+
+
+Ramsdell Standards Track [Page 31]
+
+RFC 3851 S/MIME 3.1 Message Specification July 2004
+
+
+id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
+ us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 }
+
+id-cap OBJECT IDENTIFIER ::= { id-smime 11 }
+
+-- The preferBinaryInside indicates an ability to receive messages
+-- with binary encoding inside the CMS wrapper
+
+id-cap-preferBinaryInside OBJECT IDENTIFIER ::= { id-cap 1 }
+
+-- The following list the OIDs to be used with S/MIME V3
+
+-- Signature Algorithms Not Found in [CMSALG]
+--
+-- md2WithRSAEncryption OBJECT IDENTIFIER ::=
+-- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1)
+-- 2}
+--
+-- Other Signed Attributes
+--
+-- signingTime OBJECT IDENTIFIER ::=
+-- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
+-- 5}
+-- See [CMS] for a description of how to encode the attribute
+-- value.
+
+SMIMECapabilitiesParametersForRC2CBC ::= INTEGER
+-- (RC2 Key Length (number of bits))
+
+END
+
+B. References
+
+B.1. Normative References
+
+ [CERT31] Ramsdell, B., Ed., "S/MIME Version 3.1 Certificate
+ Handling", RFC 3850, July 2004.
+
+ [CHARSETS] Character sets assigned by IANA. See
+ http://www.iana.org/assignments/character-sets
+
+ [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
+ 3852, July 2004.
+
+ [CMSAES] Schaad, J., "Use of the Advanced Encryption Standard
+ (AES) Encryption Algorithm in Cryptographic Message
+ Syntax (CMS)", RFC 3565, July 2003.
+
+
+
+
+Ramsdell Standards Track [Page 32]
+
+RFC 3851 S/MIME 3.1 Message Specification July 2004
+
+
+ [CMSALG] Housley, R., "Cryptographic Message Syntax (CMS)
+ Algorithms", RFC 3370, August 2002.
+
+ [CMSCOMPR] Gutmann, P., "Compressed Data Content Type for
+ Cryptographic Message Syntax (CMS)", RFC 3274, June
+ 2002.
+
+ [CONTDISP] Troost, R., Dorner, S., and K. Moore, "Communicating
+ Presentation Information in Internet Messages: The
+ Content-Disposition Header Field", RFC 2183, August
+ 1997.
+
+ [ESS] Hoffman, P., "Enhanced Security Services for S/MIME",
+ RFC 2634, June 1999.
+
+ [FIPS180-2] "Secure Hash Signature Standard (SHS)", National
+ Institute of Standards and Technology (NIST). FIPS
+ Publication 180-2.
+
+ [MIME-SPEC] Freed, N. and N. Borenstein, "Multipurpose Internet
+ Mail Extensions (MIME) Part One: Format of Internet
+ Message Bodies", RFC 2045, November 1996.
+
+ Freed, N. and N. Borenstein, "Multipurpose Internet
+ Mail Extensions (MIME) Part Two: Media Types", RFC
+ 2046, November 1996.
+
+ Moore, K., "MIME (Multipurpose Internet Mail
+ Extensions) Part Three: Message Header Extensions for
+ Non-ASCII Text", RFC 2047, November 1996.
+
+ Freed, N., Klensin, J., and J. Postel, "Multipurpose
+ Internet Mail Extensions (MIME) Part Four: Registration
+ Procedures", BCP 13, RFC 2048, November 1996.
+
+ Freed, N. and N. Borenstein, "Multipurpose Internet
+ Mail Extensions (MIME) Part Five: Conformance Criteria
+ and Examples", RFC 2049, November 1996.
+
+ [MIME-SECURE] Galvin, J., Murphy, S., Crocker, S., and N. Freed,
+ "Security Multiparts for MIME: Multipart/Signed and
+ Multipart/Encrypted", RFC 1847, October 1995.
+
+ [MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [X.208-88] CCITT. Recommendation X.208: Specification of Abstract
+ Syntax Notation One (ASN.1). 1988.
+
+
+
+Ramsdell Standards Track [Page 33]
+
+RFC 3851 S/MIME 3.1 Message Specification July 2004
+
+
+ [X.209-88] CCITT. Recommendation X.209: Specification of Basic
+ Encoding Rules for Abstract Syntax Notation One
+ (ASN.1). 1988.
+
+ [X.509-88] CCITT. Recommendation X.509: The Directory -
+ Authentication Framework. 1988.
+
+B.2. Informative References
+
+ [DHSUB] Zuccherato, R., "Methods for Avoiding the "Small-
+ Subgroup" Attacks on the Diffie-Hellman Key Agreement
+ Method for S/MIME", RFC 2785, March 2000.
+
+ [MMA] Rescorla, E., "Preventing the Million Message Attack on
+ Cryptographic Message Syntax", RFC 3218, January 2002.
+
+ [PKCS-7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax
+ Version 1.5", RFC 2315, March 1998.
+
+ [RANDOM] Eastlake 3rd, D., Crocker, S., and J. Schiller,
+ "Randomness Recommendations for Security", RFC 1750,
+ December 1994.
+
+ [SMIMEV2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L.,
+ and L. Repka, "S/MIME Version 2 Message Specification",
+ RFC 2311, March 1998.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ramsdell Standards Track [Page 34]
+
+RFC 3851 S/MIME 3.1 Message Specification July 2004
+
+
+C. Acknowledgements
+
+ Many thanks go out to the other authors of the S/MIME Version 2
+ Message Specification RFC: Steve Dusse, Paul Hoffman, Laurence
+ Lundblade and Lisa Repka.
+
+ A number of the members of the S/MIME Working Group have also worked
+ very hard and contributed to this document. Any list of people is
+ doomed to omission, and for that I apologize. In alphabetical order,
+ the following people stand out in my mind due to the fact that they
+ made direct contributions to this document.
+
+ Tony Capel
+ Piers Chivers
+ Dave Crocker
+ Bill Flanigan
+ Peter Gutmann
+ Paul Hoffman
+ Russ Housley
+ William Ottaway
+ John Pawling
+ Jim Schaad
+
+D. Editor's Address
+
+ Blake Ramsdell
+ Sendmail, Inc.
+ 704 228th Ave NE #775
+ Sammamish, WA 98074
+
+ EMail: blake sendmail com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ramsdell Standards Track [Page 35]
+
+RFC 3851 S/MIME 3.1 Message Specification July 2004
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at ietf-
+ ipr ietf org
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+Ramsdell Standards Track [Page 36]
+
diff --git a/rfc/rfc5750.txt b/rfc/rfc5750.txt
new file mode 100644
index 0000000..64c3e00
--- /dev/null
+++ b/rfc/rfc5750.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) B. Ramsdell
+Request for Comments: 5750 Brute Squad Labs
+Obsoletes: 3850 S. Turner
+Category: Standards Track IECA
+ISSN: 2070-1721 January 2010
+
+
+ Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2
+ Certificate Handling
+
+Abstract
+
+ This document specifies conventions for X.509 certificate usage by
+ Secure/Multipurpose Internet Mail Extensions (S/MIME) v3.2 agents.
+ S/MIME provides a method to send and receive secure MIME messages,
+ and certificates are an integral part of S/MIME agent processing.
+ S/MIME agents validate certificates as described in RFC 5280, the
+ Internet X.509 Public Key Infrastructure Certificate and CRL Profile.
+ S/MIME agents must meet the certificate processing requirements in
+ this document as well as those in RFC 5280. This document obsoletes
+ RFC 3850.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by
+ the Internet Engineering Steering Group (IESG). Further
+ information on Internet Standards is available in Section 2 of
+ RFC 5741.
+
+ Information about the current status of this document, any
+ errata, and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc5750.
+
+Copyright Notice
+
+ Copyright (c) 2010 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
+
+
+
+Ramsdell & Turner Standards Track [Page 1]
+
+RFC 5750 S/MIME 3.2 Certificate Handling January 2010
+
+
+ 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.
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+ the copyright in such materials, this document may not be modified
+ outside the IETF Standards Process, and derivative works of it may
+ not be created outside the IETF Standards Process, except to format
+ it for publication as an RFC or to translate it into languages other
+ than English.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Definitions ................................................3
+ 1.2. Conventions Used in This Document ..........................4
+ 1.3. Compatibility with Prior Practice S/MIME ...................4
+ 1.4. Changes from S/MIME v3 to S/MIME v3.1 ......................5
+ 1.5. Changes since S/MIME v3.1 ..................................5
+ 2. CMS Options .....................................................6
+ 2.1. Certificate Revocation Lists ...............................6
+ 2.2. Certificate Choices ........................................6
+ 2.3. CertificateSet .............................................7
+ 3. Using Distinguished Names for Internet Mail .....................8
+ 4. Certificate Processing ..........................................9
+ 4.1. Certificate Revocation Lists ..............................10
+ 4.2. Certificate Path Validation ...............................11
+ 4.3. Certificate and CRL Signing Algorithms and Key Sizes ......11
+ 4.4. PKIX Certificate Extensions ...............................12
+ 5. Security Considerations ........................................15
+ 6. References .....................................................17
+ 6.1. Reference Conventions .....................................17
+ 6.2. Normative References ......................................17
+ 6.3. Informative References ....................................19
+ Appendix A. Moving S/MIME v2 Certificate Handling to Historic
+ Status.................................................21
+ Appendix B. Acknowledgments........................................21
+
+
+
+
+
+
+
+
+
+Ramsdell & Turner Standards Track [Page 2]
+
+RFC 5750 S/MIME 3.2 Certificate Handling January 2010
+
+
+1. Introduction
+
+ S/MIME (Secure/Multipurpose Internet Mail Extensions) v3.2, described
+ in [SMIME-MSG], provides a method to send and receive secure MIME
+ messages. Before using a public key to provide security services,
+ the S/MIME agent MUST verify that the public key is valid. S/MIME
+ agents MUST use PKIX certificates to validate public keys as
+ described in the Internet X.509 Public Key Infrastructure (PKIX)
+ Certificate and CRL Profile [KEYM]. S/MIME agents MUST meet the
+ certificate processing requirements documented in this document in
+ addition to those stated in [KEYM].
+
+ This specification is compatible with the Cryptographic Message
+ Syntax (CMS) RFC 5652 [CMS] in that it uses the data types defined by
+ CMS. It also inherits all the varieties of architectures for
+ certificate-based key management supported by CMS.
+
+1.1. Definitions
+
+ For the purposes of this document, the following definitions apply.
+
+ ASN.1: Abstract Syntax Notation One, as defined in ITU-T X.680
+ [X.680].
+
+ Attribute certificate (AC): An X.509 AC is a separate structure from
+ a subject's public key X.509 certificate. A subject may have
+ multiple X.509 ACs associated with each of its public key X.509
+ certificates. Each X.509 AC binds one or more attributes with one of
+ the subject's public key X.509 certificates. The X.509 AC syntax is
+ defined in [ACAUTH].
+
+ Certificate: A type that binds an entity's name to a public key with
+ a digital signature. This type is defined in the Internet X.509
+ Public Key Infrastructure (PKIX) Certificate and CRL Profile [KEYM].
+ This type also contains the distinguished name of the certificate
+ issuer (the signer), an issuer-specific serial number, the issuer's
+ signature algorithm identifier, a validity period, and extensions
+ also defined in that document.
+
+ Certificate Revocation List (CRL): A type that contains information
+ about certificates whose validity an issuer has prematurely revoked.
+ The information consists of an issuer name, the time of issue, the
+ next scheduled time of issue, a list of certificate serial numbers
+ and their associated revocation times, and extensions as defined in
+ [KEYM]. The CRL is signed by the issuer. The type intended by this
+ specification is the one defined in [KEYM].
+
+
+
+
+
+Ramsdell & Turner Standards Track [Page 3]
+
+RFC 5750 S/MIME 3.2 Certificate Handling January 2010
+
+
+ Receiving agent: Software that interprets and processes S/MIME CMS
+ objects, MIME body parts that contain CMS objects, or both.
+
+ Sending agent: Software that creates S/MIME CMS objects, MIME body
+ parts that contain CMS objects, or both.
+
+ S/MIME agent: User software that is a receiving agent, a sending
+ agent, or both.
+
+1.2. Conventions Used in This Document
+
+ 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 [MUSTSHOULD].
+
+ We define some additional terms here:
+
+ SHOULD+ This term means the same as SHOULD. However, the authors
+ expect that a requirement marked as SHOULD+ will be
+ promoted at some future time to be a MUST.
+
+ SHOULD- This term means the same as SHOULD. However, the authors
+ expect that a requirement marked as SHOULD- will be
+ demoted to a MAY in a future version of this document.
+
+ MUST- This term means the same as MUST. However, the authors
+ expect that this requirement will no longer be a MUST in a
+ future document. Although its status will be determined
+ at a later time, it is reasonable to expect that if a
+ future revision of a document alters the status of a MUST-
+ requirement, it will remain at least a SHOULD or a
+ SHOULD-.
+
+1.3. Compatibility with Prior Practice S/MIME
+
+ S/MIME version 3.2 agents ought to attempt to have the greatest
+ interoperability possible with agents for prior versions of S/MIME.
+
+ S/MIME version 2 is described in RFC 2311 through RFC 2315 inclusive
+ [SMIMEv2], S/MIME version 3 is described in RFC 2630 through RFC 2634
+ inclusive and RFC 5035 [SMIMEv3], and S/MIME version 3.1 is described
+ in RFC 3850, RFC 3851, RFC 3852, RFC 2634, and RFC 5035 [SMIMEv3.1].
+ RFC 2311 also has historical information about the development of
+ S/MIME.
+
+
+
+
+
+
+
+Ramsdell & Turner Standards Track [Page 4]
+
+RFC 5750 S/MIME 3.2 Certificate Handling January 2010
+
+
+1.4. Changes from S/MIME v3 to S/MIME v3.1
+
+ Version 1 and version 2 CRLs MUST be supported.
+
+ Multiple certification authority (CA) certificates with the same
+ subject and public key, but with overlapping validity periods, MUST
+ be supported.
+
+ Version 2 attribute certificates SHOULD be supported, and version 1
+ attributes certificates MUST NOT be used.
+
+ The use of the MD2 digest algorithm for certificate signatures is
+ discouraged, and security language was added.
+
+ Clarified use of email address use in certificates. Certificates
+ that do not contain an email address have no requirements for
+ verifying the email address associated with the certificate.
+
+ Receiving agents SHOULD display certificate information when
+ displaying the results of signature verification.
+
+ Receiving agents MUST NOT accept a signature made with a certificate
+ that does not have the digitalSignature or nonRepudiation bit set.
+
+ Clarifications for the interpretation of the key usage and extended
+ key usage extensions.
+
+1.5. Changes since S/MIME v3.1
+
+ Conventions Used in This Document: Moved to Section 1.2. Added
+ definitions for SHOULD+, SHOULD-, and MUST-.
+
+ Section 1.1: Updated ASN.1 definition and reference.
+
+ Section 1.3: Added text about v3.1 RFCs.
+
+ Section 3: Aligned email address text with RFC 5280. Updated
+ note to indicate emailAddress IA5String upper bound is
+ 255 characters. Added text about matching email
+ addresses.
+
+ Section 4.2: Added text to indicate how S/MIME agents locate the
+ correct user certificate.
+
+
+
+
+
+
+
+
+Ramsdell & Turner Standards Track [Page 5]
+
+RFC 5750 S/MIME 3.2 Certificate Handling January 2010
+
+
+ Section 4.3: RSA with SHA-256 (PKCS #1 v1.5) added as MUST; DSA
+ with SHA-256 added as SHOULD+; RSA with SHA-1, DSA
+ with SHA-1, and RSA with MD5 changed to SHOULD-; and
+ RSASSA-PSS with SHA-256 added as SHOULD+. Updated key
+ sizes and changed pointer to PKIX RFCs.
+
+ Section 4.4.1: Aligned with PKIX on use of basic constraints
+ extension in CA certificates. Clarified which
+ extension is used to constrain end entities from using
+ their keys to perform issuing authority operations.
+
+ Section 5: Updated security considerations.
+
+ Section 7: Moved references from Appendix B to Section 6.
+ Updated the references.
+
+ Appendix A: Moved Appendix A to Appendix B. Added Appendix A to
+ move S/MIME v2 Certificate Handling to Historic
+ Status.
+
+2. CMS Options
+
+ The CMS message format allows for a wide variety of options in
+ content and algorithm support. This section puts forth a number of
+ support requirements and recommendations in order to achieve a base
+ level of interoperability among all S/MIME implementations. Most of
+ the CMS format for S/MIME messages is defined in [SMIME-MSG].
+
+2.1. Certificate Revocation Lists
+
+ Receiving agents MUST support the Certificate Revocation List (CRL)
+ format defined in [KEYM]. If sending agents include CRLs in outgoing
+ messages, the CRL format defined in [KEYM] MUST be used. In all
+ cases, both v1 and v2 CRLs MUST be supported.
+
+ All agents MUST be capable of performing revocation checks using CRLs
+ as specified in [KEYM]. All agents MUST perform revocation status
+ checking in accordance with [KEYM]. Receiving agents MUST recognize
+ CRLs in received S/MIME messages.
+
+ Agents SHOULD store CRLs received in messages for use in processing
+ later messages.
+
+2.2. Certificate Choices
+
+ Receiving agents MUST support v1 X.509 and v3 X.509 certificates as
+ profiled in [KEYM]. End-entity certificates MAY include an Internet
+ mail address, as described in Section 3.
+
+
+
+Ramsdell & Turner Standards Track [Page 6]
+
+RFC 5750 S/MIME 3.2 Certificate Handling January 2010
+
+
+ Receiving agents SHOULD support X.509 version 2 attribute
+ certificates. See [ACAUTH] for details about the profile for
+ attribute certificates.
+
+2.2.1. Historical Note about CMS Certificates
+
+ The CMS message format supports a choice of certificate formats for
+ public key content types: PKIX, PKCS #6 extended certificates
+ [PKCS6], and PKIX attribute certificates.
+
+ The PKCS #6 format is not in widespread use. In addition, PKIX
+ certificate extensions address much of the same functionality and
+ flexibility as was intended in the PKCS #6. Thus, sending and
+ receiving agents MUST NOT use PKCS #6 extended certificates.
+
+ X.509 version 1 attribute certificates are also not widely
+ implemented, and have been superseded with version 2 attribute
+ certificates. Sending agents MUST NOT send version 1 attribute
+ certificates.
+
+2.3. CertificateSet
+
+ Receiving agents MUST be able to handle an arbitrary number of
+ certificates of arbitrary relationship to the message sender and to
+ each other in arbitrary order. In many cases, the certificates
+ included in a signed message may represent a chain of certification
+ from the sender to a particular root. There may be, however,
+ situations where the certificates in a signed message may be
+ unrelated and included for convenience.
+
+ Sending agents SHOULD include any certificates for the user's public
+ key(s) and associated issuer certificates. This increases the
+ likelihood that the intended recipient can establish trust in the
+ originator's public key(s). This is especially important when
+ sending a message to recipients that may not have access to the
+ sender's public key through any other means or when sending a signed
+ message to a new recipient. The inclusion of certificates in
+ outgoing messages can be omitted if S/MIME objects are sent within a
+ group of correspondents that has established access to each other's
+ certificates by some other means such as a shared directory or manual
+ certificate distribution. Receiving S/MIME agents SHOULD be able to
+ handle messages without certificates using a database or directory
+ lookup scheme.
+
+
+
+
+
+
+
+
+Ramsdell & Turner Standards Track [Page 7]
+
+RFC 5750 S/MIME 3.2 Certificate Handling January 2010
+
+
+ A sending agent SHOULD include at least one chain of certificates up
+ to, but not including, a certification authority (CA) that it
+ believes that the recipient may trust as authoritative. A receiving
+ agent MUST be able to handle an arbitrarily large number of
+ certificates and chains.
+
+ Agents MAY send CA certificates, that is, cross-certificates, self-
+ issued certificates, and self-signed certificates. Note that
+ receiving agents SHOULD NOT simply trust any self-signed certificates
+ as valid CAs, but SHOULD use some other mechanism to determine if
+ this is a CA that should be trusted. Also note that when
+ certificates contain Digital Signature Algorithm (DSA) public keys
+ the parameters may be located in the root certificate. This would
+ require that the recipient possess both the end-entity certificate
+ and the root certificate to perform a signature verification, and is
+ a valid example of a case where transmitting the root certificate may
+ be required.
+
+ Receiving agents MUST support chaining based on the distinguished
+ name fields. Other methods of building certificate chains MAY be
+ supported.
+
+ Receiving agents SHOULD support the decoding of X.509 attribute
+ certificates included in CMS objects. All other issues regarding the
+ generation and use of X.509 attribute certificates are outside of the
+ scope of this specification. One specification that addresses
+ attribute certificate use is defined in [SECLABEL].
+
+3. Using Distinguished Names for Internet Mail
+
+ End-entity certificates MAY contain an Internet mail address as
+ described in [KEYM], Section 4.2.1.6. The email address SHOULD be in
+ the subjectAltName extension, and SHOULD NOT be in the subject
+ distinguished name.
+
+ Receiving agents MUST recognize and accept certificates that contain
+ no email address. Agents are allowed to provide an alternative
+ mechanism for associating an email address with a certificate that
+ does not contain an email address, such as through the use of the
+ agent's address book, if available. Receiving agents MUST recognize
+ email addresses in the subjectAltName field. Receiving agents MUST
+ recognize email addresses in the Distinguished Name field in the PKCS
+ #9 [PKCS9] emailAddress attribute:
+
+ pkcs-9-at-emailAddress OBJECT IDENTIFIER ::=
+ { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1 }
+
+
+
+
+
+Ramsdell & Turner Standards Track [Page 8]
+
+RFC 5750 S/MIME 3.2 Certificate Handling January 2010
+
+
+ Note that this attribute MUST be encoded as IA5String and has an
+ upper bound of 255 characters. The right side of the email address
+ SHOULD be treated as ASCII-case-insensitive.
+
+ Sending agents SHOULD make the address in the From or Sender header
+ in a mail message match an Internet mail address in the signer's
+ certificate. Receiving agents MUST check that the address in the
+ From or Sender header of a mail message matches an Internet mail
+ address, if present, in the signer's certificate, if mail addresses
+ are present in the certificate. A receiving agent SHOULD provide
+ some explicit alternate processing of the message if this comparison
+ fails, which may be to display a message that shows the recipient the
+ addresses in the certificate or other certificate details.
+
+ A receiving agent SHOULD display a subject name or other certificate
+ details when displaying an indication of successful or unsuccessful
+ signature verification.
+
+ All subject and issuer names MUST be populated (i.e., not an empty
+ SEQUENCE) in S/MIME-compliant X.509 certificates, except that the
+ subject distinguished name (DN) in a user's (i.e., end-entity)
+ certificate MAY be an empty SEQUENCE in which case the subjectAltName
+ extension will include the subject's identifier and MUST be marked as
+ critical.
+
+4. Certificate Processing
+
+ S/MIME agents need to provide some certificate retrieval mechanism in
+ order to gain access to certificates for recipients of digital
+ envelopes. There are many ways to implement certificate retrieval
+ mechanisms. [X.500] directory service is an excellent example of a
+ certificate retrieval-only mechanism that is compatible with classic
+ X.500 Distinguished Names. Another method under consideration by the
+ IETF is to provide certificate retrieval services as part of the
+ existing Domain Name System (DNS). Until such mechanisms are widely
+ used, their utility may be limited by the small number of the
+ correspondent's certificates that can be retrieved. At a minimum,
+ for initial S/MIME deployment, a user agent could automatically
+ generate a message to an intended recipient requesting the
+ recipient's certificate in a signed return message.
+
+ Receiving and sending agents SHOULD also provide a mechanism to allow
+ a user to "store and protect" certificates for correspondents in such
+ a way so as to guarantee their later retrieval. In many
+ environments, it may be desirable to link the certificate
+ retrieval/storage mechanisms together in some sort of certificate
+ database. In its simplest form, a certificate database would be
+ local to a particular user and would function in a similar way as an
+
+
+
+Ramsdell & Turner Standards Track [Page 9]
+
+RFC 5750 S/MIME 3.2 Certificate Handling January 2010
+
+
+ "address book" that stores a user's frequent correspondents. In this
+ way, the certificate retrieval mechanism would be limited to the
+ certificates that a user has stored (presumably from incoming
+ messages). A comprehensive certificate retrieval/storage solution
+ may combine two or more mechanisms to allow the greatest flexibility
+ and utility to the user. For instance, a secure Internet mail agent
+ may resort to checking a centralized certificate retrieval mechanism
+ for a certificate if it cannot be found in a user's local certificate
+ storage/retrieval database.
+
+ Receiving and sending agents SHOULD provide a mechanism for the
+ import and export of certificates, using a CMS certs-only message.
+ This allows for import and export of full certificate chains as
+ opposed to just a single certificate. This is described in
+ [SMIME-MSG].
+
+ Agents MUST handle multiple valid certification authority (CA)
+ certificates containing the same subject name and the same public
+ keys but with overlapping validity intervals.
+
+4.1. Certificate Revocation Lists
+
+ In general, it is always better to get the latest CRL information
+ from a CA than to get information stored away from incoming messages.
+ A receiving agent SHOULD have access to some CRL retrieval mechanism
+ in order to gain access to certificate revocation information when
+ validating certification paths. A receiving or sending agent SHOULD
+ also provide a mechanism to allow a user to store incoming
+ certificate revocation information for correspondents in such a way
+ so as to guarantee its later retrieval.
+
+ Receiving and sending agents SHOULD retrieve and utilize CRL
+ information every time a certificate is verified as part of a
+ certification path validation even if the certificate was already
+ verified in the past. However, in many instances (such as off-line
+ verification) access to the latest CRL information may be difficult
+ or impossible. The use of CRL information, therefore, may be
+ dictated by the value of the information that is protected. The
+ value of the CRL information in a particular context is beyond the
+ scope of this specification but may be governed by the policies
+ associated with particular certification paths.
+
+ All agents MUST be capable of performing revocation checks using CRLs
+ as specified in [KEYM]. All agents MUST perform revocation status
+ checking in accordance with [KEYM]. Receiving agents MUST recognize
+ CRLs in received S/MIME messages.
+
+
+
+
+
+Ramsdell & Turner Standards Track [Page 10]
+
+RFC 5750 S/MIME 3.2 Certificate Handling January 2010
+
+
+4.2. Certificate Path Validation
+
+ In creating a user agent for secure messaging, certificate, CRL, and
+ certification path validation SHOULD be highly automated while still
+ acting in the best interests of the user. Certificate, CRL, and path
+ validation MUST be performed as per [KEYM] when validating a
+ correspondent's public key. This is necessary before using a public
+ key to provide security services such as verifying a signature,
+ encrypting a content-encryption key (e.g., RSA), or forming a
+ pairwise symmetric key (e.g., Diffie-Hellman) to be used to encrypt
+ or decrypt a content-encryption key.
+
+ Certificates and CRLs are made available to the path validation
+ procedure in two ways: a) incoming messages, and b) certificate and
+ CRL retrieval mechanisms. Certificates and CRLs in incoming messages
+ are not required to be in any particular order nor are they required
+ to be in any way related to the sender or recipient of the message
+ (although in most cases they will be related to the sender).
+ Incoming certificates and CRLs SHOULD be cached for use in path
+ validation and optionally stored for later use. This temporary
+ certificate and CRL cache SHOULD be used to augment any other
+ certificate and CRL retrieval mechanisms for path validation on
+ incoming signed messages.
+
+ When verifying a signature and the certificates that are included in
+ the message, if a signingCertificate attribute from RFC 2634 [ESS] or
+ a signingCertificateV2 attribute from RFC 5035 [ESS] is found in an
+ S/MIME message, it SHALL be used to identify the signer's
+ certificate. Otherwise, the certificate is identified in an S/MIME
+ message, either using the issuerAndSerialNumber, which identifies the
+ signer's certificate by the issuer's distinguished name and the
+ certificate serial number, or the subjectKeyIdentifier, which
+ identifies the signer's certificate by a key identifier.
+
+ When decrypting an encrypted message, if a
+ SMIMEEncryptionKeyPreference attribute is found in an encapsulating
+ SignedData, it SHALL be used to identify the originator's certificate
+ found in OriginatorInfo. See [CMS] for the CMS fields that reference
+ the originator's and recipient's certificates.
+
+4.3. Certificate and CRL Signing Algorithms and Key Sizes
+
+ Certificates and Certificate Revocation Lists (CRLs) are signed by
+ the certificate issuer. Receiving agents:
+
+ - MUST support RSA with SHA-256
+
+ - SHOULD+ support DSA with SHA-256
+
+
+
+Ramsdell & Turner Standards Track [Page 11]
+
+RFC 5750 S/MIME 3.2 Certificate Handling January 2010
+
+
+ - SHOULD+ support RSASSA-PSS with SHA-256
+
+ - SHOULD- support RSA with SHA-1
+
+ - SHOULD- support DSA with SHA-1
+
+ - SHOULD- support RSA with MD5
+
+ The following are the RSA and RSASSA-PSS key size requirements for
+ S/MIME receiving agents during certificate and CRL signature
+ verification:
+
+ key size <= 1023 : MAY (see Section 5)
+ 1024 <= key size <= 4096 : MUST (see Section 5)
+ 4096 < key size : MAY (see Section 5)
+
+ The following are the DSA key size requirements for S/MIME receiving
+ agents during certificate and CRL signature verification:
+
+ key size <= 1023 : MAY (see Section 5)
+ 1024 <= key size <= 3072 : MUST (see Section 5)
+
+ For 512-bit RSA with SHA-1 see [KEYMALG] and [FIPS186-2] without
+ Change Notice 1, for 512-bit RSA with SHA-256 see [RSAOAEP] and
+ [FIPS186-2] without Change Notice 1, for 1024-bit through 3072-bit
+ RSA with SHA-256 see [RSAOAEP] and [FIPS186-2] with Change Notice 1,
+ and for 4096-bit RSA with SHA-256 see [RSAOAEP] and [PKCS1]. In
+ either case, the first reference provides the signature algorithm's
+ object identifier and the second provides the signature algorithm's
+ definition.
+
+ For 512-bit DSA with SHA-1 see [KEYMALG] and [FIPS186-2] without
+ Change Notice 1, for 512-bit DSA with SHA-256 see [KEYMALG2] and
+ [FIPS186-2] without Change Notice 1, for 1024-bit DSA with SHA-1 see
+ [KEYMALG] and [FIPS186-2] with Change Notice 1, for 1024-bit through
+ 3072 DSA with SHA-256 see [KEYMALG2] and [FIPS186-3]. In either
+ case, the first reference provides the signature algorithm's object
+ identifier and the second provides the signature algorithm's
+ definition.
+
+ For RSASSA-PSS with SHA-256 see [RSAPSS].
+
+4.4. PKIX Certificate Extensions
+
+ PKIX describes an extensible framework in which the basic certificate
+ information can be extended and describes how such extensions can be
+ used to control the process of issuing and validating certificates.
+ The PKIX Working Group has ongoing efforts to identify and create
+
+
+
+Ramsdell & Turner Standards Track [Page 12]
+
+RFC 5750 S/MIME 3.2 Certificate Handling January 2010
+
+
+ extensions that have value in particular certification environments.
+ Further, there are active efforts underway to issue PKIX certificates
+ for business purposes. This document identifies the minimum required
+ set of certificate extensions that have the greatest value in the
+ S/MIME environment. The syntax and semantics of all the identified
+ extensions are defined in [KEYM].
+
+ Sending and receiving agents MUST correctly handle the basic
+ constraints, key usage, authority key identifier, subject key
+ identifier, and subject alternative names certificate extensions when
+ they appear in end-entity and CA certificates. Some mechanism SHOULD
+ exist to gracefully handle other certificate extensions when they
+ appear in end-entity or CA certificates.
+
+ Certificates issued for the S/MIME environment SHOULD NOT contain any
+ critical extensions (extensions that have the critical field set to
+ TRUE) other than those listed here. These extensions SHOULD be
+ marked as non-critical unless the proper handling of the extension is
+ deemed critical to the correct interpretation of the associated
+ certificate. Other extensions may be included, but those extensions
+ SHOULD NOT be marked as critical.
+
+ Interpretation and syntax for all extensions MUST follow [KEYM],
+ unless otherwise specified here.
+
+4.4.1. Basic Constraints
+
+ The basic constraints extension serves to delimit the role and
+ position that an issuing authority or end-entity certificate plays in
+ a certification path.
+
+ For example, certificates issued to CAs and subordinate CAs contain a
+ basic constraint extension that identifies them as issuing authority
+ certificates. End-entity certificates contain the key usage
+ extension that restrains end entities from using the key when
+ performing issuing authority operations (see Section 4.4.2).
+
+ As per [KEYM], certificates MUST contain a basicConstraints extension
+ in CA certificates, and SHOULD NOT contain that extension in end-
+ entity certificates.
+
+4.4.2. Key Usage Certificate Extension
+
+ The key usage extension serves to limit the technical purposes for
+ which a public key listed in a valid certificate may be used.
+ Issuing authority certificates may contain a key usage extension that
+ restricts the key to signing certificates, certificate revocation
+ lists, and other data.
+
+
+
+Ramsdell & Turner Standards Track [Page 13]
+
+RFC 5750 S/MIME 3.2 Certificate Handling January 2010
+
+
+ For example, a certification authority may create subordinate issuer
+ certificates that contain a key usage extension that specifies that
+ the corresponding public key can be used to sign end user
+ certificates and sign CRLs.
+
+ If a key usage extension is included in a PKIX certificate, then it
+ MUST be marked as critical.
+
+ S/MIME receiving agents MUST NOT accept the signature of a message if
+ it was verified using a certificate that contains the key usage
+ extension without either the digitalSignature or nonRepudiation bit
+ set. Sometimes S/MIME is used as a secure message transport for
+ applications beyond interpersonal messaging. In such cases, the
+ S/MIME-enabled application can specify additional requirements
+ concerning the digitalSignature or nonRepudiation bits within this
+ extension.
+
+ If the key usage extension is not specified, receiving clients MUST
+ presume that the digitalSignature and nonRepudiation bits are set.
+
+4.4.3. Subject Alternative Name
+
+ The subject alternative name extension is used in S/MIME as the
+ preferred means to convey the email address(es) that correspond(s) to
+ the entity for this certificate. Any email addresses present MUST be
+ encoded using the rfc822Name CHOICE of the GeneralName type as
+ described in [KEYM], Section 4.2.1.6. Since the SubjectAltName type
+ is a SEQUENCE OF GeneralName, multiple email addresses MAY be
+ present.
+
+4.4.4. Extended Key Usage Extension
+
+ The extended key usage extension also serves to limit the technical
+ purposes for which a public key listed in a valid certificate may be
+ used. The set of technical purposes for the certificate therefore
+ are the intersection of the uses indicated in the key usage and
+ extended key usage extensions.
+
+ For example, if the certificate contains a key usage extension
+ indicating digital signature and an extended key usage extension that
+ includes the email protection OID, then the certificate may be used
+ for signing but not encrypting S/MIME messages. If the certificate
+ contains a key usage extension indicating digital signature but no
+ extended key usage extension, then the certificate may also be used
+ to sign but not encrypt S/MIME messages.
+
+
+
+
+
+
+Ramsdell & Turner Standards Track [Page 14]
+
+RFC 5750 S/MIME 3.2 Certificate Handling January 2010
+
+
+ If the extended key usage extension is present in the certificate,
+ then interpersonal message S/MIME receiving agents MUST check that it
+ contains either the emailProtection or the anyExtendedKeyUsage OID as
+ defined in [KEYM]. S/MIME uses other than interpersonal messaging
+ MAY require the explicit presence of the extended key usage extension
+ or other OIDs to be present in the extension or both.
+
+5. Security Considerations
+
+ All of the security issues faced by any cryptographic application
+ must be faced by a S/MIME agent. Among these issues are protecting
+ the user's private key, preventing various attacks, and helping the
+ user avoid mistakes such as inadvertently encrypting a message for
+ the wrong recipient. The entire list of security considerations is
+ beyond the scope of this document, but some significant concerns are
+ listed here.
+
+ When processing certificates, there are many situations where the
+ processing might fail. Because the processing may be done by a user
+ agent, a security gateway, or other program, there is no single way
+ to handle such failures. Just because the methods to handle the
+ failures have not been listed, however, the reader should not assume
+ that they are not important. The opposite is true: if a certificate
+ is not provably valid and associated with the message, the processing
+ software should take immediate and noticeable steps to inform the end
+ user about it.
+
+ Some of the many places where signature and certificate checking
+ might fail include:
+
+ - no Internet mail addresses in a certificate match the sender of a
+ message, if the certificate contains at least one mail address
+
+ - no certificate chain leads to a trusted CA
+
+ - no ability to check the CRL for a certificate
+
+ - an invalid CRL was received
+
+ - the CRL being checked is expired
+
+ - the certificate is expired
+
+ - the certificate has been revoked
+
+
+
+
+
+
+
+Ramsdell & Turner Standards Track [Page 15]
+
+RFC 5750 S/MIME 3.2 Certificate Handling January 2010
+
+
+ There are certainly other instances where a certificate may be
+ invalid, and it is the responsibility of the processing software to
+ check them all thoroughly, and to decide what to do if the check
+ fails.
+
+ It is possible for there to be multiple unexpired CRLs for a CA. If
+ an agent is consulting CRLs for certificate validation, it SHOULD
+ make sure that the most recently issued CRL for that CA is consulted,
+ since an S/MIME message sender could deliberately include an older
+ unexpired CRL in an S/MIME message. This older CRL might not include
+ recently revoked certificates, which might lead an agent to accept a
+ certificate that has been revoked in a subsequent CRL.
+
+ When determining the time for a certificate validity check, agents
+ have to be careful to use a reliable time. Unless it is from a
+ trusted agent, this time MUST NOT be the SigningTime attribute found
+ in an S/MIME message. For most sending agents, the SigningTime
+ attribute could be deliberately set to direct the receiving agent to
+ check a CRL that could have out-of-date revocation status for a
+ certificate, or cause an improper result when checking the Validity
+ field of a certificate.
+
+ In addition to the Security Considerations identified in [KEYM],
+ caution should be taken when processing certificates that have not
+ first been validated to a trust anchor. Certificates could be
+ manufactured by untrusted sources for the purpose of mounting denial
+ of service or other attacks. For example, keys selected to require
+ excessive cryptographic processing, or extensive lists of CRL
+ Distribution Point (CDP) and/or Authority Information Access (AIA)
+ addresses in the certificate, could be used to mount denial-of-
+ service attacks. Similarly, attacker-specified CDP and/or AIA
+ addresses could be included in fake certificates to allow the
+ originator to detect receipt of the message even if signature
+ verification fails.
+
+ The 4096-bit RSA key size requirement for certificate and CRL
+ verification is larger than the 2048-bit RSA key sizes for message
+ signature generation/verification or message encryption/decryption in
+ [SMIME-MSG] because many root CAs included in certificate stores have
+ already issued root certificates with the 4096-bit key. The standard
+ that defines comparable key sizes for DSA is not yet available. In
+ particular, [FIPS186-2] without Change Notice 1 allowed DSA key sizes
+ between 512 and 1024 bits, [FIPS186-2] with Change Notice 1 only
+ allowed DSA key sizes of 1024 bits, and [FIPS186-3] allowed DSA key
+ sizes from 1024 to 3072 bits. Further, 4096-bit keys are normally
+ only used by Root certificates and not by subordinate CA
+ certificates, thereby lengthening the root CA certificate's validity
+ period.
+
+
+
+Ramsdell & Turner Standards Track [Page 16]
+
+RFC 5750 S/MIME 3.2 Certificate Handling January 2010
+
+
+ RSA and DSA keys of less than 1024 bits are now considered by many
+ experts to be cryptographically insecure (due to advances in
+ computing power), and should no longer be used to sign certificates
+ or CRLs. Such keys were previously considered secure, so processing
+ previously received signed and encrypted mail may require processing
+ certificates or CRLs signed with weak keys. Implementations that
+ wish to support previous versions of S/MIME or process old messages
+ need to consider the security risks that result from accepting
+ certificates and CRLs with smaller key sizes (e.g., spoofed
+ certificates) versus the costs of denial of service. If an
+ implementation supports verification of certificates or CRLs
+ generated with RSA and DSA keys of less than 1024 bits, it MUST warn
+ the user. Implementers should consider providing a stronger warning
+ for weak signatures on certificates and CRLs associated with newly
+ received messages than the one provided for certificates and CRLs
+ associated with previously stored messages. Server implementations
+ (e.g., secure mail list servers) where user warnings are not
+ appropriate SHOULD reject messages with weak cryptography.
+
+ If an implementation is concerned about compliance with National
+ Institute of Standards and Technology (NIST) key size
+ recommendations, then see [SP800-57].
+
+6. References
+
+6.1. Reference Conventions
+
+ [CMS] refers to [RFC5652].
+
+ [ESS] refers to [RFC2634] and [RFC5035].
+
+ [SMIMEv2] refers to [RFC2311], [RFC2312], [RFC2313], [RFC2314], and
+ [RFC2315].
+
+ [SMIMEv3] refers to [RFC2630], [RFC2631], [RFC2632], [RFC2633],
+ [RFC2634], and [RFC5035].
+
+ [SMIMv3.1] refers to [RFC2634], [RFC3850], [RFC3851], [RFC3852], and
+ [RFC5035].
+
+6.2. Normative References
+
+ [ACAUTH] Farrell, S., Housley, R., and S. Turner, "An Internet
+ Attribute Certificate Profile for Authorization", RFC
+ 5755, January 2010.
+
+ [RFC2634] Hoffman, P., Ed., "Enhanced Security Services for
+ S/MIME", RFC 2634, June 1999.
+
+
+
+Ramsdell & Turner Standards Track [Page 17]
+
+RFC 5750 S/MIME 3.2 Certificate Handling January 2010
+
+
+ [RFC5035] Schaad, J., "Enhanced Security Services (ESS) Update:
+ Adding CertID Algorithm Agility", RFC 5035, August 2007.
+
+ [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
+ 5652, September 2009.
+
+ [FIPS186-2] National Institute of Standards and Technology (NIST),
+ "Digital Signature Standard (DSS)", FIPS Publication
+ 186-3, January 2000. [With Change Notice 1]
+
+ [FIPS186-3] National Institute of Standards and Technology (NIST),
+ FIPS Publication 186-3: Digital Signature Standard, June
+ 2009.
+
+ [KEYM] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+ Housley, R., and W. Polk, "Internet X.509 Public Key
+ Infrastructure Certificate and Certificate Revocation
+ List (CRL) Profile", RFC 5280, May 2008.
+
+ [KEYMALG] Bassham, L., Polk, W., and R. Housley, "Algorithms and
+ Identifiers for the Internet X.509 Public Key
+ Infrastructure Certificate and Certificate Revocation
+ List (CRL) Profile", RFC 3279, April 2002.
+
+ [KEYMALG2] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T.
+ Polk, "Internet X.509 Public Key Infrastructure:
+ Additional Algorithms and Identifiers for DSA and
+ ECDSA", RFC 5758, January 2010.
+
+ [MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [PKCS1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
+ Standards (PKCS) #1: RSA Cryptography Specifications
+ Version 2.1", RFC 3447, February 2003.
+
+ [PKCS9] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object
+ Classes and Attribute Types Version 2.0", RFC 2985,
+ November 2000.
+
+ [RSAPSS] Schaad, J., "Use of the RSASSA-PSS Signature Algorithm
+ in Cryptographic Message Syntax (CMS)", RFC 4056, June
+ 2005.
+
+
+
+
+
+
+
+
+Ramsdell & Turner Standards Track [Page 18]
+
+RFC 5750 S/MIME 3.2 Certificate Handling January 2010
+
+
+ [RSAOAEP] Schaad, J., Kaliski, B., and R. Housley, "Additional
+ Algorithms and Identifiers for RSA Cryptography for use
+ in the Internet X.509 Public Key Infrastructure
+ Certificate and Certificate Revocation List (CRL)
+ Profile", RFC 4055, June 2005.
+
+ [SMIME-MSG] Ramsdell, B. and S. Turner, "Secure/Multipurpose
+ Internet Mail Extensions (S/MIME) Version 3.2 Message
+ Specification", RFC 5751, January 2010.
+
+ [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002.
+ Information Technology - Abstract Syntax Notation One
+ (ASN.1): Specification of basic notation.
+
+6.3. Informative References
+
+ [PKCS6] RSA Laboratories, "PKCS #6: Extended-Certificate Syntax
+ Standard", November 1993.
+
+ [SECLABEL] Nicolls, W., "Implementing Company Classification Policy
+ with the S/MIME Security Label", RFC 3114, May 2002.
+
+ [RFC2311] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and
+ L. Repka, "S/MIME Version 2 Message Specification", RFC
+ 2311, March 1998.
+
+ [RFC2312] Dusse, S., Hoffman, P., Ramsdell, B., and J. Weinstein,
+ "S/MIME Version 2 Certificate Handling", RFC 2312, March
+ 1998.
+
+ [RFC2313] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", RFC
+ 2313, March 1998.
+
+ [RFC2314] Kaliski, B., "PKCS #10: Certification Request Syntax
+ Version 1.5", RFC 2314, March 1998.
+
+ [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax
+ Version 1.5", RFC 2315, March 1998.
+
+ [RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630,
+ June 1999.
+
+ [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC
+ 2631, June 1999.
+
+ [RFC2632] Ramsdell, B., Ed., "S/MIME Version 3 Certificate
+ Handling", RFC 2632, June 1999.
+
+
+
+
+Ramsdell & Turner Standards Track [Page 19]
+
+RFC 5750 S/MIME 3.2 Certificate Handling January 2010
+
+
+ [RFC2633] Ramsdell, B., Ed., "S/MIME Version 3 Message
+ Specification", RFC 2633, June 1999.
+
+ [RFC3850] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
+ Extensions (S/MIME) Version 3.1 Certificate Handling",
+ RFC 3850, July 2004.
+
+ [RFC3851] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
+ Extensions (S/MIME) Version 3.1 Message Specification",
+ RFC 3851, July 2004.
+
+ [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
+ 3852, July 2004.
+
+ [SP800-57] National Institute of Standards and Technology (NIST),
+ Special Publication 800-57: Recommendation for Key
+ Management, August 2005.
+
+ [X.500] ITU-T Recommendation X.500 (1997) | ISO/IEC 9594-
+ 1:1997, Information technology - Open Systems
+ Interconnection - The Directory: Overview of concepts,
+ models and services.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ramsdell & Turner Standards Track [Page 20]
+
+RFC 5750 S/MIME 3.2 Certificate Handling January 2010
+
+
+Appendix A. Moving S/MIME v2 Certificate Handling to Historic Status
+
+ The S/MIME v3 [SMIMEv3], v3.1 [SMIMEv3.1], and v3.2 (this document)
+ are backwards compatible with the S/MIME v2 Certificate Handling
+ Specification [SMIMEv2], with the exception of the algorithms
+ (dropped RC2/40 requirement and added DSA and RSASSA-PSS
+ requirements). Therefore, it is recommended that RFC 2312 [SMIMEv2]
+ be moved to Historic status.
+
+Appendix B. Acknowledgments
+
+ Many thanks go out to the other authors of the S/MIME v2 RFC: Steve
+ Dusse, Paul Hoffman, and Jeff Weinstein. Without v2, there wouldn't
+ be a v3, v3.1, or v3.2.
+
+ A number of the members of the S/MIME Working Group have also worked
+ very hard and contributed to this document. Any list of people is
+ doomed to omission, and for that I apologize. In alphabetical order,
+ the following people stand out in my mind because they made direct
+ contributions to this document.
+
+ Bill Flanigan, Trevor Freeman, Elliott Ginsburg, Alfred Hoenes, Paul
+ Hoffman, Russ Housley, David P. Kemp, Michael Myers, John Pawling,
+ Denis Pinkas, and Jim Schaad.
+
+Authors' Addresses
+
+ Blake Ramsdell
+ Brute Squad Labs, Inc.
+
+ EMail: blaker gmail com
+
+
+ Sean Turner
+ IECA, Inc.
+ 3057 Nutley Street, Suite 106
+ Fairfax, VA 22031
+ USA
+
+ EMail: turners ieca com
+
+
+
+
+
+
+
+
+
+
+
+Ramsdell & Turner Standards Track [Page 21]
+
diff --git a/rfc/rfc5751.txt b/rfc/rfc5751.txt
new file mode 100644
index 0000000..8d1dd21
--- /dev/null
+++ b/rfc/rfc5751.txt
@@ -0,0 +1,2523 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) B. Ramsdell
+Request for Comments: 5751 Brute Squad Labs
+Obsoletes: 3851 S. Turner
+Category: Standards Track IECA
+ISSN: 2070-1721 January 2010
+
+
+ Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2
+ Message Specification
+
+Abstract
+
+ This document defines Secure/Multipurpose Internet Mail Extensions
+ (S/MIME) version 3.2. S/MIME provides a consistent way to send and
+ receive secure MIME data. Digital signatures provide authentication,
+ message integrity, and non-repudiation with proof of origin.
+ Encryption provides data confidentiality. Compression can be used to
+ reduce data size. This document obsoletes RFC 3851.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by
+ the Internet Engineering Steering Group (IESG). Further
+ information on Internet Standards is available in Section 2 of
+ RFC 5741.
+
+ Information about the current status of this document, any
+ errata, and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc5751.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ramsdell & Turner Standards Track [Page 1]
+
+RFC 5751 S/MIME 3.2 Message Specification January 2010
+
+
+Copyright Notice
+
+ Copyright (c) 2010 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.
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+ the copyright in such materials, this document may not be modified
+ outside the IETF Standards Process, and derivative works of it may
+ not be created outside the IETF Standards Process, except to format
+ it for publication as an RFC or to translate it into languages other
+ than English.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ramsdell & Turner Standards Track [Page 2]
+
+RFC 5751 S/MIME 3.2 Message Specification January 2010
+
+
+Table of Contents
+
+ 1. Introduction ....................................................4
+ 1.1. Specification Overview .....................................4
+ 1.2. Definitions ................................................5
+ 1.3. Conventions Used in This Document ..........................6
+ 1.4. Compatibility with Prior Practice of S/MIME ................7
+ 1.5. Changes from S/MIME v3 to S/MIME v3.1 ......................7
+ 1.6. Changes since S/MIME v3.1 ..................................7
+ 2. CMS Options .....................................................9
+ 2.1. DigestAlgorithmIdentifier ..................................9
+ 2.2. SignatureAlgorithmIdentifier ...............................9
+ 2.3. KeyEncryptionAlgorithmIdentifier ..........................10
+ 2.4. General Syntax ............................................11
+ 2.5. Attributes and the SignerInfo Type ........................12
+ 2.6. SignerIdentifier SignerInfo Type ..........................16
+ 2.7. ContentEncryptionAlgorithmIdentifier ......................16
+ 3. Creating S/MIME Messages .......................................18
+ 3.1. Preparing the MIME Entity for Signing, Enveloping,
+ or Compressing ............................................19
+ 3.2. The application/pkcs7-mime Media Type .....................23
+ 3.3. Creating an Enveloped-Only Message ........................25
+ 3.4. Creating a Signed-Only Message ............................26
+ 3.5. Creating a Compressed-Only Message ........................30
+ 3.6. Multiple Operations .......................................30
+ 3.7. Creating a Certificate Management Message .................31
+ 3.8. Registration Requests .....................................32
+ 3.9. Identifying an S/MIME Message .............................32
+ 4. Certificate Processing .........................................32
+ 4.1. Key Pair Generation .......................................33
+ 4.2. Signature Generation ......................................33
+ 4.3. Signature Verification ....................................34
+ 4.4. Encryption ................................................34
+ 4.5. Decryption ................................................34
+ 5. IANA Considerations ............................................34
+ 5.1. Media Type for application/pkcs7-mime .....................34
+ 5.2. Media Type for application/pkcs7-signature ................35
+ 6. Security Considerations ........................................36
+ 7. References .....................................................38
+ 7.1. Reference Conventions .....................................38
+ 7.2. Normative References ......................................39
+ 7.3. Informative References ....................................41
+ Appendix A. ASN.1 Module ..........................................43
+ Appendix B. Moving S/MIME v2 Message Specification to Historic
+ Status ................................................45
+ Appendix C. Acknowledgments .......................................45
+
+
+
+
+
+Ramsdell & Turner Standards Track [Page 3]
+
+RFC 5751 S/MIME 3.2 Message Specification January 2010
+
+
+1. Introduction
+
+ S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a
+ consistent way to send and receive secure MIME data. Based on the
+ popular Internet MIME standard, S/MIME provides the following
+ cryptographic security services for electronic messaging
+ applications: authentication, message integrity and non-repudiation
+ of origin (using digital signatures), and data confidentiality (using
+ encryption). As a supplementary service, S/MIME provides for message
+ compression.
+
+ S/MIME can be used by traditional mail user agents (MUAs) to add
+ cryptographic security services to mail that is sent, and to
+ interpret cryptographic security services in mail that is received.
+ However, S/MIME is not restricted to mail; it can be used with any
+ transport mechanism that transports MIME data, such as HTTP or SIP.
+ As such, S/MIME takes advantage of the object-based features of MIME
+ and allows secure messages to be exchanged in mixed-transport
+ systems.
+
+ Further, S/MIME can be used in automated message transfer agents that
+ use cryptographic security services that do not require any human
+ intervention, such as the signing of software-generated documents and
+ the encryption of FAX messages sent over the Internet.
+
+1.1. Specification Overview
+
+ This document describes a protocol for adding cryptographic signature
+ and encryption services to MIME data. The MIME standard [MIME-SPEC]
+ provides a general structure for the content of Internet messages and
+ allows extensions for new content-type-based applications.
+
+ This specification defines how to create a MIME body part that has
+ been cryptographically enhanced according to the Cryptographic
+ Message Syntax (CMS) RFC 5652 [CMS], which is derived from PKCS #7
+ [PKCS-7]. This specification also defines the application/pkcs7-mime
+ media type that can be used to transport those body parts.
+
+ This document also discusses how to use the multipart/signed media
+ type defined in [MIME-SECURE] to transport S/MIME signed messages.
+ multipart/signed is used in conjunction with the application/pkcs7-
+ signature media type, which is used to transport a detached S/MIME
+ signature.
+
+
+
+
+
+
+
+
+Ramsdell & Turner Standards Track [Page 4]
+
+RFC 5751 S/MIME 3.2 Message Specification January 2010
+
+
+ In order to create S/MIME messages, an S/MIME agent MUST follow the
+ specifications in this document, as well as the specifications listed
+ in the Cryptographic Message Syntax document [CMS], [CMSALG],
+ [RSAPSS], [RSAOAEP], and [CMS-SHA2].
+
+ Throughout this specification, there are requirements and
+ recommendations made for how receiving agents handle incoming
+ messages. There are separate requirements and recommendations for
+ how sending agents create outgoing messages. In general, the best
+ strategy is to "be liberal in what you receive and conservative in
+ what you send". Most of the requirements are placed on the handling
+ of incoming messages, while the recommendations are mostly on the
+ creation of outgoing messages.
+
+ The separation for requirements on receiving agents and sending
+ agents also derives from the likelihood that there will be S/MIME
+ systems that involve software other than traditional Internet mail
+ clients. S/MIME can be used with any system that transports MIME
+ data. An automated process that sends an encrypted message might not
+ be able to receive an encrypted message at all, for example. Thus,
+ the requirements and recommendations for the two types of agents are
+ listed separately when appropriate.
+
+1.2. Definitions
+
+ For the purposes of this specification, the following definitions
+ apply.
+
+ ASN.1: Abstract Syntax Notation One, as defined in ITU-T
+ Recommendation X.680 [X.680].
+
+ BER: Basic Encoding Rules for ASN.1, as defined in ITU-
+ T Recommendation X.690 [X.690].
+
+ Certificate: A type that binds an entity's name to a public key
+ with a digital signature.
+
+ DER: Distinguished Encoding Rules for ASN.1, as defined
+ in ITU-T Recommendation X.690 [X.690].
+
+ 7-bit data: Text data with lines less than 998 characters
+ long, where none of the characters have the 8th
+ bit set, and there are no NULL characters. <CR>
+ and <LF> occur only as part of a <CR><LF> end-of-
+ line delimiter.
+
+
+
+
+
+
+Ramsdell & Turner Standards Track [Page 5]
+
+RFC 5751 S/MIME 3.2 Message Specification January 2010
+
+
+ 8-bit data: Text data with lines less than 998 characters, and
+ where none of the characters are NULL characters.
+ <CR> and <LF> occur only as part of a <CR><LF>
+ end-of-line delimiter.
+
+ Binary data: Arbitrary data.
+
+ Transfer encoding: A reversible transformation made on data so 8-bit
+ or binary data can be sent via a channel that only
+ transmits 7-bit data.
+
+ Receiving agent: Software that interprets and processes S/MIME CMS
+ objects, MIME body parts that contain CMS content
+ types, or both.
+
+ Sending agent: Software that creates S/MIME CMS content types,
+ MIME body parts that contain CMS content types, or
+ both.
+
+ S/MIME agent: User software that is a receiving agent, a sending
+ agent, or both.
+
+1.3. Conventions Used in This Document
+
+ 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 [MUSTSHOULD].
+
+ We define some additional terms here:
+
+ SHOULD+ This term means the same as SHOULD. However, the authors
+ expect that a requirement marked as SHOULD+ will be
+ promoted at some future time to be a MUST.
+
+ SHOULD- This term means the same as SHOULD. However, the authors
+ expect that a requirement marked as SHOULD- will be demoted
+ to a MAY in a future version of this document.
+
+ MUST- This term means the same as MUST. However, the authors
+ expect that this requirement will no longer be a MUST in a
+ future document. Although its status will be determined at
+ a later time, it is reasonable to expect that if a future
+ revision of a document alters the status of a MUST-
+ requirement, it will remain at least a SHOULD or a SHOULD-.
+
+
+
+
+
+
+
+Ramsdell & Turner Standards Track [Page 6]
+
+RFC 5751 S/MIME 3.2 Message Specification January 2010
+
+
+1.4. Compatibility with Prior Practice of S/MIME
+
+ S/MIME version 3.2 agents ought to attempt to have the greatest
+ interoperability possible with agents for prior versions of S/MIME.
+ S/MIME version 2 is described in RFC 2311 through RFC 2315 inclusive
+ [SMIMEv2], S/MIME version 3 is described in RFC 2630 through RFC 2634
+ inclusive and RFC 5035 [SMIMEv3], and S/MIME version 3.1 is described
+ in RFC 3850, RFC 3851, RFC 3852, RFC 2634, and RFC 5035 [SMIMEv3.1].
+ RFC 2311 also has historical information about the development of
+ S/MIME.
+
+1.5. Changes from S/MIME v3 to S/MIME v3.1
+
+ The RSA public key algorithm was changed to a MUST implement key
+ wrapping algorithm, and the Diffie-Hellman (DH) algorithm changed to
+ a SHOULD implement.
+
+ The AES symmetric encryption algorithm has been included as a SHOULD
+ implement.
+
+ The RSA public key algorithm was changed to a MUST implement
+ signature algorithm.
+
+ Ambiguous language about the use of "empty" SignedData messages to
+ transmit certificates was clarified to reflect that transmission of
+ Certificate Revocation Lists is also allowed.
+
+ The use of binary encoding for some MIME entities is now explicitly
+ discussed.
+
+ Header protection through the use of the message/rfc822 media type
+ has been added.
+
+ Use of the CompressedData CMS type is allowed, along with required
+ media type and file extension additions.
+
+1.6. Changes since S/MIME v3.1
+
+ Editorial changes, e.g., replaced "MIME type" with "media type",
+ content-type with Content-Type.
+
+ Moved "Conventions Used in This Document" to Section 1.3. Added
+ definitions for SHOULD+, SHOULD-, and MUST-.
+
+ Section 1.1 and Appendix A: Added references to RFCs for RSASSA-PSS,
+ RSAES-OAEP, and SHA2 CMS algorithms. Added CMS Multiple Signers
+ Clarification to CMS reference.
+
+
+
+
+Ramsdell & Turner Standards Track [Page 7]
+
+RFC 5751 S/MIME 3.2 Message Specification January 2010
+
+
+ Section 1.2: Updated references to ASN.1 to X.680 and BER and DER to
+ X.690.
+
+ Section 1.4: Added references to S/MIME MSG 3.1 RFCs.
+
+ Section 2.1 (digest algorithm): SHA-256 added as MUST, SHA-1 and MD5
+ made SHOULD-.
+
+ Section 2.2 (signature algorithms): RSA with SHA-256 added as MUST,
+ and DSA with SHA-256 added as SHOULD+, RSA with SHA-1, DSA with
+ SHA-1, and RSA with MD5 changed to SHOULD-, and RSASSA-PSS with
+ SHA-256 added as SHOULD+. Also added note about what S/MIME v3.1
+ clients support.
+
+ Section 2.3 (key encryption): DH changed to SHOULD-, and RSAES-OAEP
+ added as SHOULD+. Elaborated requirements for key wrap algorithm.
+
+ Section 2.5.1: Added requirement that receiving agents MUST support
+ both GeneralizedTime and UTCTime.
+
+ Section 2.5.2: Replaced reference "sha1WithRSAEncryption" with
+ "sha256WithRSAEncryption", "DES-3EDE-CBC" with "AES-128 CBC", and
+ deleted the RC5 example.
+
+ Section 2.5.2.1: Deleted entire section (discussed deprecated RC2).
+
+ Section 2.7, 2.7.1, Appendix A: references to RC2/40 removed.
+
+ Section 2.7 (content encryption): AES-128 CBC added as MUST, AES-192
+ and AES-256 CBC SHOULD+, tripleDES now SHOULD-.
+
+ Section 2.7.1: Updated pointers from 2.7.2.1 through 2.7.2.4 to
+ 2.7.1.1 to 2.7.1.2.
+
+ Section 3.1.1: Removed text about MIME character sets.
+
+ Section 3.2.2 and 3.6: Replaced "encrypted" with "enveloped". Update
+ OID example to use AES-128 CBC oid.
+
+ Section 3.4.3.2: Replace micalg parameter for SHA-1 with sha-1.
+
+ Section 4: Updated reference to CERT v3.2.
+
+ Section 4.1: Updated RSA and DSA key size discussion. Moved last
+ four sentences to security considerations. Updated reference to
+ randomness requirements for security.
+
+
+
+
+
+Ramsdell & Turner Standards Track [Page 8]
+
+RFC 5751 S/MIME 3.2 Message Specification January 2010
+
+
+ Section 5: Added IANA registration templates to update media type
+ registry to point to this document as opposed to RFC 2311.
+
+ Section 6: Updated security considerations.
+
+ Section 7: Moved references from Appendix B to this section. Updated
+ references. Added informational references to SMIMEv2, SMIMEv3, and
+ SMIMEv3.1.
+
+ Appendix B: Added Appendix B to move S/MIME v2 to Historic status.
+
+2. CMS Options
+
+ CMS allows for a wide variety of options in content, attributes, and
+ algorithm support. This section puts forth a number of support
+ requirements and recommendations in order to achieve a base level of
+ interoperability among all S/MIME implementations. [CMSALG] and
+ [CMS-SHA2] provides additional details regarding the use of the
+ cryptographic algorithms. [ESS] provides additional details
+ regarding the use of additional attributes.
+
+2.1. DigestAlgorithmIdentifier
+
+ Sending and receiving agents MUST support SHA-256 [CMS-SHA2] and
+ SHOULD- support SHA-1 [CMSALG]. Receiving agents SHOULD- support MD5
+ [CMSALG] for the purpose of providing backward compatibility with
+ MD5-digested S/MIME v2 SignedData objects.
+
+2.2. SignatureAlgorithmIdentifier
+
+ Receiving agents:
+
+ - MUST support RSA with SHA-256.
+
+ - SHOULD+ support DSA with SHA-256.
+
+ - SHOULD+ support RSASSA-PSS with SHA-256.
+
+ - SHOULD- support RSA with SHA-1.
+
+ - SHOULD- support DSA with SHA-1.
+
+ - SHOULD- support RSA with MD5.
+
+
+
+
+
+
+
+
+Ramsdell & Turner Standards Track [Page 9]
+
+RFC 5751 S/MIME 3.2 Message Specification January 2010
+
+
+ Sending agents:
+
+ - MUST support RSA with SHA-256.
+
+ - SHOULD+ support DSA with SHA-256.
+
+ - SHOULD+ support RSASSA-PSS with SHA-256.
+
+ - SHOULD- support RSA with SHA-1 or DSA with SHA-1.
+
+ - SHOULD- support RSA with MD5.
+
+ See Section 4.1 for information on key size and algorithm references.
+
+ Note that S/MIME v3.1 clients support verifying id-dsa-with-sha1 and
+ rsaEncryption and might not implement sha256withRSAEncryption. Note
+ that S/MIME v3 clients might only implement signing or signature
+ verification using id-dsa-with-sha1, and might also use id-dsa as an
+ AlgorithmIdentifier in this field. Receiving clients SHOULD
+ recognize id-dsa as equivalent to id-dsa-with-sha1, and sending
+ clients MUST use id-dsa-with-sha1 if using that algorithm. Also note
+ that S/MIME v2 clients are only required to verify digital signatures
+ using the rsaEncryption algorithm with SHA-1 or MD5, and might not
+ implement id-dsa-with-sha1 or id-dsa at all.
+
+2.3. KeyEncryptionAlgorithmIdentifier
+
+ Receiving and sending agents:
+
+ - MUST support RSA Encryption, as specified in [CMSALG].
+
+ - SHOULD+ support RSAES-OAEP, as specified in [RSAOAEP].
+
+ - SHOULD- support DH ephemeral-static mode, as specified in
+ [CMSALG] and [SP800-57].
+
+ When DH ephemeral-static is used, a key wrap algorithm is also
+ specified in the KeyEncryptionAlgorithmIdentifier [CMS]. The
+ underlying encryption functions for the key wrap and content
+ encryption algorithm ([CMSALG] and [CMSAES]) and the key sizes for
+ the two algorithms MUST be the same (e.g., AES-128 key wrap algorithm
+ with AES-128 content encryption algorithm). As AES-128 CBC is the
+ mandatory-to-implement content encryption algorithm, the AES-128 key
+ wrap algorithm MUST also be supported when DH ephemeral-static is
+ used.
+
+
+
+
+
+
+Ramsdell & Turner Standards Track [Page 10]
+
+RFC 5751 S/MIME 3.2 Message Specification January 2010
+
+
+ Note that S/MIME v3.1 clients might only implement key encryption and
+ decryption using the rsaEncryption algorithm. Note that S/MIME v3
+ clients might only implement key encryption and decryption using the
+ Diffie-Hellman algorithm. Also note that S/MIME v2 clients are only
+ capable of decrypting content-encryption keys using the rsaEncryption
+ algorithm.
+
+2.4. General Syntax
+
+ There are several CMS content types. Of these, only the Data,
+ SignedData, EnvelopedData, and CompressedData content types are
+ currently used for S/MIME.
+
+2.4.1. Data Content Type
+
+ Sending agents MUST use the id-data content type identifier to
+ identify the "inner" MIME message content. For example, when
+ applying a digital signature to MIME data, the CMS SignedData
+ encapContentInfo eContentType MUST include the id-data object
+ identifier and the media type MUST be stored in the SignedData
+ encapContentInfo eContent OCTET STRING (unless the sending agent is
+ using multipart/signed, in which case the eContent is absent, per
+ Section 3.4.3 of this document). As another example, when applying
+ encryption to MIME data, the CMS EnvelopedData encryptedContentInfo
+ contentType MUST include the id-data object identifier and the
+ encrypted MIME content MUST be stored in the EnvelopedData
+ encryptedContentInfo encryptedContent OCTET STRING.
+
+2.4.2. SignedData Content Type
+
+ Sending agents MUST use the SignedData content type to apply a
+ digital signature to a message or, in a degenerate case where there
+ is no signature information, to convey certificates. Applying a
+ signature to a message provides authentication, message integrity,
+ and non-repudiation of origin.
+
+2.4.3. EnvelopedData Content Type
+
+ This content type is used to apply data confidentiality to a message.
+ A sender needs to have access to a public key for each intended
+ message recipient to use this service.
+
+2.4.4. CompressedData Content Type
+
+ This content type is used to apply data compression to a message.
+ This content type does not provide authentication, message integrity,
+ non-repudiation, or data confidentiality, and is only used to reduce
+ the message's size.
+
+
+
+Ramsdell & Turner Standards Track [Page 11]
+
+RFC 5751 S/MIME 3.2 Message Specification January 2010
+
+
+ See Section 3.6 for further guidance on the use of this type in
+ conjunction with other CMS types.
+
+2.5. Attributes and the SignerInfo Type
+
+ The SignerInfo type allows the inclusion of unsigned and signed
+ attributes along with a signature.
+
+ Receiving agents MUST be able to handle zero or one instance of each
+ of the signed attributes listed here. Sending agents SHOULD generate
+ one instance of each of the following signed attributes in each
+ S/MIME message:
+
+ - Signing Time (section (Section 2.5.1 in this document)
+
+ - SMIME Capabilities (section (Section 2.5.2 in this document)
+
+ - Encryption Key Preference (section (Section 2.5.3 in this
+ document)
+
+ - Message Digest (section (Section 11.2 in [CMS])
+
+ - Content Type (section (Section 11.1 in [CMS])
+
+ Further, receiving agents SHOULD be able to handle zero or one
+ instance of the signingCertificate and signingCertificatev2 signed
+ attributes, as defined in Section 5 of RFC 2634 [ESS] and Section 3
+ of RFC 5035 [ESS].
+
+ Sending agents SHOULD generate one instance of the signingCertificate
+ or signingCertificatev2 signed attribute in each SignerInfo
+ structure.
+
+ Additional attributes and values for these attributes might be
+ defined in the future. Receiving agents SHOULD handle attributes or
+ values that they do not recognize in a graceful manner.
+
+ Interactive sending agents that include signed attributes that are
+ not listed here SHOULD display those attributes to the user, so that
+ the user is aware of all of the data being signed.
+
+2.5.1. Signing Time Attribute
+
+ The signing-time attribute is used to convey the time that a message
+ was signed. The time of signing will most likely be created by a
+ message originator and therefore is only as trustworthy as the
+ originator.
+
+
+
+
+Ramsdell & Turner Standards Track [Page 12]
+
+RFC 5751 S/MIME 3.2 Message Specification January 2010
+
+
+ Sending agents MUST encode signing time through the year 2049 as
+ UTCTime; signing times in 2050 or later MUST be encoded as
+ GeneralizedTime. When the UTCTime CHOICE is used, S/MIME agents MUST
+ interpret the year field (YY) as follows:
+
+ If YY is greater than or equal to 50, the year is interpreted as
+ 19YY; if YY is less than 50, the year is interpreted as 20YY.
+
+ Receiving agents MUST be able to process signing-time attributes that
+ are encoded in either UTCTime or GeneralizedTime.
+
+2.5.2. SMIME Capabilities Attribute
+
+ The SMIMECapabilities attribute includes signature algorithms (such
+ as "sha256WithRSAEncryption"), symmetric algorithms (such as "AES-128
+ CBC"), and key encipherment algorithms (such as "rsaEncryption").
+ There are also several identifiers that indicate support for other
+ optional features such as binary encoding and compression. The
+ SMIMECapabilities were designed to be flexible and extensible so
+ that, in the future, a means of identifying other capabilities and
+ preferences such as certificates can be added in a way that will not
+ cause current clients to break.
+
+ If present, the SMIMECapabilities attribute MUST be a
+ SignedAttribute; it MUST NOT be an UnsignedAttribute. CMS defines
+ SignedAttributes as a SET OF Attribute. The SignedAttributes in a
+ signerInfo MUST NOT include multiple instances of the
+ SMIMECapabilities attribute. CMS defines the ASN.1 syntax for
+ Attribute to include attrValues SET OF AttributeValue. A
+ SMIMECapabilities attribute MUST only include a single instance of
+ AttributeValue. There MUST NOT be zero or multiple instances of
+ AttributeValue present in the attrValues SET OF AttributeValue.
+
+ The semantics of the SMIMECapabilities attribute specify a partial
+ list as to what the client announcing the SMIMECapabilities can
+ support. A client does not have to list every capability it
+ supports, and need not list all its capabilities so that the
+ capabilities list doesn't get too long. In an SMIMECapabilities
+ attribute, the object identifiers (OIDs) are listed in order of their
+ preference, but SHOULD be separated logically along the lines of
+ their categories (signature algorithms, symmetric algorithms, key
+ encipherment algorithms, etc.).
+
+ The structure of the SMIMECapabilities attribute is to facilitate
+ simple table lookups and binary comparisons in order to determine
+ matches. For instance, the DER-encoding for the SMIMECapability for
+ AES-128 CBC MUST be identically encoded regardless of the
+ implementation. Because of the requirement for identical encoding,
+
+
+
+Ramsdell & Turner Standards Track [Page 13]
+
+RFC 5751 S/MIME 3.2 Message Specification January 2010
+
+
+ individuals documenting algorithms to be used in the
+ SMIMECapabilities attribute SHOULD explicitly document the correct
+ byte sequence for the common cases.
+
+ For any capability, the associated parameters for the OID MUST
+ specify all of the parameters necessary to differentiate between two
+ instances of the same algorithm.
+
+ The OIDs that correspond to algorithms SHOULD use the same OID as the
+ actual algorithm, except in the case where the algorithm usage is
+ ambiguous from the OID. For instance, in an earlier specification,
+ rsaEncryption was ambiguous because it could refer to either a
+ signature algorithm or a key encipherment algorithm. In the event
+ that an OID is ambiguous, it needs to be arbitrated by the maintainer
+ of the registered SMIMECapabilities list as to which type of
+ algorithm will use the OID, and a new OID MUST be allocated under the
+ smimeCapabilities OID to satisfy the other use of the OID.
+
+ The registered SMIMECapabilities list specifies the parameters for
+ OIDs that need them, most notably key lengths in the case of
+ variable-length symmetric ciphers. In the event that there are no
+ differentiating parameters for a particular OID, the parameters MUST
+ be omitted, and MUST NOT be encoded as NULL. Additional values for
+ the SMIMECapabilities attribute might be defined in the future.
+ Receiving agents MUST handle a SMIMECapabilities object that has
+ values that it does not recognize in a graceful manner.
+
+ Section 2.7.1 explains a strategy for caching capabilities.
+
+2.5.3. Encryption Key Preference Attribute
+
+ The encryption key preference attribute allows the signer to
+ unambiguously describe which of the signer's certificates has the
+ signer's preferred encryption key. This attribute is designed to
+ enhance behavior for interoperating with those clients that use
+ separate keys for encryption and signing. This attribute is used to
+ convey to anyone viewing the attribute which of the listed
+ certificates is appropriate for encrypting a session key for future
+ encrypted messages.
+
+ If present, the SMIMEEncryptionKeyPreference attribute MUST be a
+ SignedAttribute; it MUST NOT be an UnsignedAttribute. CMS defines
+ SignedAttributes as a SET OF Attribute. The SignedAttributes in a
+ signerInfo MUST NOT include multiple instances of the
+ SMIMEEncryptionKeyPreference attribute. CMS defines the ASN.1 syntax
+ for Attribute to include attrValues SET OF AttributeValue. A
+ SMIMEEncryptionKeyPreference attribute MUST only include a single
+
+
+
+
+Ramsdell & Turner Standards Track [Page 14]
+
+RFC 5751 S/MIME 3.2 Message Specification January 2010
+
+
+ instance of AttributeValue. There MUST NOT be zero or multiple
+ instances of AttributeValue present in the attrValues SET OF
+ AttributeValue.
+
+ The sending agent SHOULD include the referenced certificate in the
+ set of certificates included in the signed message if this attribute
+ is used. The certificate MAY be omitted if it has been previously
+ made available to the receiving agent. Sending agents SHOULD use
+ this attribute if the commonly used or preferred encryption
+ certificate is not the same as the certificate used to sign the
+ message.
+
+ Receiving agents SHOULD store the preference data if the signature on
+ the message is valid and the signing time is greater than the
+ currently stored value. (As with the SMIMECapabilities, the clock
+ skew SHOULD be checked and the data not used if the skew is too
+ great.) Receiving agents SHOULD respect the sender's encryption key
+ preference attribute if possible. This, however, represents only a
+ preference and the receiving agent can use any certificate in
+ replying to the sender that is valid.
+
+ Section 2.7.1 explains a strategy for caching preference data.
+
+2.5.3.1. Selection of Recipient Key Management Certificate
+
+ In order to determine the key management certificate to be used when
+ sending a future CMS EnvelopedData message for a particular
+ recipient, the following steps SHOULD be followed:
+
+ - If an SMIMEEncryptionKeyPreference attribute is found in a
+ SignedData object received from the desired recipient, this
+ identifies the X.509 certificate that SHOULD be used as the X.509
+ key management certificate for the recipient.
+
+ - If an SMIMEEncryptionKeyPreference attribute is not found in a
+ SignedData object received from the desired recipient, the set of
+ X.509 certificates SHOULD be searched for a X.509 certificate with
+ the same subject name as the signer of a X.509 certificate that can
+ be used for key management.
+
+ - Or use some other method of determining the user's key management
+ key. If a X.509 key management certificate is not found, then
+ encryption cannot be done with the signer of the message. If
+ multiple X.509 key management certificates are found, the S/MIME
+ agent can make an arbitrary choice between them.
+
+
+
+
+
+
+Ramsdell & Turner Standards Track [Page 15]
+
+RFC 5751 S/MIME 3.2 Message Specification January 2010
+
+
+2.6. SignerIdentifier SignerInfo Type
+
+ S/MIME v3.2 implementations MUST support both issuerAndSerialNumber
+ and subjectKeyIdentifier. Messages that use the subjectKeyIdentifier
+ choice cannot be read by S/MIME v2 clients.
+
+ It is important to understand that some certificates use a value for
+ subjectKeyIdentifier that is not suitable for uniquely identifying a
+ certificate. Implementations MUST be prepared for multiple
+ certificates for potentially different entities to have the same
+ value for subjectKeyIdentifier, and MUST be prepared to try each
+ matching certificate during signature verification before indicating
+ an error condition.
+
+2.7. ContentEncryptionAlgorithmIdentifier
+
+ Sending and receiving agents:
+
+ - MUST support encryption and decryption with AES-128 CBC
+ [CMSAES].
+
+ - SHOULD+ support encryption and decryption with AES-192 CBC and
+ AES-256 CBC [CMSAES].
+
+ - SHOULD- support encryption and decryption with DES EDE3 CBC,
+ hereinafter called "tripleDES" [CMSALG].
+
+2.7.1. Deciding Which Encryption Method to Use
+
+ When a sending agent creates an encrypted message, it has to decide
+ which type of encryption to use. The decision process involves using
+ information garnered from the capabilities lists included in messages
+ received from the recipient, as well as out-of-band information such
+ as private agreements, user preferences, legal restrictions, and so
+ on.
+
+ Section 2.5.2 defines a method by which a sending agent can
+ optionally announce, among other things, its decrypting capabilities
+ in its order of preference. The following method for processing and
+ remembering the encryption capabilities attribute in incoming signed
+ messages SHOULD be used.
+
+ - If the receiving agent has not yet created a list of
+ capabilities for the sender's public key, then, after verifying
+ the signature on the incoming message and checking the
+ timestamp, the receiving agent SHOULD create a new list
+ containing at least the signing time and the symmetric
+ capabilities.
+
+
+
+Ramsdell & Turner Standards Track [Page 16]
+
+RFC 5751 S/MIME 3.2 Message Specification January 2010
+
+
+ - If such a list already exists, the receiving agent SHOULD verify
+ that the signing time in the incoming message is greater than
+ the signing time stored in the list and that the signature is
+ valid. If so, the receiving agent SHOULD update both the
+ signing time and capabilities in the list. Values of the
+ signing time that lie far in the future (that is, a greater
+ discrepancy than any reasonable clock skew), or a capabilities
+ list in messages whose signature could not be verified, MUST NOT
+ be accepted.
+
+ The list of capabilities SHOULD be stored for future use in creating
+ messages.
+
+ Before sending a message, the sending agent MUST decide whether it is
+ willing to use weak encryption for the particular data in the
+ message. If the sending agent decides that weak encryption is
+ unacceptable for this data, then the sending agent MUST NOT use a
+ weak algorithm. The decision to use or not use weak encryption
+ overrides any other decision in this section about which encryption
+ algorithm to use.
+
+ Sections 2.7.1.1 through 2.7.1.2 describe the decisions a sending
+ agent SHOULD use in deciding which type of encryption will be applied
+ to a message. These rules are ordered, so the sending agent SHOULD
+ make its decision in the order given.
+
+2.7.1.1. Rule 1: Known Capabilities
+
+ If the sending agent has received a set of capabilities from the
+ recipient for the message the agent is about to encrypt, then the
+ sending agent SHOULD use that information by selecting the first
+ capability in the list (that is, the capability most preferred by the
+ intended recipient) that the sending agent knows how to encrypt. The
+ sending agent SHOULD use one of the capabilities in the list if the
+ agent reasonably expects the recipient to be able to decrypt the
+ message.
+
+2.7.1.2. Rule 2: Unknown Capabilities, Unknown Version of S/MIME
+
+ If the following two conditions are met:
+
+ - the sending agent has no knowledge of the encryption
+ capabilities of the recipient, and
+
+ - the sending agent has no knowledge of the version of S/MIME of
+ the recipient,
+
+
+
+
+
+Ramsdell & Turner Standards Track [Page 17]
+
+RFC 5751 S/MIME 3.2 Message Specification January 2010
+
+
+ then the sending agent SHOULD use AES-128 because it is a stronger
+ algorithm and is required by S/MIME v3.2. If the sending agent
+ chooses not to use AES-128 in this step, it SHOULD use tripleDES.
+
+2.7.2. Choosing Weak Encryption
+
+ All algorithms that use 40-bit keys are considered by many to be weak
+ encryption. A sending agent that is controlled by a human SHOULD
+ allow a human sender to determine the risks of sending data using a
+ weak encryption algorithm before sending the data, and possibly allow
+ the human to use a stronger encryption method such as tripleDES or
+ AES.
+
+2.7.3. Multiple Recipients
+
+ If a sending agent is composing an encrypted message to a group of
+ recipients where the encryption capabilities of some of the
+ recipients do not overlap, the sending agent is forced to send more
+ than one message. Please note that if the sending agent chooses to
+ send a message encrypted with a strong algorithm, and then send the
+ same message encrypted with a weak algorithm, someone watching the
+ communications channel could learn the contents of the strongly
+ encrypted message simply by decrypting the weakly encrypted message.
+
+3. Creating S/MIME Messages
+
+ This section describes the S/MIME message formats and how they are
+ created. S/MIME messages are a combination of MIME bodies and CMS
+ content types. Several media types as well as several CMS content
+ types are used. The data to be secured is always a canonical MIME
+ entity. The MIME entity and other data, such as certificates and
+ algorithm identifiers, are given to CMS processing facilities that
+ produce a CMS object. Finally, the CMS object is wrapped in MIME.
+ The Enhanced Security Services for S/MIME [ESS] document provides
+ descriptions of how nested, secured S/MIME messages are formatted.
+ ESS provides a description of how a triple-wrapped S/MIME message is
+ formatted using multipart/signed and application/pkcs7-mime for the
+ signatures.
+
+ S/MIME provides one format for enveloped-only data, several formats
+ for signed-only data, and several formats for signed and enveloped
+ data. Several formats are required to accommodate several
+ environments, in particular for signed messages. The criteria for
+ choosing among these formats are also described.
+
+ The reader of this section is expected to understand MIME as
+ described in [MIME-SPEC] and [MIME-SECURE].
+
+
+
+
+Ramsdell & Turner Standards Track [Page 18]
+
+RFC 5751 S/MIME 3.2 Message Specification January 2010
+
+
+3.1. Preparing the MIME Entity for Signing, Enveloping, or Compressing
+
+ S/MIME is used to secure MIME entities. A MIME entity can be a sub-
+ part, sub-parts of a message, or the whole message with all its sub-
+ parts. A MIME entity that is the whole message includes only the
+ MIME message headers and MIME body, and does not include the RFC-822
+ header. Note that S/MIME can also be used to secure MIME entities
+ used in applications other than Internet mail. If protection of the
+ RFC-822 header is required, the use of the message/rfc822 media type
+ is explained later in this section.
+
+ The MIME entity that is secured and described in this section can be
+ thought of as the "inside" MIME entity. That is, it is the
+ "innermost" object in what is possibly a larger MIME message.
+ Processing "outside" MIME entities into CMS content types is
+ described in Sections 3.2, 3.4, and elsewhere.
+
+ The procedure for preparing a MIME entity is given in [MIME-SPEC].
+ The same procedure is used here with some additional restrictions
+ when signing. The description of the procedures from [MIME-SPEC] is
+ repeated here, but it is suggested that the reader refer to that
+ document for the exact procedure. This section also describes
+ additional requirements.
+
+ A single procedure is used for creating MIME entities that are to
+ have any combination of signing, enveloping, and compressing applied.
+ Some additional steps are recommended to defend against known
+ corruptions that can occur during mail transport that are of
+ particular importance for clear-signing using the multipart/signed
+ format. It is recommended that these additional steps be performed
+ on enveloped messages, or signed and enveloped messages, so that the
+ message can be forwarded to any environment without modification.
+
+ These steps are descriptive rather than prescriptive. The
+ implementer is free to use any procedure as long as the result is the
+ same.
+
+ Step 1. The MIME entity is prepared according to the local
+ conventions.
+
+ Step 2. The leaf parts of the MIME entity are converted to canonical
+ form.
+
+ Step 3. Appropriate transfer encoding is applied to the leaves of
+ the MIME entity.
+
+
+
+
+
+
+Ramsdell & Turner Standards Track [Page 19]
+
+RFC 5751 S/MIME 3.2 Message Specification January 2010
+
+
+ When an S/MIME message is received, the security services on the
+ message are processed, and the result is the MIME entity. That MIME
+ entity is typically passed to a MIME-capable user agent where it is
+ further decoded and presented to the user or receiving application.
+
+ 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.
+
+3.1.1. Canonicalization
+
+ Each MIME entity MUST be converted to a canonical form that is
+ uniquely and unambiguously representable in the environment where the
+ signature is created and the environment where the signature will be
+ verified. MIME entities MUST be canonicalized for enveloping and
+ compressing as well as signing.
+
+ The exact details of canonicalization depend on the actual media type
+ and subtype of an entity, and are not described here. Instead, the
+ standard for the particular media type SHOULD be consulted. For
+ example, canonicalization of type text/plain is different from
+ canonicalization of audio/basic. Other than text types, most types
+ have only one representation regardless of computing platform or
+ environment that can be considered their canonical representation.
+ In general, canonicalization will be performed by the non-security
+ part of the sending agent rather than the S/MIME implementation.
+
+ The most common and important canonicalization is for text, which is
+ often represented differently in different environments. MIME
+ entities of major type "text" MUST have both their line endings and
+ character set canonicalized. The line ending MUST be the pair of
+ characters <CR><LF>, and the charset SHOULD be a registered charset
+ [CHARSETS]. The details of the canonicalization are specified in
+ [MIME-SPEC].
+
+ Note that some charsets such as ISO-2022 have multiple
+ representations for the same characters. When preparing such text
+ for signing, the canonical representation specified for the charset
+ MUST be used.
+
+
+
+Ramsdell & Turner Standards Track [Page 20]
+
+RFC 5751 S/MIME 3.2 Message Specification January 2010
+
+
+3.1.2. Transfer Encoding
+
+ When generating any of the secured MIME entities below, except the
+ signing using the multipart/signed format, no transfer encoding is
+ required at all. S/MIME implementations MUST be able to deal with
+ binary MIME objects. If no Content-Transfer-Encoding header field is
+ present, the transfer encoding is presumed to be 7BIT.
+
+ S/MIME implementations SHOULD however use transfer encoding described
+ in Section 3.1.3 for all MIME entities they secure. The reason for
+ securing only 7-bit MIME entities, even for enveloped data that are
+ not exposed to the transport, is that it allows the MIME entity to be
+ handled in any environment without changing it. For example, a
+ trusted gateway might remove the envelope, but not the signature, of
+ a message, and then forward the signed message on to the end
+ recipient so that they can verify the signatures directly. If the
+ transport internal to the site is not 8-bit clean, such as on a wide-
+ area network with a single mail gateway, verifying the signature will
+ not be possible unless the original MIME entity was only 7-bit data.
+
+ S/MIME implementations that "know" that all intended recipients are
+ capable of handling inner (all but the outermost) binary MIME objects
+ SHOULD use binary encoding as opposed to a 7-bit-safe transfer
+ encoding for the inner entities. The use of a 7-bit-safe encoding
+ (such as base64) would unnecessarily expand the message size.
+ Implementations MAY "know" that recipient implementations are capable
+ of handling inner binary MIME entities either by interpreting the id-
+ cap-preferBinaryInside SMIMECapabilities attribute, by prior
+ agreement, or by other means.
+
+ If one or more intended recipients are unable to handle inner binary
+ MIME objects, or if this capability is unknown for any of the
+ intended recipients, S/MIME implementations SHOULD use transfer
+ encoding described in Section 3.1.3 for all MIME entities they
+ secure.
+
+3.1.3. Transfer Encoding for Signing Using multipart/signed
+
+ If a multipart/signed entity is ever to be transmitted over the
+ standard Internet SMTP infrastructure or other transport that is
+ constrained to 7-bit text, it MUST have transfer encoding applied so
+ that it is represented as 7-bit text. MIME entities that are 7-bit
+ data already need no transfer encoding. Entities such as 8-bit text
+ and binary data can be encoded with quoted-printable or base-64
+ transfer encoding.
+
+
+
+
+
+
+Ramsdell & Turner Standards Track [Page 21]
+
+RFC 5751 S/MIME 3.2 Message Specification January 2010
+
+
+ The primary reason for the 7-bit requirement is that the Internet
+ mail transport infrastructure cannot guarantee transport of 8-bit or
+ binary data. Even though many segments of the transport
+ infrastructure now handle 8-bit and even binary data, it is sometimes
+ not possible to know whether the transport path is 8-bit clean. If a
+ mail message with 8-bit data were to encounter a message transfer
+ agent that cannot transmit 8-bit or binary data, the agent has three
+ options, none of which are acceptable for a clear-signed message:
+
+ - The agent could change the transfer encoding; this would
+ invalidate the signature.
+
+ - The agent could transmit the data anyway, which would most likely
+ result in the 8th bit being corrupted; this too would invalidate
+ the signature.
+
+ - The agent could return the message to the sender.
+
+ [MIME-SECURE] prohibits an agent from changing the transfer encoding
+ of the first part of a multipart/signed message. If a compliant
+ agent that cannot transmit 8-bit or binary data encounters a
+ multipart/signed message with 8-bit or binary data in the first part,
+ it would have to return the message to the sender as undeliverable.
+
+3.1.4. Sample Canonical MIME Entity
+
+ This example shows a multipart/mixed message with full transfer
+ encoding. This message contains a text part and an attachment. The
+ sample message text includes characters that are not US-ASCII and
+ thus need to be transfer encoded. Though not shown here, the end of
+ each line is <CR><LF>. The line ending of the MIME headers, the
+ text, and the transfer encoded parts, all MUST be <CR><LF>.
+
+ Note that this example is not of an S/MIME message.
+
+ Content-Type: multipart/mixed; boundary=bar
+
+ --bar
+ Content-Type: text/plain; charset=iso-8859-1
+ Content-Transfer-Encoding: quoted-printable
+
+ =A1Hola Michael!
+
+ How do you like the new S/MIME specification?
+
+ It's generally a good idea to encode lines that begin with
+ From=20because some mail transport agents will insert a greater-
+ than (>) sign, thus invalidating the signature.
+
+
+
+Ramsdell & Turner Standards Track [Page 22]
+
+RFC 5751 S/MIME 3.2 Message Specification January 2010
+
+
+ Also, in some cases it might be desirable to encode any =20
+ trailing whitespace that occurs on lines in order to ensure =20
+ that the message signature is not invalidated when passing =20
+ a gateway that modifies such whitespace (like BITNET). =20
+
+ --bar
+ Content-Type: image/jpeg
+ Content-Transfer-Encoding: base64
+
+ iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
+ jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
+ uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
+ HOxEa44b+EI=
+
+ --bar--
+
+3.2. The application/pkcs7-mime Media Type
+
+ The application/pkcs7-mime media type is used to carry CMS content
+ types including EnvelopedData, SignedData, and CompressedData. The
+ details of constructing these entities are described in subsequent
+ sections. This section describes the general characteristics of the
+ application/pkcs7-mime media type.
+
+ The carried CMS object always contains a MIME entity that is prepared
+ as described in Section 3.1 if the eContentType is id-data. Other
+ contents MAY be carried when the eContentType contains different
+ values. See [ESS] for an example of this with signed receipts.
+
+ Since CMS content types are binary data, in most cases base-64
+ transfer encoding is appropriate, in particular, when used with SMTP
+ transport. The transfer encoding used depends on the transport
+ through which the object is to be sent, and is not a characteristic
+ of the media type.
+
+ Note that this discussion refers to the transfer encoding of the CMS
+ object or "outside" MIME entity. It is completely distinct from, and
+ unrelated to, the transfer encoding of the MIME entity secured by the
+ CMS object, the "inside" object, which is described in Section 3.1.
+
+ Because there are several types of application/pkcs7-mime objects, a
+ sending agent SHOULD do as much as possible to help a receiving agent
+ know about the contents of the object without forcing the receiving
+ agent to decode the ASN.1 for the object. The Content-Type header
+ field of all application/pkcs7-mime objects SHOULD include the
+ optional "smime-type" parameter, as described in the following
+ sections.
+
+
+
+
+Ramsdell & Turner Standards Track [Page 23]
+
+RFC 5751 S/MIME 3.2 Message Specification January 2010
+
+
+3.2.1. The name and filename Parameters
+
+ For the application/pkcs7-mime, sending agents SHOULD emit the
+ optional "name" parameter to the Content-Type field for compatibility
+ with older systems. Sending agents SHOULD also emit the optional
+ Content-Disposition field [CONTDISP] with the "filename" parameter.
+ If a sending agent emits the above parameters, the value of the
+ parameters SHOULD be a file name with the appropriate extension:
+
+ Media Type File Extension
+ application/pkcs7-mime (SignedData, EnvelopedData) .p7m
+ application/pkcs7-mime (degenerate SignedData .p7c
+ certificate management message)
+ application/pkcs7-mime (CompressedData) .p7z
+ application/pkcs7-signature (SignedData) .p7s
+
+ In addition, the file name SHOULD be limited to eight characters
+ followed by a three-letter extension. The eight-character filename
+ base can be any distinct name; the use of the filename base "smime"
+ SHOULD be used to indicate that the MIME entity is associated with
+ S/MIME.
+
+ Including a file name serves two purposes. It facilitates easier use
+ of S/MIME objects as files on disk. It also can convey type
+ information across gateways. When a MIME entity of type
+ application/pkcs7-mime (for example) arrives at a gateway that has no
+ special knowledge of S/MIME, it will default the entity's media type
+ to application/octet-stream and treat it as a generic attachment,
+ thus losing the type information. However, the suggested filename
+ for an attachment is often carried across a gateway. This often
+ allows the receiving systems to determine the appropriate application
+ to hand the attachment off to, in this case, a stand-alone S/MIME
+ processing application. Note that this mechanism is provided as a
+ convenience for implementations in certain environments. A proper
+ S/MIME implementation MUST use the media types and MUST NOT rely on
+ the file extensions.
+
+3.2.2. The smime-type Parameter
+
+ The application/pkcs7-mime content type defines the optional "smime-
+ type" parameter. The intent of this parameter is to convey details
+ about the security applied (signed or enveloped) along with
+ information about the contained content. This specification defines
+ the following smime-types.
+
+
+
+
+
+
+
+Ramsdell & Turner Standards Track [Page 24]
+
+RFC 5751 S/MIME 3.2 Message Specification January 2010
+
+
+ Name CMS Type Inner Content
+ enveloped-data EnvelopedData id-data
+ signed-data SignedData id-data
+ certs-only SignedData none
+ compressed-data CompressedData id-data
+
+ In order for consistency to be obtained with future specifications,
+ the following guidelines SHOULD be followed when assigning a new
+ smime-type parameter.
+
+ 1. If both signing and encryption can be applied to the content,
+ then two values for smime-type SHOULD be assigned "signed-*"
+ and "enveloped-*". If one operation can be assigned, then this
+ can be omitted. Thus, since "certs-only" can only be signed,
+ "signed-" is omitted.
+
+ 2. A common string for a content OID SHOULD be assigned. We use
+ "data" for the id-data content OID when MIME is the inner
+ content.
+
+ 3. If no common string is assigned, then the common string of
+ "OID.<oid>" is recommended (for example,
+ "OID.2.16.840.1.101.3.4.1.2" would be AES-128 CBC).
+
+ It is explicitly intended that this field be a suitable hint for mail
+ client applications to indicate whether a message is "signed" or
+ "enveloped" without having to tunnel into the CMS payload.
+
+3.3. Creating an Enveloped-Only Message
+
+ This section describes the format for enveloping a MIME entity
+ without signing it. It is important to note that sending enveloped
+ but not signed messages does not provide for data integrity. It is
+ possible to replace ciphertext in such a way that the processed
+ message will still be valid, but the meaning can be altered.
+
+ Step 1. The MIME entity to be enveloped is prepared according to
+ Section 3.1.
+
+ Step 2. The MIME entity and other required data is processed into a
+ CMS object of type EnvelopedData. In addition to encrypting
+ a copy of the content-encryption key for each recipient, a
+ copy of the content-encryption key SHOULD be encrypted for
+ the originator and included in the EnvelopedData (see [CMS],
+ Section 6).
+
+ Step 3. The EnvelopedData object is wrapped in a CMS ContentInfo
+ object.
+
+
+
+Ramsdell & Turner Standards Track [Page 25]
+
+RFC 5751 S/MIME 3.2 Message Specification January 2010
+
+
+ Step 4. The ContentInfo object is inserted into an
+ application/pkcs7-mime MIME entity.
+
+ The smime-type parameter for enveloped-only messages is "enveloped-
+ data". The file extension for this type of message is ".p7m".
+
+ A sample message would be:
+
+ Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
+ name=smime.p7m
+ Content-Transfer-Encoding: base64
+ Content-Disposition: attachment; filename=smime.p7m
+
+ rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
+ 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
+ f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
+ 0GhIGfHfQbnj756YT64V
+
+3.4. Creating a Signed-Only Message
+
+ There are two formats for signed messages defined for S/MIME:
+
+ - application/pkcs7-mime with SignedData.
+
+ - multipart/signed.
+
+ In general, the multipart/signed form is preferred for sending, and
+ receiving agents MUST be able to handle both.
+
+3.4.1. Choosing a Format for Signed-Only Messages
+
+ There are no hard-and-fast rules as to when a particular signed-only
+ format is chosen. It depends on the capabilities of all the
+ receivers and the relative importance of receivers with S/MIME
+ facilities being able to verify the signature versus the importance
+ of receivers without S/MIME software being able to view the message.
+
+ Messages signed using the multipart/signed format can always be
+ viewed by the receiver whether or not they have S/MIME software.
+ They can also be viewed whether they are using a MIME-native user
+ agent or they have messages translated by a gateway. In this
+ context, "be viewed" means the ability to process the message
+ essentially as if it were not a signed message, including any other
+ MIME structure the message might have.
+
+
+
+
+
+
+
+Ramsdell & Turner Standards Track [Page 26]
+
+RFC 5751 S/MIME 3.2 Message Specification January 2010
+
+
+ Messages signed using the SignedData format cannot be viewed by a
+ recipient unless they have S/MIME facilities. However, the
+ SignedData format protects the message content from being changed by
+ benign intermediate agents. Such agents might do line wrapping or
+ content-transfer encoding changes that would break the signature.
+
+3.4.2. Signing Using application/pkcs7-mime with SignedData
+
+ This signing format uses the application/pkcs7-mime media type. The
+ steps to create this format are:
+
+ Step 1. The MIME entity is prepared according to Section 3.1.
+
+ Step 2. The MIME entity and other required data are processed into a
+ CMS object of type SignedData.
+
+ Step 3. The SignedData object is wrapped in a CMS ContentInfo
+ object.
+
+ Step 4. The ContentInfo object is inserted into an
+ application/pkcs7-mime MIME entity.
+
+ The smime-type parameter for messages using application/pkcs7-mime
+ with SignedData is "signed-data". The file extension for this type
+ of message is ".p7m".
+
+ A sample message would be:
+
+ Content-Type: application/pkcs7-mime; smime-type=signed-data;
+ name=smime.p7m
+ Content-Transfer-Encoding: base64
+ Content-Disposition: attachment; filename=smime.p7m
+
+ 567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7
+ 77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH
+ HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh
+ 6YT64V0GhIGfHfQbnj75
+
+3.4.3. Signing Using the multipart/signed Format
+
+ This format is a clear-signing format. Recipients without any S/MIME
+ or CMS processing facilities are able to view the message. It makes
+ use of the multipart/signed media type described in [MIME-SECURE].
+ The multipart/signed media type has two parts. The first part
+ contains the MIME entity that is signed; the second part contains the
+ "detached signature" CMS SignedData object in which the
+ encapContentInfo eContent field is absent.
+
+
+
+
+Ramsdell & Turner Standards Track [Page 27]
+
+RFC 5751 S/MIME 3.2 Message Specification January 2010
+
+
+3.4.3.1. The application/pkcs7-signature Media Type
+
+ This media type always contains a CMS ContentInfo containing a single
+ CMS object of type SignedData. The SignedData encapContentInfo
+ eContent field MUST be absent. The signerInfos field contains the
+ signatures for the MIME entity.
+
+ The file extension for signed-only messages using application/pkcs7-
+ signature is ".p7s".
+
+3.4.3.2. Creating a multipart/signed Message
+
+ Step 1. The MIME entity to be signed is prepared according to
+ Section 3.1, taking special care for clear-signing.
+
+ Step 2. The MIME entity is presented to CMS processing in order to
+ obtain an object of type SignedData in which the
+ encapContentInfo eContent field is absent.
+
+ Step 3. The MIME entity is inserted into the first part of a
+ multipart/signed message with no processing other than that
+ described in Section 3.1.
+
+ Step 4. Transfer encoding is applied to the "detached signature" CMS
+ SignedData object, and it is inserted into a MIME entity of
+ type application/pkcs7-signature.
+
+ Step 5. The MIME entity of the application/pkcs7-signature is
+ inserted into the second part of the multipart/signed
+ entity.
+
+ The multipart/signed Content-Type has two required parameters: the
+ protocol parameter and the micalg parameter.
+
+ The protocol parameter MUST be "application/pkcs7-signature". Note
+ that quotation marks are required around the protocol parameter
+ because MIME requires that the "/" character in the parameter value
+ MUST be quoted.
+
+ The micalg parameter allows for one-pass processing when the
+ signature is being verified. The value of the micalg parameter is
+ dependent on the message digest algorithm(s) used in the calculation
+ of the Message Integrity Check. If multiple message digest
+ algorithms are used, they MUST be separated by commas per [MIME-
+ SECURE]. The values to be placed in the micalg parameter SHOULD be
+ from the following:
+
+
+
+
+
+Ramsdell & Turner Standards Track [Page 28]
+
+RFC 5751 S/MIME 3.2 Message Specification January 2010
+
+
+ Algorithm Value Used
+
+ MD5 md5
+ SHA-1 sha-1
+ SHA-224 sha-224
+ SHA-256 sha-256
+ SHA-384 sha-384
+ SHA-512 sha-512
+ Any other (defined separately in algorithm profile or "unknown"
+ if not defined)
+
+ (Historical note: some early implementations of S/MIME emitted and
+ expected "rsa-md5", "rsa-sha1", and "sha1" for the micalg parameter.)
+ Receiving agents SHOULD be able to recover gracefully from a micalg
+ parameter value that they do not recognize. Future names for this
+ parameter will be consistent with the IANA "Hash Function Textual
+ Names" registry.
+
+3.4.3.3. Sample multipart/signed Message
+
+ Content-Type: multipart/signed;
+ protocol="application/pkcs7-signature";
+ micalg=sha1; boundary=boundary42
+
+ --boundary42
+ Content-Type: text/plain
+
+ This is a clear-signed message.
+
+ --boundary42
+ Content-Type: application/pkcs7-signature; name=smime.p7s
+ Content-Transfer-Encoding: base64
+ Content-Disposition: attachment; filename=smime.p7s
+
+ ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
+ 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
+ n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
+ 7GhIGfHfYT64VQbnj756
+
+ --boundary42--
+
+ The content that is digested (the first part of the multipart/signed)
+ consists of the bytes:
+
+ 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 74 65 78 74 2f 70 6c 61 69
+ 6e 0d 0a 0d 0a 54 68 69 73 20 69 73 20 61 20 63 6c 65 61 72 2d 73 69
+ 67 6e 65 64 20 6d 65 73 73 61 67 65 2e 0d 0a
+
+
+
+
+Ramsdell & Turner Standards Track [Page 29]
+
+RFC 5751 S/MIME 3.2 Message Specification January 2010
+
+
+3.5. Creating a Compressed-Only Message
+
+ This section describes the format for compressing a MIME entity.
+ Please note that versions of S/MIME prior to version 3.1 did not
+ specify any use of CompressedData, and will not recognize it. The
+ use of a capability to indicate the ability to receive CompressedData
+ is described in [CMSCOMPR] and is the preferred method for
+ compatibility.
+
+ Step 1. The MIME entity to be compressed is prepared according to
+ Section 3.1.
+
+ Step 2. The MIME entity and other required data are processed into a
+ CMS object of type CompressedData.
+
+ Step 3. The CompressedData object is wrapped in a CMS ContentInfo
+ object.
+
+ Step 4. The ContentInfo object is inserted into an
+ application/pkcs7-mime MIME entity.
+
+ The smime-type parameter for compressed-only messages is "compressed-
+ data". The file extension for this type of message is ".p7z".
+
+ A sample message would be:
+
+ Content-Type: application/pkcs7-mime; smime-type=compressed-data;
+ name=smime.p7z
+ Content-Transfer-Encoding: base64
+ Content-Disposition: attachment; filename=smime.p7z
+
+ rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
+ 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
+ f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
+ 0GhIGfHfQbnj756YT64V
+
+3.6. Multiple Operations
+
+ The signed-only, enveloped-only, and compressed-only MIME formats can
+ be nested. This works because these formats are all MIME entities
+ that encapsulate other MIME entities.
+
+ An S/MIME implementation MUST be able to receive and process
+ arbitrarily nested S/MIME within reasonable resource limits of the
+ recipient computer.
+
+
+
+
+
+
+Ramsdell & Turner Standards Track [Page 30]
+
+RFC 5751 S/MIME 3.2 Message Specification January 2010
+
+
+ It is possible to apply any of the signing, encrypting, and
+ compressing operations in any order. It is up to the implementer and
+ the user to choose. When signing first, the signatories are then
+ securely obscured by the enveloping. When enveloping first the
+ signatories are exposed, but it is possible to verify signatures
+ without removing the enveloping. This can be useful in an
+ environment where automatic signature verification is desired, as no
+ private key material is required to verify a signature.
+
+ There are security ramifications to choosing whether to sign first or
+ encrypt first. A recipient of a message that is encrypted and then
+ signed can validate that the encrypted block was unaltered, but
+ cannot determine any relationship between the signer and the
+ unencrypted contents of the message. A recipient of a message that
+ is signed then encrypted can assume that the signed message itself
+ has not been altered, but that a careful attacker could have changed
+ the unauthenticated portions of the encrypted message.
+
+ When using compression, keep the following guidelines in mind:
+
+ - Compression of binary encoded encrypted data is discouraged,
+ since it will not yield significant compression. Base64
+ encrypted data could very well benefit, however.
+
+ - If a lossy compression algorithm is used with signing, you will
+ need to compress first, then sign.
+
+3.7. Creating a Certificate Management Message
+
+ The certificate management message or MIME entity is used to
+ transport certificates and/or Certificate Revocation Lists, such as
+ in response to a registration request.
+
+ Step 1. The certificates and/or Certificate Revocation Lists are
+ made available to the CMS generating process that creates a
+ CMS object of type SignedData. The SignedData
+ encapContentInfo eContent field MUST be absent and
+ signerInfos field MUST be empty.
+
+ Step 2. The SignedData object is wrapped in a CMS ContentInfo
+ object.
+
+ Step 3. The ContentInfo object is enclosed in an
+ application/pkcs7-mime MIME entity.
+
+ The smime-type parameter for a certificate management message is
+ "certs-only". The file extension for this type of message is ".p7c".
+
+
+
+
+Ramsdell & Turner Standards Track [Page 31]
+
+RFC 5751 S/MIME 3.2 Message Specification January 2010
+
+
+3.8. Registration Requests
+
+ A sending agent that signs messages MUST have a certificate for the
+ signature so that a receiving agent can verify the signature. There
+ are many ways of getting certificates, such as through an exchange
+ with a certification authority, through a hardware token or diskette,
+ and so on.
+
+ S/MIME v2 [SMIMEv2] specified a method for "registering" public keys
+ with certificate authorities using an application/pkcs10 body part.
+ Since that time, the IETF PKIX Working Group has developed other
+ methods for requesting certificates. However, S/MIME v3.2 does not
+ require a particular certificate request mechanism.
+
+3.9. Identifying an S/MIME Message
+
+ Because S/MIME takes into account interoperation in non-MIME
+ environments, several different mechanisms are employed to carry the
+ type information, and it becomes a bit difficult to identify S/MIME
+ messages. The following table lists criteria for determining whether
+ or not a message is an S/MIME message. A message is considered an
+ S/MIME message if it matches any of the criteria listed below.
+
+ The file suffix in the table below comes from the "name" parameter in
+ the Content-Type header field, or the "filename" parameter on the
+ Content-Disposition header field. These parameters that give the
+ file suffix are not listed below as part of the parameter section.
+
+ Media type: application/pkcs7-mime
+ parameters: any
+ file suffix: any
+
+ Media type: multipart/signed
+ parameters: protocol="application/pkcs7-signature"
+ file suffix: any
+
+ Media type: application/octet-stream
+ parameters: any
+ file suffix: p7m, p7s, p7c, p7z
+
+4. Certificate Processing
+
+ A receiving agent MUST provide some certificate retrieval mechanism
+ in order to gain access to certificates for recipients of digital
+ envelopes. This specification does not cover how S/MIME agents
+ handle certificates, only what they do after a certificate has been
+ validated or rejected. S/MIME certificate issues are covered in
+ [CERT32].
+
+
+
+Ramsdell & Turner Standards Track [Page 32]
+
+RFC 5751 S/MIME 3.2 Message Specification January 2010
+
+
+ At a minimum, for initial S/MIME deployment, a user agent could
+ automatically generate a message to an intended recipient requesting
+ that recipient's certificate in a signed return message. Receiving
+ and sending agents SHOULD also provide a mechanism to allow a user to
+ "store and protect" certificates for correspondents in such a way so
+ as to guarantee their later retrieval.
+
+4.1. Key Pair Generation
+
+ All generated key pairs MUST be generated from a good source of non-
+ deterministic random input [RANDOM] and the private key MUST be
+ protected in a secure fashion.
+
+ An S/MIME user agent MUST NOT generate asymmetric keys less than 512
+ bits for use with the RSA or DSA signature algorithms.
+
+ For 512-bit RSA with SHA-1 see [CMSALG] and [FIPS186-2] without
+ Change Notice 1, for 512-bit RSA with SHA-256 see [CMS-SHA2] and
+ [FIPS186-2] without Change Notice 1, and for 1024-bit through
+ 2048-bit RSA with SHA-256 see [CMS-SHA2] and [FIPS186-2] with Change
+ Notice 1. The first reference provides the signature algorithm's
+ object identifier, and the second provides the signature algorithm's
+ definition.
+
+ For 512-bit DSA with SHA-1 see [CMSALG] and [FIPS186-2] without
+ Change Notice 1, for 512-bit DSA with SHA-256 see [CMS-SHA2] and
+ [FIPS186-2] without Change Notice 1, for 1024-bit DSA with SHA-1 see
+ [CMSALG] and [FIPS186-2] with Change Notice 1, for 1024-bit and above
+ DSA with SHA-256 see [CMS-SHA2] and [FIPS186-3]. The first reference
+ provides the signature algorithm's object identifier and the second
+ provides the signature algorithm's definition.
+
+ For RSASSA-PSS with SHA-256, see [RSAPSS]. For 1024-bit DH, see
+ [CMSALG]. For 1024-bit and larger DH, see [SP800-56A]; regardless,
+ use the KDF, which is from X9.42, specified in [CMSALG]. For RSAES-
+ OAEP, see [RSAOAEP].
+
+4.2. Signature Generation
+
+ The following are the requirements for an S/MIME agent generated RSA,
+ RSASSA-PSS, and DSA signatures:
+
+ key size <= 1023 : SHOULD NOT (see Security Considerations)
+ 1024 <= key size <= 2048 : SHOULD (see Security Considerations)
+ 2048 < key size : MAY (see Security Considerations)
+
+
+
+
+
+
+Ramsdell & Turner Standards Track [Page 33]
+
+RFC 5751 S/MIME 3.2 Message Specification January 2010
+
+
+4.3. Signature Verification
+
+ The following are the requirements for S/MIME receiving agents during
+ signature verification of RSA, RSASSA-PSS, and DSA signatures:
+
+ key size <= 1023 : MAY (see Security Considerations)
+ 1024 <= key size <= 2048 : MUST (see Security Considerations)
+ 2048 < key size : MAY (see Security Considerations)
+
+4.4. Encryption
+
+ The following are the requirements for an S/MIME agent when
+ establishing keys for content encryption using the RSA, RSA-OAEP, and
+ DH algorithms:
+
+ key size <= 1023 : SHOULD NOT (see Security Considerations)
+ 1024 <= key size <= 2048 : SHOULD (see Security Considerations)
+ 2048 < key size : MAY (see Security Considerations)
+
+4.5. Decryption
+
+ The following are the requirements for an S/MIME agent when
+ establishing keys for content decryption using the RSA, RSAES-OAEP,
+ and DH algorithms:
+
+ key size <= 1023 : MAY (see Security Considerations)
+ 1024 <= key size <= 2048 : MUST (see Security Considerations)
+ 2048 < key size : MAY (see Security Considerations)
+
+5. IANA Considerations
+
+ The following information updates the media type registration for
+ application/pkcs7-mime and application/pkcs7-signature to refer to
+ this document as opposed to RFC 2311.
+
+ Note that other documents can define additional MIME media types for
+ S/MIME.
+
+5.1. Media Type for application/pkcs7-mime
+
+ Type name: application
+
+ Subtype Name: pkcs7-mime
+
+ Required Parameters: NONE
+
+
+
+
+
+
+Ramsdell & Turner Standards Track [Page 34]
+
+RFC 5751 S/MIME 3.2 Message Specification January 2010
+
+
+ Optional Parameters: smime-type/signed-data
+ smime-type/enveloped-data
+ smime-type/compressed-data
+ smime-type/certs-only
+ name
+
+ Encoding Considerations: See Section 3 of this document
+
+ Security Considerations: See Section 6 of this document
+
+ Interoperability Considerations: See Sections 1-6 of this document
+
+ Published Specification: RFC 2311, RFC 2633, and this document
+
+ Applications that use this media type: Security applications
+
+ Additional information: NONE
+
+ Person & email to contact for further information:
+ S/MIME working group chairs smime-chairs tools ietf org
+
+ Intended usage: COMMON
+
+ Restrictions on usage: NONE
+
+ Author: Sean Turner
+
+ Change Controller: S/MIME working group delegated from the IESG
+
+5.2. Media Type for application/pkcs7-signature
+
+ Type name: application
+
+ Subtype Name: pkcs7-signature
+
+ Required Parameters: NONE
+
+ Optional Parameters: NONE
+
+ Encoding Considerations: See Section 3 of this document
+
+ Security Considerations: See Section 6 of this document
+
+ Interoperability Considerations: See Sections 1-6 of this document
+
+ Published Specification: RFC 2311, RFC 2633, and this document
+
+ Applications that use this media type: Security applications
+
+
+
+Ramsdell & Turner Standards Track [Page 35]
+
+RFC 5751 S/MIME 3.2 Message Specification January 2010
+
+
+ Additional information: NONE
+
+ Person & email to contact for further information:
+ S/MIME working group chairs smime-chairs tools ietf org
+
+ Intended usage: COMMON
+
+ Restrictions on usage: NONE
+
+ Author: Sean Turner
+
+ Change Controller: S/MIME working group delegated from the IESG
+
+6. Security Considerations
+
+ Cryptographic algorithms will be broken or weakened over time.
+ Implementers and users need to check that the cryptographic
+ algorithms listed in this document continue to provide the expected
+ level of security. The IETF from time to time may issue documents
+ dealing with the current state of the art. For example:
+
+ - The Million Message Attack described in RFC 3218 [MMA].
+
+ - The Diffie-Hellman "small-subgroup" attacks described in RFC
+ 2785 [DHSUB].
+
+ - The attacks against hash algorithms described in RFC 4270 [HASH-
+ ATTACK].
+
+ This specification uses Public-Key Cryptography technologies. It is
+ assumed that the private key is protected to ensure that it is not
+ accessed or altered by unauthorized parties.
+
+ It is impossible for most people or software to estimate the value of
+ a message's content. Further, it is impossible for most people or
+ software to estimate the actual cost of recovering an encrypted
+ message content that is encrypted with a key of a particular size.
+ Further, it is quite difficult to determine the cost of a failed
+ decryption if a recipient cannot process a message's content. Thus,
+ choosing between different key sizes (or choosing whether to just use
+ plaintext) is also impossible for most people or software. However,
+ decisions based on these criteria are made all the time, and
+ therefore this specification gives a framework for using those
+ estimates in choosing algorithms.
+
+ The choice of 2048 bits as the RSA asymmetric key size in this
+ specification is based on the desire to provide at least 100 bits of
+ security. The key sizes that must be supported to conform to this
+
+
+
+Ramsdell & Turner Standards Track [Page 36]
+
+RFC 5751 S/MIME 3.2 Message Specification January 2010
+
+
+ specification seem appropriate for the Internet based on [STRENGTH].
+ Of course, there are environments, such as financial and medical
+ systems, that may select different key sizes. For this reason, an
+ implementation MAY support key sizes beyond those recommended in this
+ specification.
+
+ Receiving agents that validate signatures and sending agents that
+ encrypt messages need to be cautious of cryptographic processing
+ usage when validating signatures and encrypting messages using keys
+ larger than those mandated in this specification. An attacker could
+ send certificates with keys that would result in excessive
+ cryptographic processing, for example, keys larger than those
+ mandated in this specification, which could swamp the processing
+ element. Agents that use such keys without first validating the
+ certificate to a trust anchor are advised to have some sort of
+ cryptographic resource management system to prevent such attacks.
+
+ Using weak cryptography in S/MIME offers little actual security over
+ sending plaintext. However, other features of S/MIME, such as the
+ specification of AES and the ability to announce stronger
+ cryptographic capabilities to parties with whom you communicate,
+ allow senders to create messages that use strong encryption. Using
+ weak cryptography is never recommended unless the only alternative is
+ no cryptography.
+
+ RSA and DSA keys of less than 1024 bits are now considered by many
+ experts to be cryptographically insecure (due to advances in
+ computing power), and should no longer be used to protect messages.
+ Such keys were previously considered secure, so processing previously
+ received signed and encrypted mail will often result in the use of
+ weak keys. Implementations that wish to support previous versions of
+ S/MIME or process old messages need to consider the security risks
+ that result from smaller key sizes (e.g., spoofed messages) versus
+ the costs of denial of service. If an implementation supports
+ verification of digital signatures generated with RSA and DSA keys of
+ less than 1024 bits, it MUST warn the user. Implementers should
+ consider providing different warnings for newly received messages and
+ previously stored messages. Server implementations (e.g., secure
+ mail list servers) where user warnings are not appropriate SHOULD
+ reject messages with weak signatures.
+
+ Implementers SHOULD be aware that multiple active key pairs can be
+ associated with a single individual. For example, one key pair can
+ be used to support confidentiality, while a different key pair can be
+ used for digital signatures.
+
+
+
+
+
+
+Ramsdell & Turner Standards Track [Page 37]
+
+RFC 5751 S/MIME 3.2 Message Specification January 2010
+
+
+ If a sending agent is sending the same message using different
+ strengths of cryptography, an attacker watching the communications
+ channel might be able to determine the contents of the strongly
+ encrypted message by decrypting the weakly encrypted version. In
+ other words, a sender SHOULD NOT send a copy of a message using
+ weaker cryptography than they would use for the original of the
+ message.
+
+ Modification of the ciphertext can go undetected if authentication is
+ not also used, which is the case when sending EnvelopedData without
+ wrapping it in SignedData or enclosing SignedData within it.
+
+ If an implementation is concerned about compliance with National
+ Institute of Standards and Technology (NIST) key size
+ recommendations, then see [SP800-57].
+
+ If messaging environments make use of the fact that a message is
+ signed to change the behavior of message processing (examples would
+ be running rules or UI display hints), without first verifying that
+ the message is actually signed and knowing the state of the
+ signature, this can lead to incorrect handling of the message.
+ Visual indicators on messages may need to have the signature
+ validation code checked periodically if the indicator is supposed to
+ give information on the current status of a message.
+
+7. References
+
+7.1. Reference Conventions
+
+ [CMS] refers to [RFC5652].
+
+ [ESS] refers to [RFC2634] and [RFC5035].
+
+ [MIME] refers to [RFC2045], [RFC2046], [RFC2047], [RFC2049],
+ [RFC4288], and [RFC4289].
+
+ [SMIMEv2] refers to [RFC2311], [RFC2312], [RFC2313], [RFC2314], and
+ [RFC2315].
+
+ [SMIMEv3] refers to [RFC2630], [RFC2631], [RFC2632], [RFC2633],
+ [RFC2634], and [RFC5035].
+
+ [SMIMv3.1] refers to [RFC2634], [RFC3850], [RFC3851], [RFC3852], and
+ [RFC5035].
+
+
+
+
+
+
+
+Ramsdell & Turner Standards Track [Page 38]
+
+RFC 5751 S/MIME 3.2 Message Specification January 2010
+
+
+7.2. Normative References
+
+ [CERT32] Ramsdell, B. and S. Turner, "Secure/Multipurpose
+ Internet Mail Extensions (S/MIME) Version 3.2
+ Certificate Handling", RFC 5750, January 2010.
+
+ [CHARSETS] Character sets assigned by IANA. See
+ http://www.iana.org/assignments/character-sets.
+
+ [CMSAES] Schaad, J., "Use of the Advanced Encryption Standard
+ (AES) Encryption Algorithm in Cryptographic Message
+ Syntax (CMS)", RFC 3565, July 2003.
+
+ [CMSALG] Housley, R., "Cryptographic Message Syntax (CMS)
+ Algorithms", RFC 3370, August 2002.
+
+ [CMSCOMPR] Gutmann, P., "Compressed Data Content Type for
+ Cryptographic Message Syntax (CMS)", RFC 3274, June
+ 2002.
+
+ [CMS-SHA2] Turner, S., "Using SHA2 Algorithms with Cryptographic
+ Message Syntax", RFC 5754, January 2010.
+
+ [CONTDISP] Troost, R., Dorner, S., and K. Moore, Ed.,
+ "Communicating Presentation Information in Internet
+ Messages: The Content-Disposition Header Field", RFC
+ 2183, August 1997.
+
+ [FIPS186-2] National Institute of Standards and Technology (NIST),
+ "Digital Signature Standard (DSS)", FIPS Publication
+ 186-2, January 2000. [With Change Notice 1].
+
+ [FIPS186-3] National Institute of Standards and Technology (NIST),
+ FIPS Publication 186-3: Digital Signature Standard,
+ June 2009.
+
+ [MIME-SECURE] Galvin, J., Murphy, S., Crocker, S., and N. Freed,
+ "Security Multiparts for MIME: Multipart/Signed and
+ Multipart/Encrypted", RFC 1847, October 1995.
+
+ [MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
+ "Randomness Requirements for Security", BCP 106, RFC
+ 4086, June 2005.
+
+
+
+
+
+Ramsdell & Turner Standards Track [Page 39]
+
+RFC 5751 S/MIME 3.2 Message Specification January 2010
+
+
+ [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet
+ Mail Extensions (MIME) Part One: Format of Internet
+ Message Bodies", RFC 2045, November 1996.
+
+ [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet
+ Mail Extensions (MIME) Part Two: Media Types", RFC
+ 2046, November 1996.
+
+ [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail
+ Extensions) Part Three: Message Header Extensions for
+ Non-ASCII Text", RFC 2047, November 1996.
+
+ [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet
+ Mail Extensions (MIME) Part Five: Conformance Criteria
+ and Examples", RFC 2049, November 1996.
+
+ [RFC2634] Hoffman, P. Ed., "Enhanced Security Services for
+ S/MIME", RFC 2634, June 1999.
+
+ [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications
+ and Registration Procedures", BCP 13, RFC 4288,
+ December 2005.
+
+ [RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail
+ Extensions (MIME) Part Four: Registration Procedures",
+ BCP 13, RFC 4289, December 2005.
+
+ [RFC5035] Schaad, J., "Enhanced Security Services (ESS) Update:
+ Adding CertID Algorithm Agility", RFC 5035, August
+ 2007.
+
+ [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
+ 5652, September 2009.
+
+ [RSAOAEP] Housley, R. "Use of the RSAES-OAEP Key Transport
+ Algorithm in the Cryptographic Message Syntax (CMS)",
+ RFC 3560, July 2003.
+
+ [RSAPSS] Schaad, J., "Use of the RSASSA-PSS Signature Algorithm
+ in Cryptographic Message Syntax (CMS)", RFC 4056, June
+ 2005.
+
+ [SP800-56A] National Institute of Standards and Technology (NIST),
+ Special Publication 800-56A: Recommendation Pair-Wise
+ Key Establishment Schemes Using Discrete Logarithm
+ Cryptography (Revised), March 2007.
+
+
+
+
+
+Ramsdell & Turner Standards Track [Page 40]
+
+RFC 5751 S/MIME 3.2 Message Specification January 2010
+
+
+ [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC
+ 8824-1:2002. Information Technology - Abstract Syntax
+ Notation One (ASN.1): Specification of basic notation.
+
+ [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC
+ 8825-1:2002. Information Technology - ASN.1 encoding
+ rules: Specification of Basic Encoding Rules (BER),
+ Canonical Encoding Rules (CER) and Distinguished
+ Encoding Rules (DER).
+
+7.3. Informative References
+
+ [DHSUB] Zuccherato, R., "Methods for Avoiding the "Small-
+ Subgroup" Attacks on the Diffie-Hellman Key Agreement
+ Method for S/MIME", RFC 2785, March 2000.
+
+ [HASH-ATTACK] Hoffman, P. and B. Schneier, "Attacks on Cryptographic
+ Hashes in Internet Protocols", RFC 4270, November 2005.
+
+ [MMA] Rescorla, E., "Preventing the Million Message Attack on
+ Cryptographic Message Syntax", RFC 3218, January 2002.
+
+ [PKCS-7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax
+ Version 1.5", RFC 2315, March 1998.
+
+ [RFC2311] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L.,
+ and L. Repka, "S/MIME Version 2 Message Specification",
+ RFC 2311, March 1998.
+
+ [RFC2312] Dusse, S., Hoffman, P., Ramsdell, B., and J.
+ Weinstein, "S/MIME Version 2 Certificate Handling", RFC
+ 2312, March 1998.
+
+ [RFC2313] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", RFC
+ 2313, March 1998.
+
+ [RFC2314] Kaliski, B., "PKCS #10: Certification Request Syntax
+ Version 1.5", RFC 2314, March 1998.
+
+ [RFC2315] Kaliski, B., "PKCS #7: Certification Message Syntax
+ Version 1.5", RFC 2315, March 1998.
+
+ [RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630,
+ June 1999.
+
+ [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method",
+ RFC 2631, June 1999.
+
+
+
+
+Ramsdell & Turner Standards Track [Page 41]
+
+RFC 5751 S/MIME 3.2 Message Specification January 2010
+
+
+ [RFC2632] Ramsdell, B., Ed., "S/MIME Version 3 Certificate
+ Handling", RFC 2632, June 1999.
+
+ [RFC2633] Ramsdell, B., Ed., "S/MIME Version 3 Message
+ Specification", RFC 2633, June 1999.
+
+ [RFC3850] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
+ Extensions (S/MIME) Version 3.1 Certificate Handling",
+ RFC 3850, July 2004.
+
+ [RFC3851] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
+ Extensions (S/MIME) Version 3.1 Message Specification",
+ RFC 3851, July 2004.
+
+ [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
+ 3852, July 2004.
+
+ [SP800-57] National Institute of Standards and Technology (NIST),
+ Special Publication 800-57: Recommendation for Key
+ Management, August 2005.
+
+ [STRENGTH] Orman, H., and P. Hoffman, "Determining Strengths For
+ Public Keys Used For Exchanging Symmetric Keys", BCP
+ 86, RFC 3766, April 2004.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ramsdell & Turner Standards Track [Page 42]
+
+RFC 5751 S/MIME 3.2 Message Specification January 2010
+
+
+Appendix A. ASN.1 Module
+
+ Note: The ASN.1 module contained herein is unchanged from RFC 3851
+ [SMIMEv3.1] with the exception of a change to the prefersBinaryInside
+ ASN.1 comment. This module uses the 1988 version of ASN.1.
+
+ SecureMimeMessageV3dot1
+
+ { iso(1) member-body(2) us(840) rsadsi(113549)
+ pkcs(1) pkcs-9(9) smime(16) modules(0) msg-v3dot1(21) }
+
+ DEFINITIONS IMPLICIT TAGS ::=
+
+ BEGIN
+
+ IMPORTS
+
+ -- Cryptographic Message Syntax [CMS]
+ SubjectKeyIdentifier, IssuerAndSerialNumber,
+ RecipientKeyIdentifier
+ FROM CryptographicMessageSyntax
+ { iso(1) member-body(2) us(840) rsadsi(113549)
+ pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2001(14) };
+
+ -- id-aa is the arc with all new authenticated and unauthenticated
+ -- attributes produced by the S/MIME Working Group
+
+ id-aa OBJECT IDENTIFIER ::= {iso(1) member-body(2) usa(840)
+ rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) attributes(2)}
+
+ -- S/MIME Capabilities provides a method of broadcasting the
+ -- symmetric capabilities understood. Algorithms SHOULD be ordered
+ -- by preference and grouped by type
+
+ smimeCapabilities OBJECT IDENTIFIER ::= {iso(1) member-body(2)
+ us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15}
+
+ SMIMECapability ::= SEQUENCE {
+ capabilityID OBJECT IDENTIFIER,
+ parameters ANY DEFINED BY capabilityID OPTIONAL }
+
+ SMIMECapabilities ::= SEQUENCE OF SMIMECapability
+
+ -- Encryption Key Preference provides a method of broadcasting the
+ -- preferred encryption certificate.
+
+ id-aa-encrypKeyPref OBJECT IDENTIFIER ::= {id-aa 11}
+
+
+
+
+Ramsdell & Turner Standards Track [Page 43]
+
+RFC 5751 S/MIME 3.2 Message Specification January 2010
+
+
+ SMIMEEncryptionKeyPreference ::= CHOICE {
+ issuerAndSerialNumber [0] IssuerAndSerialNumber,
+ receipentKeyId [1] RecipientKeyIdentifier,
+ subjectAltKeyIdentifier [2] SubjectKeyIdentifier
+ }
+
+ -- receipentKeyId is spelt incorrectly, but kept for historical
+ -- reasons.
+
+ id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
+ rsadsi(113549) pkcs(1) pkcs9(9) 16 }
+
+ id-cap OBJECT IDENTIFIER ::= { id-smime 11 }
+
+ -- The preferBinaryInside OID indicates an ability to receive
+ -- messages with binary encoding inside the CMS wrapper.
+ -- The preferBinaryInside attribute's value field is ABSENT.
+
+ id-cap-preferBinaryInside OBJECT IDENTIFIER ::= { id-cap 1 }
+
+ -- The following list OIDs to be used with S/MIME V3
+
+ -- Signature Algorithms Not Found in [CMSALG], [CMS-SHA2], [RSAPSS],
+ -- and [RSAOAEP]
+
+ --
+ -- md2WithRSAEncryption OBJECT IDENTIFIER ::=
+ -- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1)
+ -- 2}
+
+ --
+ -- Other Signed Attributes
+ --
+ -- signingTime OBJECT IDENTIFIER ::=
+ -- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
+ -- 5}
+ -- See [CMS] for a description of how to encode the attribute
+ -- value.
+
+ SMIMECapabilitiesParametersForRC2CBC ::= INTEGER
+ -- (RC2 Key Length (number of bits))
+
+ END
+
+
+
+
+
+
+
+
+Ramsdell & Turner Standards Track [Page 44]
+
+RFC 5751 S/MIME 3.2 Message Specification January 2010
+
+
+Appendix B. Moving S/MIME v2 Message Specification to Historic Status
+
+ The S/MIME v3 [SMIMEv3], v3.1 [SMIMEv3.1], and v3.2 (this document)
+ are backwards compatible with the S/MIME v2 Message Specification
+ [SMIMEv2], with the exception of the algorithms (dropped RC2/40
+ requirement and added DSA and RSASSA-PSS requirements). Therefore,
+ it is recommended that RFC 2311 [SMIMEv2] be moved to Historic
+ status.
+
+Appendix C. Acknowledgments
+
+ Many thanks go out to the other authors of the S/MIME version 2
+ Message Specification RFC: Steve Dusse, Paul Hoffman, Laurence
+ Lundblade, and Lisa Repka. Without v2, there wouldn't be a v3, v3.1,
+ or v3.2.
+
+ A number of the members of the S/MIME Working Group have also worked
+ very hard and contributed to this document. Any list of people is
+ doomed to omission, and for that I apologize. In alphabetical order,
+ the following people stand out in my mind because they made direct
+ contributions to this document:
+
+ Tony Capel, Piers Chivers, Dave Crocker, Bill Flanigan, Peter
+ Gutmann, Alfred Hoenes, Paul Hoffman, Russ Housley, William Ottaway,
+ John Pawling, and Jim Schaad.
+
+Authors' Addresses
+
+ Blake Ramsdell
+ Brute Squad Labs, Inc.
+
+ EMail: blaker gmail com
+
+
+ Sean Turner
+ IECA, Inc.
+ 3057 Nutley Street, Suite 106
+ Fairfax, VA 22031
+ USA
+
+ EMail: turners ieca com
+
+
+
+
+
+
+
+
+
+
+Ramsdell & Turner Standards Track [Page 45]
+
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]
![http://www.ietf.cnri.reston.va.us/images/ietflogo.gif"](http://www.ietf.cnri.reston.va.us/images/ietflogo.gif"){kind=link}
