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
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
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
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.
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
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.
[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--
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:
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.
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).
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.
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