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.8184.108.40.206.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. 220.127.116.11. 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".
18.104.22.168. 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.
22.214.171.124. 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