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" documents [ESS] provide
   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.

   Anyone reading this section is expected to understand MIME as
   described in [MIME-SPEC] and [RFC1847].

3.1.  Preparing the MIME Entity for Signing, Enveloping, or Compressing

   S/MIME is used to secure MIME entities.  A MIME message is composed
   of a MIME header and a MIME body.  A body can consist of a single
   MIME entity or a tree of MIME entities (rooted with a multipart).
   S/MIME can be used to secure either a single MIME entity or a tree of
   MIME entities.  These entities can be in locations other than the
   root.  S/MIME can be applied multiple times to different entities in
   a single message.  A MIME entity that is the whole message includes
   only the MIME message headers and MIME body and does not include the
   rfc822 header.  Note that S/MIME can also be used to secure MIME
   entities used in applications other than Internet mail.  For cases
   where protection of the rfc822 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 EnvelopedData,
   CompressedData, and AuthEnvelopedData content types is described in
   Sections 3.2 and 3.5.  Other documents define additional CMS content
   types; those documents should be consulted for processing those CMS
   content types.

   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 those
   documents for the exact procedures.  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
   messages 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 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 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.  Given
   the security difference between headers, it is RECOMMENDED that the
   receiving client provide a distinction between header fields,
   depending on where they are located.

   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.

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.

   As a rule, S/MIME implementations SHOULD use transfer encoding as
   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 is 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.

   In the case where S/MIME implementations can determine that all
   intended recipients are capable of handling inner (all but the
   outermost) binary MIME objects, implementations 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)
   unnecessarily expands the message size.  Implementations MAY
   determine that recipient implementations are capable of
   handling inner binary MIME entities by (1) interpreting the
   id-cap-preferBinaryInside SMIMECapabilities attribute, (2) prior
   agreement, or (3) 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 as
   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 already
   7-bit data need no transfer encoding.  Entities such as 8-bit text
   and binary data can be encoded with quoted-printable or base64
   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 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.

   [RFC1847] 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 encountered 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 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 an example 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--

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 base64
   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.

3.2.1.  The name and filename Parameters

   For 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 [RFC2183] with the "filename" parameter.
   If a sending agent emits the above parameters, the value of the
   parameters SHOULD be a filename with the appropriate extension:

                                                                File
   Media Type                                                Extension
   -------------------------------------------------------------------
   application/pkcs7-mime (SignedData, EnvelopedData,           .p7m
      AuthEnvelopedData)
   application/pkcs7-mime (degenerate SignedData certificate    .p7c
      management message)
   application/pkcs7-mime (CompressedData)                      .p7z
   application/pkcs7-signature (SignedData)                     .p7s

   In addition, the filename 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 filename 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 standalone 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.

       Name                   CMS Type              Inner Content
       ----------------------------------------------------------
       enveloped-data         EnvelopedData         id-data
       signed-data            SignedData            id-data
       certs-only             SignedData            id-data
       compressed-data        CompressedData        id-data
       authEnveloped-data     AuthEnvelopedData     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 three values for smime-type SHOULD be assigned: "signed-*",
       "authEnv-*", 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",
   "authEnveloped", or "enveloped" without having to tunnel into the CMS
   payload.

   A registry for additional smime-type parameter values has been
   defined in [RFC7114].

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.  The
   "enveloped-only" structure does not support authenticated symmetric
   algorithms.  Use the "authenticated enveloped" structure for these
   algorithms.  Thus, 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 are processed into a
            CMS object of type EnvelopedData.  In addition to encrypting
            a copy of the content-encryption key (CEK) for each
            recipient, a copy of the CEK SHOULD be encrypted for the
            originator and included in the EnvelopedData (see [RFC5652],
            Section 6).

   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; name=smime.p7m;
      smime-type=enveloped-data
   Content-Transfer-Encoding: base64
   Content-Disposition: attachment; filename=smime.p7m

   MIIBHgYJKoZIhvcNAQcDoIIBDzCCAQsCAQAxgcAwgb0CAQAwJjASMRAwDgYDVQQDEw
   dDYXJsUlNBAhBGNGvHgABWvBHTbi7NXXHQMA0GCSqGSIb3DQEBAQUABIGAC3EN5nGI
   iJi2lsGPcP2iJ97a4e8kbKQz36zg6Z2i0yx6zYC4mZ7mX7FBs3IWg+f6KgCLx3M1eC
   bWx8+MDFbbpXadCDgO8/nUkUNYeNxJtuzubGgzoyEd8Ch4H/dd9gdzTd+taTEgS0ip
   dSJuNnkVY4/M652jKKHRLFf02hosdR8wQwYJKoZIhvcNAQcBMBQGCCqGSIb3DQMHBA
   gtaMXpRwZRNYAgDsiSf8Z9P43LrY4OxUk660cu1lXeCSFOSOpOJ7FuVyU=

3.4.  Creating an Authenticated Enveloped-Only Message

   This section describes the format for enveloping a MIME entity
   without signing it.  Authenticated enveloped messages provide
   confidentiality and data integrity.  It is important to note that
   sending authenticated enveloped messages does not provide for proof
   of origination when using S/MIME.  It is possible for a third party
   to replace ciphertext in such a way that the processed message will
   still be valid, but the meaning can be altered.  However, this is
   substantially more difficult than it is for an enveloped-only
   message, as the algorithm does provide a level of authentication.
   Any recipient for whom the message is encrypted can replace it
   without detection.

   Step 1.  The MIME entity to be enveloped is prepared according to
            Section 3.1.

   Step 2.  The MIME entity and other required data are processed into a
            CMS object of type AuthEnvelopedData.  In addition to
            encrypting a copy of the CEK for each recipient, a copy of
            the CEK SHOULD be encrypted for the originator and included
            in the AuthEnvelopedData (see [RFC5083]).

   Step 3.  The AuthEnvelopedData 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 authenticated enveloped-only messages is
   "authEnveloped-data".  The file extension for this type of message
   is ".p7m".

   A sample message would be:

   Content-Type: application/pkcs7-mime; smime-type=authEnveloped-data;
      name=smime.p7m
   Content-Transfer-Encoding: base64
   Content-Disposition: attachment; filename=smime.p7m

   MIIDWQYLKoZIhvcNAQkQARegggNIMIIDRAIBADGBvjCBuwIBADAmMBIxEDAO
   BgNVBAMTB0NhcmxSU0ECEEY0a8eAAFa8EdNuLs1dcdAwCwYJKoZIhvcNAQEB
   BIGAgyZJo0ERTxA4xdTri5P5tVMyh0RARepTUCORZvlUbcUlaI8IpJZH3/J1
   Fv6MxTRS4O/K+ZcTlQmYeWLQvwdltQdOIP3mhpqXzTnOYhTK1IDtF2zx75Lg
   vE+ilpcLIzXfJB4RCBPtBWaHAof4Wb+VMQvLkk9OolX4mRSH1LPktgAwggJq
   BgkqhkiG9w0BBwEwGwYJYIZIAWUDBAEGMA4EDGPizioC9OHSsnNx4oCCAj7Y
   Cb8rOy8+55106newEJohC/aDgWbJhrMKzSOwa7JraXOV3HXD3NvKbl665dRx
   vmDwSCNaLCRU5q8/AxQx2SvnAbM+JKcEfC/VFdd4SiHNiUECAApLku2rMi5B
   WrhW/FXmx9d+cjum2BRwB3wj0q1wajdB0/kVRbQwg697dnlYyUog4vpJERjr
   7KAkawZx1RMHaM18wgZjUNpCBXFS3chQi9mTBp2i2Hf5iZ8OOtTx+rCQUmI6
   Jhy03vdcPCCARBjn3v0d3upZYDZddMA41CB9fKnnWFjadV1KpYwv80tqsEfx
   Vo0lJQ5VtJ8MHJiBpLVKadRIZ4iH2ULC0JtN5mXE1SrFKh7cqbJ4+7nqSRL3
   oBTud3rX41DGshOjpqcYHT4sqYlgZkc6dp0g1+hF1p3cGmjHdpysV2NVSUev
   ghHbvSqhIsXFzRSWKiZOigmlkv3R5LnjpYyP4brM62Jl7y0qborvV4dNMz7m
   D+5YxSlH0KAe8z6TT3LHuQdN7QCkFoiUSCaNhpAFaakkGIpqcqLhpOK4lXxt
   kptCG93eUwNCcTxtx6bXufPR5TUHohvZvfeqMp42kL37FJC/A8ZHoOxXy8+X
   X5QYxCQNuofWlvnIWv0Nr8w65x6lgVjPYmd/cHwzQKBTBMXN6pBud/PZL5zF
   tw3QHlQkBR+UflMWZKeN9L0KdQ27mQlCo5gQS85aifxoiiA2v9+0hxZw91rP
   IW4D+GS7oMMoKj8ZNyCJJsyf5smRZ+WxeBoolb3+TiGcBBCsRnfe6noLZiFO
   6Zeu2ZwE

3.5.  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.5.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.

   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.5.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 as follows:

   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

   MIIDmQYJKoZIhvcNAQcCoIIDijCCA4YCAQExCTAHBgUrDgMCGjAtBgkqhkiG9w0BBw
   GgIAQeDQpUaGlzIGlzIHNvbWUgc2FtcGxlIGNvbnRlbnQuoIIC4DCCAtwwggKboAMC
   AQICAgDIMAkGByqGSM44BAMwEjEQMA4GA1UEAxMHQ2FybERTUzAeFw05OTA4MTcwMT
   EwNDlaFw0zOTEyMzEyMzU5NTlaMBMxETAPBgNVBAMTCEFsaWNlRFNTMIIBtjCCASsG
   ByqGSM44BAEwggEeAoGBAIGNze2D6gqeOT7CSCij5EeT3Q7XqA7sU8WrhAhP/5Thc0
   h+DNbzREjR/p+vpKGJL+HZMMg23j+bv7dM3F9piuR10DcMkQiVm96nXvn89J8v3UOo
   i1TxP7AHCEdNXYjDw7Wz41UIddU5dhDEeL3/nbCElzfy5FEbteQJllzzflvbAhUA4k
   emGkVmuBPG2o+4NyErYov3k80CgYAmONAUiTKqOfs+bdlLWWpMdiM5BAI1XPLLGjDD
   HlBd3ZtZ4s2qBT1YwHuiNrhuB699ikIlp/R1z0oIXks+kPht6pzJIYo7dhTpzi5dow
   fNI4W4LzABfG1JiRGJNkS9+MiVSlNWteL5c+waYTYfEX/Cve3RUP+YdMLRgUpgObo2
   OQOBhAACgYBc47ladRSWC6l63eM/qeysXty9txMRNKYWiSgRI9k0hmd1dRMSPUNbb+
   VRv/qJ8qIbPiR9PQeNW2PIu0WloErjhdbOBoA/6CN+GvIkq1MauCcNHu8Iv2YUgFxi
   rGX6FYvxuzTU0pY39mFHssQyhPB+QUD9RqdjTjPypeL08oPluKOBgTB/MAwGA1UdEw
   EB/wQCMAAwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFHBEPoIub4feStN14z0g
   vEMrk/EfMB0GA1UdDgQWBBS+bKGz48H37UNwpM4TAeL945f+zTAfBgNVHREEGDAWgR
   RBbGljZURTU0BleGFtcGxlLmNvbTAJBgcqhkjOOAQDAzAAMC0CFFUMpBkfQiuJcSIz
   jYNqtT1na79FAhUAn2FTUlQLXLLd2ud2HeIQUltDXr0xYzBhAgEBMBgwEjEQMA4GA1
   UEAxMHQ2FybERTUwICAMgwBwYFKw4DAhowCQYHKoZIzjgEAwQuMCwCFD1cSW6LIUFz
   eXle3YI5SKSBer/sAhQmCq7s/CTFHOEjgASeUjbMpx5g6A==

3.5.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 [RFC1847].  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.

3.5.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.5.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 [RFC1847].
   The values to be placed in the micalg parameter SHOULD be from the
   following:

        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 the algorithm profile
                        or "unknown" if not defined)

   *Note: MD5 and SHA-1 are historical and no longer considered secure.
   See Appendix B for details.

   (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 values for this
   parameter will be taken from the IANA "Hash Function Textual Names"
   registry.

3.5.3.3.  Sample multipart/signed Message

   Content-Type: multipart/signed;
       micalg=sha-256;
       boundary="----=_NextBoundary____Fri,_06_Sep_2002_00:25:21";
       protocol="application/pkcs7-signature"

   This is a multipart message in MIME format.

   ------=_NextBoundary____Fri,_06_Sep_2002_00:25:21

   This is some sample content.
   ------=_NextBoundary____Fri,_06_Sep_2002_00:25:21
   Content-Type: application/pkcs7-signature; name=smime.p7s
   Content-Transfer-Encoding: base64
   Content-Disposition: attachment; filename=smime.p7s

   MIIBJgYJKoZIhvcNAQcCoIIBFzCCARMCAQExADALBgkqhkiG9w0BBwExgf4w
   gfsCAQIwJjASMRAwDgYDVQQDEwdDYXJsUlNBAhBGNGvHgABWvBHTbi7EELOw
   MAsGCWCGSAFlAwQCAaAxMC8GCSqGSIb3DQEJBDEiBCCxwpZGNZzTSsugsn+f
   lEidzQK4mf/ozKqfmbxhcIkKqjALBgkqhkiG9w0BAQsEgYB0XJV7fjPa5Nuh
   oth5msDfP8A5urYUMjhNpWgXG8ae3XpppqVrPi2nVO41onHnkByjkeD/wc31
   A9WH8MzFQgSTsrJ65JvffTTXkOpRPxsSHn3wJFwP/atWHkh8YK/jR9bULhUl
   Mv5jQEDiwVX5DRasxu6Ld8zv9u5/TsdBNiufGw==

   ------=_NextBoundary____Fri,_06_Sep_2002_00:25:21--

   The content that is digested (the first part of the multipart/signed)
   consists of the bytes:

   54 68 69 73 20 69 73 20 73 6f 6d 65 20 73 61 6d 70 6c 65 20 63 6f 6e
   74 65 6e 74 2e 0d 0a

3.6.  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 [RFC3274] 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

   eNoLycgsVgCi4vzcVIXixNyCnFSF5Py8ktS8Ej0AlCkKVA==

3.7.  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.

   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 related 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 and 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 encrypted data that is transferred as binary data
   is discouraged, since it will not yield significant compression.
   Encrypted data that is transferred as base64-encoded data could
   benefit as well.

   -  If a lossy compression algorithm is used with signing, you will
   need to compress first, then sign.

3.8.  Creating a Certificate Management Message

   The certificate management message or MIME entity is used to
   transport certificates and/or Certificate Revocation Lists (CRLs),
   such as in response to a registration request.

   Step 1.  The certificates and/or CRLs 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 the 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".

3.9.  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 v4.0 does not
   require a particular certificate request mechanism.

3.10.  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 in the
   Content-Disposition header field.  The MIME parameters that carry the
   file suffix are not listed below.

   Media Type                 Parameters                     File Suffix
   ---------------------------------------------------------------------
   application/pkcs7-mime     N/A                            N/A

   multipart/signed           protocol=                      N/A
                              "application/pkcs7-signature"

   application/octet-stream   N/A                            p7m, p7s,
                                                             p7c, p7z