Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification
draft-ietf-lamps-rfc5751-bis-08
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 8551.
|
|
|---|---|---|---|
| Authors | Jim Schaad, Blake C. Ramsdell , Sean Turner | ||
| Last updated | 2018-05-02 | ||
| Replaces | draft-schaad-rfc5751-bis | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Submitted to IESG for Publication | |
| Document shepherd | Russ Housley | ||
| Shepherd write-up | Show Last changed 2017-04-14 | ||
| IESG | IESG state | Became RFC 8551 (Proposed Standard) | |
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | Eric Rescorla | ||
| Send notices to | Russ Housley <housley@vigilsec.com> | ||
| IANA | IANA review state | Version Changed - Review Needed |
draft-ietf-lamps-rfc5751-bis-08
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 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. It is
RECOMMENDED that a distinction be made between the location of the
header.
When an S/MIME message is received, if the top-level protected MIME
entity has a Content-Type of message/rfc822, it can be assumed that
the intent was to provide header protection. This entity SHOULD be
presented as the top-level message, taking into account header
merging issues as previously discussed.
3.1.1. Canonicalization
Each MIME entity MUST be converted to a canonical form that is
uniquely and unambiguously representable in the environment where the
signature is created and the environment where the signature will be
verified. MIME entities MUST be canonicalized for enveloping and
compressing as well as signing.
The exact details of canonicalization depend on the actual media type
and subtype of an entity, and are not described here. Instead, the
standard for the particular media type SHOULD be consulted. For
example, canonicalization of type text/plain is different from
Schaad, et al. Expires November 3, 2018 [Page 21]
Internet-Draft S/MIME 4.0 Message Specification May 2018
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
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 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
Schaad, et al. Expires November 3, 2018 [Page 22]
Internet-Draft S/MIME 4.0 Message Specification May 2018
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 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
Schaad, et al. Expires November 3, 2018 [Page 23]
Internet-Draft S/MIME 4.0 Message Specification May 2018
need to be transfer encoded. Though not shown here, the end of each
line is <CR><LF>. The line ending of the MIME headers, the text, and
the transfer encoded parts, all MUST be <CR><LF>.
Note that this example is not of an S/MIME message.
Content-Type: multipart/mixed; boundary=bar
--bar
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
=A1Hola Michael!
How do you like the new S/MIME specification?
It's generally a good idea to encode lines that begin with
From=20because some mail transport agents will insert a greater-
than (>) sign, thus invalidating the signature.
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.
Schaad, et al. Expires November 3, 2018 [Page 24]
Internet-Draft S/MIME 4.0 Message Specification May 2018
Since CMS content types are binary data, in most cases base-64
transfer encoding is appropriate, in particular, when used with SMTP
transport. The transfer encoding used depends on the transport
through which the object is to be sent, and is not a characteristic
of the media type.
Note that this discussion refers to the transfer encoding of the CMS
object or "outside" MIME entity. It is completely distinct from, and
unrelated to, the transfer encoding of the MIME entity secured by the
CMS object, the "inside" object, which is described in Section 3.1.
Because there are several types of application/pkcs7-mime objects, a
sending agent SHOULD do as much as possible to help a receiving agent
know about the contents of the object without forcing the receiving
agent to decode the ASN.1 for the object. The Content-Type header
field of all application/pkcs7-mime objects SHOULD include the
optional "smime-type" parameter, as described in the following
sections.
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 [RFC2183] with the "filename" parameter.
If a sending agent emits the above parameters, the value of the
parameters SHOULD be a file name with the appropriate extension:
Media Type File
Extension
application/pkcs7-mime (SignedData, EnvelopedData, .p7m
AuthEnvelopedData)
application/pkcs7-mime (degenerate SignedData certificate .p7c
management message)
application/pkcs7-mime (CompressedData) .p7z
application/pkcs7-signature (SignedData) .p7s
In addition, the file name SHOULD be limited to eight characters
followed by a three-letter extension. The eight-character filename
base can be any distinct name; the use of the filename base "smime"
SHOULD be used to indicate that the MIME entity is associated with
S/MIME.
Including a file name serves two purposes. It facilitates easier use
of S/MIME objects as files on disk. It also can convey type
information across gateways. When a MIME entity of type
application/pkcs7-mime (for example) arrives at a gateway that has no
special knowledge of S/MIME, it will default the entity's media type
Schaad, et al. Expires November 3, 2018 [Page 25]
Internet-Draft S/MIME 4.0 Message Specification May 2018
to application/octet-stream and treat it as a generic attachment,
thus losing the type information. However, the suggested filename
for an attachment is often carried across a gateway. This often
allows the receiving systems to determine the appropriate application
to hand the attachment off to, in this case, a stand-alone S/MIME
processing application. Note that this mechanism is provided as a
convenience for implementations in certain environments. A proper
S/MIME implementation MUST use the media types and MUST NOT rely on
the file extensions.
3.2.2. The smime-type Parameter
The application/pkcs7-mime content type defines the optional "smime-
type" parameter. The intent of this parameter is to convey details
about the security applied (signed or enveloped) along with
information about the contained content. This specification defines
the following smime-types.
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.
Schaad, et al. Expires November 3, 2018 [Page 26]
Internet-Draft S/MIME 4.0 Message Specification May 2018
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 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
[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=
Schaad, et al. Expires November 3, 2018 [Page 27]
Internet-Draft S/MIME 4.0 Message Specification May 2018
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 is processed into a
CMS object of type AuthEnvelopedData. 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
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:
Schaad, et al. Expires November 3, 2018 [Page 28]
Internet-Draft S/MIME 4.0 Message Specification May 2018
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
Schaad, et al. Expires November 3, 2018 [Page 29]
Internet-Draft S/MIME 4.0 Message Specification May 2018
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:
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:
Schaad, et al. Expires November 3, 2018 [Page 30]
Internet-Draft S/MIME 4.0 Message Specification May 2018
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".
Schaad, et al. Expires November 3, 2018 [Page 31]
Internet-Draft S/MIME 4.0 Message Specification May 2018
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 algorithm profile or "unknown" if
not defined)
Schaad, et al. Expires November 3, 2018 [Page 32]
Internet-Draft S/MIME 4.0 Message Specification May 2018
(Historical note: some early implementations of S/MIME emitted and
expected "rsa-md5", "rsa-sha1", and "sha1" for the micalg parameter.)
Receiving agents SHOULD be able to recover gracefully from a micalg
parameter value that they do not recognize. Future names for this
parameter will be consistent with the IANA "Hash Function Textual
Names" registry.
3.5.3.3. Sample multipart/signed Message
Content-Type: multipart/signed;
micalg=sha-1;
boundary="----=_NextBoundry____Fri,_06_Sep_2002_00:25:21";
protocol="application/pkcs7-signature"
This is a multi-part message in MIME format.
------=_NextBoundry____Fri,_06_Sep_2002_00:25:21
This is some sample content.
------=_NextBoundry____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
MIIDdwYJKoZIhvcNAQcCoIIDaDCCA2QCAQExCTAHBgUrDgMCGjALBgkqhkiG9w0BBw
GgggLgMIIC3DCCApugAwIBAgICAMgwCQYHKoZIzjgEAzASMRAwDgYDVQQDEwdDYXJs
RFNTMB4XDTk5MDgxNzAxMTA0OVoXDTM5MTIzMTIzNTk1OVowEzERMA8GA1UEAxMIQW
xpY2VEU1MwggG2MIIBKwYHKoZIzjgEATCCAR4CgYEAgY3N7YPqCp45PsJIKKPkR5Pd
DteoDuxTxauECE//lOFzSH4M1vNESNH+n6+koYkv4dkwyDbeP5u/t0zcX2mK5HXQNw
yRCJWb3qde+fz0ny/dQ6iLVPE/sAcIR01diMPDtbPjVQh11Tl2EMR4vf+dsISXN/Lk
URu15AmWXPN+W9sCFQDiR6YaRWa4E8baj7g3IStii/eTzQKBgCY40BSJMqo5+z5t2U
tZakx2IzkEAjVc8ssaMMMeUF3dm1nizaoFPVjAe6I2uG4Hr32KQiWn9HXPSgheSz6Q
+G3qnMkhijt2FOnOLl2jB80jhbgvMAF8bUmJEYk2RL34yJVKU1a14vlz7BphNh8Rf8
K97dFQ/5h0wtGBSmA5ujY5A4GEAAKBgFzjuVp1FJYLqXrd4z+p7Kxe3L23ExE0phaJ
KBEj2TSGZ3V1ExI9Q1tv5VG/+onyohs+JH09B41bY8i7RaWgSuOF1s4GgD/oI34a8i
SrUxq4Jw0e7wi/ZhSAXGKsZfoVi/G7NNTSljf2YUeyxDKE8H5BQP1Gp2NOM/Kl4vTy
g+W4o4GBMH8wDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0jBBgwFo
AUcEQ+gi5vh95K03XjPSC8QyuT8R8wHQYDVR0OBBYEFL5sobPjwfftQ3CkzhMB4v3j
l/7NMB8GA1UdEQQYMBaBFEFsaWNlRFNTQGV4YW1wbGUuY29tMAkGByqGSM44BAMDMA
AwLQIUVQykGR9CK4lxIjONg2q1PWdrv0UCFQCfYVNSVAtcst3a53Yd4hBSW0NevTFj
MGECAQEwGDASMRAwDgYDVQQDEwdDYXJsRFNTAgIAyDAHBgUrDgMCGjAJBgcqhkjOOA
QDBC4wLAIUM/mGf6gkgp9Z0XtRdGimJeB/BxUCFGFFJqwYRt1WYcIOQoGiaowqGzVI
------=_NextBoundry____Fri,_06_Sep_2002_00:25:21--
The content that is digested (the first part of the multipart/signed)
consists of the bytes:
Schaad, et al. Expires November 3, 2018 [Page 33]
Internet-Draft S/MIME 4.0 Message Specification May 2018
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
Schaad, et al. Expires November 3, 2018 [Page 34]
Internet-Draft S/MIME 4.0 Message Specification May 2018
the user to choose. When signing first, the signatories are then
securely obscured by the enveloping. When enveloping first the
signatories are exposed, but it is possible to verify signatures
without removing the enveloping. This can be useful in an
environment where automatic signature verification is desired, as no
private key material is required to verify a signature.
There are security ramifications to choosing whether to sign first or
encrypt first. A recipient of a message that is encrypted and then
signed can validate that the encrypted block was unaltered, but
cannot determine any relationship between the signer and the
unencrypted contents of the message. A recipient of a message that
is signed then encrypted can assume that the signed message itself
has not been altered, but that a careful attacker could have changed
the unauthenticated portions of the encrypted message.
When using compression, keep the following guidelines in mind:
- Compression of binary encoded encrypted data is discouraged, since
it will not yield significant compression. Base64 encrypted data
could very well benefit, however.
- If a lossy compression algorithm is used with signing, you will
need to compress first, then sign.
3.8. Creating a Certificate Management Message
The certificate management message or MIME entity is used to
transport certificates and/or Certificate Revocation Lists, such as
in response to a registration request.
Step 1. The certificates and/or Certificate Revocation Lists are
made available to the CMS generating process that creates a
CMS object of type SignedData. The SignedData
encapContentInfo eContent field MUST be absent and
signerInfos field MUST be empty.
Step 2. The SignedData object is wrapped in a CMS ContentInfo
object.
Step 3. The ContentInfo object is enclosed in an
application/pkcs7-mime MIME entity.
The smime-type parameter for a certificate management message is
"certs-only". The file extension for this type of message is ".p7c".
Schaad, et al. Expires November 3, 2018 [Page 35]
Internet-Draft S/MIME 4.0 Message Specification May 2018
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 on the
Content-Disposition header field. These parameters that give the
file suffix are not listed below as part of the parameter section.
Media type 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
4. Certificate Processing
A receiving agent MUST provide some certificate retrieval mechanism
in order to gain access to certificates for recipients of digital
envelopes. This specification does not cover how S/MIME agents
handle certificates, only what they do after a certificate has been
validated or rejected. S/MIME certificate issues are covered in
[RFC5750].
At a minimum, for initial S/MIME deployment, a user agent could
automatically generate a message to an intended recipient requesting
that recipient's certificate in a signed return message. Receiving
and sending agents SHOULD also provide a mechanism to allow a user to
Schaad, et al. Expires November 3, 2018 [Page 36]
Internet-Draft S/MIME 4.0 Message Specification May 2018
"store and protect" certificates for correspondents in such a way so
as to guarantee their later retrieval.
4.1. Key Pair Generation
All generated key pairs MUST be generated from a good source of non-
deterministic random input [RFC4086] and the private key MUST be
protected in a secure fashion.
An S/MIME user agent MUST NOT generate asymmetric keys less than 2048
bits for use with an RSA signature algorithm.
For 2048-bit through 4096-bit RSA with SHA-256 see [RFC5754] and
[FIPS186-4]. The first reference provides the signature algorithm's
object identifier, and the second provides the signature algorithm's
definition.
For RSASSA-PSS with SHA-256, see [RFC4056]. For RSAES-OAEP, see
[RFC3560].
4.2. Signature Generation
The following are the requirements for an S/MIME agent generated RSA
and RSASSA-PSS signatures:
key size <= 2047 : SHOULD NOT (Note 1)
2048 <= key size <= 4096 : SHOULD (see Security Considerations)
4096 < key size : MAY (see Security Considerations)
Note 1: see Historical Mail Considerations in Section 6.
Note 2: see Security Considerations in Appendix B.
Key sizes for ECDSA and EdDSA are fixed by the curve.
4.3. Signature Verification
The following are the requirements for S/MIME receiving agents during
signature verification of RSA and RSASSA-PSS signatures:
key size <= 2047 : SHOULD NOT (Note 1)
2048 <= key size <= 4096 : MUST (Note 2)
4096 < key size : MAY (Note 2)
Note 1: see Historical Mail Considerations in Section 6.
Note 2: see Security Considerations in Appendix B.
Key sizes for ECDSA and EdDSA are fixed by the curve.
Schaad, et al. Expires November 3, 2018 [Page 37]
Internet-Draft S/MIME 4.0 Message Specification May 2018
4.4. Encryption
The following are the requirements for an S/MIME agent when
establishing keys for content encryption using the RSA, and RSA-OAEP
algorithms:
key size <= 2047 : SHOULD NOT (Note 1)
2048 <= key size <= 4096 : SHOULD (Note 2)
4096 < key size : MAY (Note 2)
Note 1: see Historical Mail Considerations in Section 6.
Note 2: see Security Considerations in Appendix B.
Key sizes for ECDH are fixed by the curve.
4.5. Decryption
The following are the requirements for an S/MIME agent when
establishing keys for content decryption using the RSA and RSAES-OAEP
algorithms:
key size <= 2047 : MAY (Note 1)
2048 <= key size <= 4096 : MUST (Note 2)
4096 < key size : MAY (Note 2)
Note 1: see Historical Mail Considerations in Section 6.
Note 2: see Security Considerations in Appendix B.
Key sizes for ECDH are fixed by the curve.
5. IANA Considerations
The following information updates the media type registration for
application/pkcs7-mime and application/pkcs7-signature to refer to
this document as opposed to RFC 2311.
Note that other documents can define additional MIME media types for
S/MIME.
5.1. Media Type for application/pkcs7-mime
Schaad, et al. Expires November 3, 2018 [Page 38]
Internet-Draft S/MIME 4.0 Message Specification May 2018
Type name: application
Subtype Name: pkcs7-mime
Required Parameters: NONE
Optional Parameters: smime-type/signed-data
smime-type/enveloped-data
smime-type/compressed-data
smime-type/certs-only
name
Encoding Considerations: See Section 3 of this document
Security Considerations: See Section 6 of this document
Interoperability Considerations: See Sections 1-6 of this document
Published Specification: RFC 2311, RFC 2633, and this document
Applications that use this media type: Security applications
Additional information: NONE
Person & email to contact for further information: iesg@ietf.org
Intended usage: COMMON
Restrictions on usage: NONE
Author: Sean Turner
Change Controller: S/MIME working group delegated from the IESG
5.2. Media Type for application/pkcs7-signature
Schaad, et al. Expires November 3, 2018 [Page 39]
Internet-Draft S/MIME 4.0 Message Specification May 2018
Type name: application
Subtype Name: pkcs7-signature
Required Parameters: NONE
Optional Parameters: NONE
Encoding Considerations: See Section 3 of this document
Security Considerations: See Section 6 of this document
Interoperability Considerations: See Sections 1-6 of this document
Published Specification: RFC 2311, RFC 2633, and this document
Applications that use this media type: Security applications
Additional information: NONE
Person & email to contact for further information: iesg@ietf.org
Intended usage: COMMON
Restrictions on usage: NONE
Author: Sean Turner
Change Controller: S/MIME working group delegated from the IESG
5.3. Register authEnveloped-data smime-type
IANA is required to register the following value in the "Parameter
Values for the smime-type Parameter" registry. The values to be
registered are:
smime-type value: authEnveloped-data
Reference: [[This Document, Section 3.2.2]]
6. Security Considerations
Cryptographic algorithms will be broken or weakened over time.
Implementers and users need to check that the cryptographic
algorithms listed in this document continue to provide the expected
level of security. The IETF from time to time may issue documents
dealing with the current state of the art. For example:
Schaad, et al. Expires November 3, 2018 [Page 40]
Internet-Draft S/MIME 4.0 Message Specification May 2018
- The Million Message Attack described in RFC 3218 [RFC3218].
- The Diffie-Hellman "small-subgroup" attacks described in RFC 2785
[RFC2785].
- The attacks against hash algorithms described in RFC 4270
[RFC4270].
This specification uses Public-Key Cryptography technologies. It is
assumed that the private key is protected to ensure that it is not
accessed or altered by unauthorized parties.
It is impossible for most people or software to estimate the value of
a message's content. Further, it is impossible for most people or
software to estimate the actual cost of recovering an encrypted
message content that is encrypted with a key of a particular size.
Further, it is quite difficult to determine the cost of a failed
decryption if a recipient cannot process a message's content. Thus,
choosing between different key sizes (or choosing whether to just use
plaintext) is also impossible for most people or software. However,
decisions based on these criteria are made all the time, and
therefore this specification gives a framework for using those
estimates in choosing algorithms.
The choice of 2048 bits as an RSA asymmetric key size in this
specification is based on the desire to provide at least 100 bits of
security. The key sizes that must be supported to conform to this
specification seem appropriate for the Internet based on [RFC3766].
Of course, there are environments, such as financial and medical
systems, that may select different key sizes. For this reason, an
implementation MAY support key sizes beyond those recommended in this
specification.
Receiving agents that validate signatures and sending agents that
encrypt messages need to be cautious of cryptographic processing
usage when validating signatures and encrypting messages using keys
larger than those mandated in this specification. An attacker could
send certificates with keys that would result in excessive
cryptographic processing, for example, keys larger than those
mandated in this specification, which could swamp the processing
element. Agents that use such keys without first validating the
certificate to a trust anchor are advised to have some sort of
cryptographic resource management system to prevent such attacks.
Some cryptographic algorithms such as RC2 offer little actual
security over sending plaintext. Other algorithms such as TripleDES,
provide security but are no longer considered to be state of the art.
S/MIME requires the use of current state of the art algorithms such
Schaad, et al. Expires November 3, 2018 [Page 41]
Internet-Draft S/MIME 4.0 Message Specification May 2018
as AES and provides the ability to announce starter cryptographic
capabilities to parties with whom you communicate. This allows the
sender to create messages which can use the strongest common
encryption algorithm. Using algorithms such as RC2 is never
recommended unless the only alternative is no cryptography.
RSA and DSA keys of less than 2048 bits are now considered by many
experts to be cryptographically insecure (due to advances in
computing power), and should no longer be used to protect messages.
Such keys were previously considered secure, so processing previously
received signed and encrypted mail will often result in the use of
weak keys. Implementations that wish to support previous versions of
S/MIME or process old messages need to consider the security risks
that result from smaller key sizes (e.g., spoofed messages) versus
the costs of denial of service. If an implementation supports
verification of digital signatures generated with RSA and DSA keys of
less than 1024 bits, it MUST warn the user. Implementers should
consider providing different warnings for newly received messages and
previously stored messages. Server implementations (e.g., secure
mail list servers) where user warnings are not appropriate SHOULD
reject messages with weak signatures.
Implementers SHOULD be aware that multiple active key pairs can be
associated with a single individual. For example, one key pair can
be used to support confidentiality, while a different key pair can be
used for digital signatures.
If a sending agent is sending the same message using different
strengths of cryptography, an attacker watching the communications
channel might be able to determine the contents of the strongly
encrypted message by decrypting the weakly encrypted version. In
other words, a sender SHOULD NOT send a copy of a message using
weaker cryptography than they would use for the original of the
message.
Modification of the ciphertext in EnvelopedData can go undetected if
authentication is not also used, which is the case when sending
EnvelopedData without wrapping it in SignedData or enclosing
SignedData within it. This is one of the reasons for moving from
EnvelopedData to AuthEnvelopedData as the authenticated encryption
algorithms provide the authentication without needing the SignedData
layer.
If an implementation is concerned about compliance with National
Institute of Standards and Technology (NIST) key size
recommendations, then see [SP800-57].
Schaad, et al. Expires November 3, 2018 [Page 42]
Internet-Draft S/MIME 4.0 Message Specification May 2018
If messaging environments make use of the fact that a message is
signed to change the behavior of message processing (examples would
be running rules or UI display hints), without first verifying that
the message is actually signed and knowing the state of the
signature, this can lead to incorrect handling of the message.
Visual indicators on messages may need to have the signature
validation code checked periodically if the indicator is supposed to
give information on the current status of a message.
Many people assume that the use of an authenticated encryption
algorithm is all that is needed to be in a situation where the sender
of the message will be authenticated. In almost all cases this is
not a correct statement. There are a number of preconditions that
need to hold for an authenticated encryption algorithm to provide
this service:
- The starting key must be bound to a single entity. The use of a
group key only would allow for the statement that a message was
sent by one of the entities that held the key but will not
identify a specific entity.
- The message must have exactly one sender and one recipient.
Having more than one recipient would allow for the second
recipient to create a message that the first recipient would
believe is from the sender by stripping them as a recipient from
the message.
- A direct path needs to exist from the starting key to the key used
as the content encryption key (CEK) which guarantees that no third
party could have seen the resulting CEK. This means that one
needs to be using an algorithm that is called a "Direct
Encryption" or a "Direct Key Agreement" algorithm in other
contexts. This means that the starting key is used directly as
the CEK key, or that the starting key is used to create a secret
which then is transformed into the CEK via a KDF step.
S/MIME implementations almost universally use ephemeral-static rather
than static-static key agreement and do not use a shared secret for
encryption, this means that the first precondition is not met. There
is a document [RFC6278] which defined how to use static-static key
agreement with CMS so that is readably doable. Currently, all S/MIME
key agreement methods derive a KEK and wrap a CEK. This violates the
third precondition above. New key agreement algorithms that directly
created the CEK without creating an intervening KEK would need to be
defined.
Even when all of the preconditions are met and origination of a
message is established by the use of an authenticated encryption
Schaad, et al. Expires November 3, 2018 [Page 43]
Internet-Draft S/MIME 4.0 Message Specification May 2018
algorithm, users need to be aware that there is no way to prove this
to a third party. This is because either of the parties can
successfully create the message (or just alter the content) based on
the fact that the CEK is going to be known to both parties. Thus the
origination is always built on a presumption that "I did not send
this message to myself."
All of the authenticated encryption algorithms in this document use
counter mode for the encryption portion of the algorithm. This means
that the length of the plain text will always be known as the cipher
text length and the plain text length are always the same. This
information can enable passive observers to infer information based
solely on the length of the message. Applications for which this is
a concern need to provide some type of padding so that the length of
the message does not provide this information.
When compression is used with encryption, it has the potential to add
an additional layer of security. However, care needs to be taken
when designing a protocol that relies on this not to create a
compression oracle. Compression oracle attacks require an adaptive
input to the process and attack the unknown content of a message
based on the length of the compressed output, this means that no
attack on the encryption key is necessarily required.
7. References
7.1. Normative References
[ASN.1] "Information Technology - Abstract Syntax Notation
(ASN.1)".
ASN.1 syntax consists of the following references [X.680],
[X.681], [X.682], and [X.683].
[CHARSETS]
"Character sets assigned by IANA.",
<http://www.iana.org/assignments/character-sets.>.
[CMS] "Cryptographic Message Syntax".
This is the set of documents dealing with the
cryptographic message syntax and refers to [RFC5652] and
[RFC5083].
[ESS] "Enhanced Security Services for S/MIME".
This is the set of documents dealing with enhanced
security services and refers to [RFC2634] and [RFC5035].
Schaad, et al. Expires November 3, 2018 [Page 44]
Internet-Draft S/MIME 4.0 Message Specification May 2018
[FIPS186-4]
National Institute of Standards and Technology (NIST),
"Digital Signature Standard (DSS)", Federal Information
Processing Standards Publication 186-4, July 2013.
[I-D.ietf-curdle-cms-ecdh-new-curves]
Housley, R., "Use of the Elliptic Curve Diffie-Hellman Key
Agreement Algorithm with X25519 and X448 in the
Cryptographic Message Syntax (CMS)", draft-ietf-curdle-
cms-ecdh-new-curves-10 (work in progress), August 2017.
[I-D.ietf-curdle-cms-eddsa-signatures]
Housley, R., "Use of EdDSA Signatures in the Cryptographic
Message Syntax (CMS)", draft-ietf-curdle-cms-eddsa-
signatures-08 (work in progress), October 2017.
[I-D.ietf-lamps-rfc5750-bis]
Schaad, J., Ramsdell, B., and S. Turner, "Secure/
Multipurpose Internet Mail Extensions (S/ MIME) Version
4.0 Certificate Handling", draft-ietf-lamps-rfc5750-bis-05
(work in progress), April 2018.
[MIME-SPEC]
"MIME Message Specifications".
This is the set of documents that define how to use MIME.
This set of documents is [RFC2045], [RFC2046], [RFC2047],
[RFC2049], [RFC6838], and [RFC4289].
[RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed,
"Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted", RFC 1847, DOI 10.17487/RFC1847,
October 1995, <https://www.rfc-editor.org/info/rfc1847>.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<https://www.rfc-editor.org/info/rfc2045>.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
DOI 10.17487/RFC2046, November 1996,
<https://www.rfc-editor.org/info/rfc2046>.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, DOI 10.17487/RFC2047, November 1996,
<https://www.rfc-editor.org/info/rfc2047>.
Schaad, et al. Expires November 3, 2018 [Page 45]
Internet-Draft S/MIME 4.0 Message Specification May 2018
[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Five: Conformance Criteria and
Examples", RFC 2049, DOI 10.17487/RFC2049, November 1996,
<https://www.rfc-editor.org/info/rfc2049>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2183] Troost, R., Dorner, S., and K. Moore, Ed., "Communicating
Presentation Information in Internet Messages: The
Content-Disposition Header Field", RFC 2183,
DOI 10.17487/RFC2183, August 1997,
<https://www.rfc-editor.org/info/rfc2183>.
[RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME",
RFC 2634, DOI 10.17487/RFC2634, June 1999,
<https://www.rfc-editor.org/info/rfc2634>.
[RFC3274] Gutmann, P., "Compressed Data Content Type for
Cryptographic Message Syntax (CMS)", RFC 3274,
DOI 10.17487/RFC3274, June 2002,
<https://www.rfc-editor.org/info/rfc3274>.
[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3370, DOI 10.17487/RFC3370, August 2002,
<https://www.rfc-editor.org/info/rfc3370>.
[RFC3560] Housley, R., "Use of the RSAES-OAEP Key Transport
Algorithm in Cryptographic Message Syntax (CMS)",
RFC 3560, DOI 10.17487/RFC3560, July 2003,
<https://www.rfc-editor.org/info/rfc3560>.
[RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES)
Encryption Algorithm in Cryptographic Message Syntax
(CMS)", RFC 3565, DOI 10.17487/RFC3565, July 2003,
<https://www.rfc-editor.org/info/rfc3565>.
[RFC4056] Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in
Cryptographic Message Syntax (CMS)", RFC 4056,
DOI 10.17487/RFC4056, June 2005,
<https://www.rfc-editor.org/info/rfc4056>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
Schaad, et al. Expires November 3, 2018 [Page 46]
Internet-Draft S/MIME 4.0 Message Specification May 2018
[RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail
Extensions (MIME) Part Four: Registration Procedures",
BCP 13, RFC 4289, DOI 10.17487/RFC4289, December 2005,
<https://www.rfc-editor.org/info/rfc4289>.
[RFC5035] Schaad, J., "Enhanced Security Services (ESS) Update:
Adding CertID Algorithm Agility", RFC 5035,
DOI 10.17487/RFC5035, August 2007,
<https://www.rfc-editor.org/info/rfc5035>.
[RFC5083] Housley, R., "Cryptographic Message Syntax (CMS)
Authenticated-Enveloped-Data Content Type", RFC 5083,
DOI 10.17487/RFC5083, November 2007,
<https://www.rfc-editor.org/info/rfc5083>.
[RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated
Encryption in the Cryptographic Message Syntax (CMS)",
RFC 5084, DOI 10.17487/RFC5084, November 2007,
<https://www.rfc-editor.org/info/rfc5084>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>.
[RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve
Cryptography (ECC) Algorithms in Cryptographic Message
Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January
2010, <https://www.rfc-editor.org/info/rfc5753>.
[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic
Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January
2010, <https://www.rfc-editor.org/info/rfc5754>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[SMIMEv4.0]
"S/MIME version 4.0".
This group of documents represents S/MIME version 4.0.
This set of documents are [RFC2634],
Schaad, et al. Expires November 3, 2018 [Page 47]
Internet-Draft S/MIME 4.0 Message Specification May 2018
[I-D.ietf-lamps-rfc5750-bis], [[This Document]],
[RFC5652], and [RFC5035].
[X.680] "Information Technology - Abstract Syntax Notation One
(ASN.1): Specification of basic notation. ITU-T
Recommendation X.680 (2002)", ITU-T X.680, ISO/
IEC 8824-1:2008, November 2008.
[X.681] "Information Technology - Abstract Syntax Notation One
(ASN.1): Information object specification", ITU-T X.681,
ISO/IEC 8824-2:2008, November 2008.
[X.682] "Information Technology - Abstract Syntax Notation One
(ASN.1): Constraint specification", ITU-T X.682, ISO/
IEC 8824-3:2008, November 2008.
[X.683] "Information Technology - Abstract Syntax Notation One
(ASN.1): Parameterization of ASN.1 specifications",
ITU-T X.683, ISO/IEC 8824-4:2008, November 2008.
[X.690] "Information Technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER).", ITU-T X.690, ISO/IEC 8825-1:2002, July 2002.
7.2. Informative References
[FIPS186-2]
National Institute of Standards and Technology (NIST),
"Digital Signature Standard (DSS) [With Change Notice 1]",
Federal Information Processing Standards
Publication 186-2, January 2000.
[RFC2268] Rivest, R., "A Description of the RC2(r) Encryption
Algorithm", RFC 2268, DOI 10.17487/RFC2268, March 1998,
<https://www.rfc-editor.org/info/rfc2268>.
[RFC2311] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and
L. Repka, "S/MIME Version 2 Message Specification",
RFC 2311, DOI 10.17487/RFC2311, March 1998,
<https://www.rfc-editor.org/info/rfc2311>.
[RFC2312] Dusse, S., Hoffman, P., Ramsdell, B., and J. Weinstein,
"S/MIME Version 2 Certificate Handling", RFC 2312,
DOI 10.17487/RFC2312, March 1998,
<https://www.rfc-editor.org/info/rfc2312>.
Schaad, et al. Expires November 3, 2018 [Page 48]
Internet-Draft S/MIME 4.0 Message Specification May 2018
[RFC2313] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5",
RFC 2313, DOI 10.17487/RFC2313, March 1998,
<https://www.rfc-editor.org/info/rfc2313>.
[RFC2314] Kaliski, B., "PKCS #10: Certification Request Syntax
Version 1.5", RFC 2314, DOI 10.17487/RFC2314, March 1998,
<https://www.rfc-editor.org/info/rfc2314>.
[RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax
Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998,
<https://www.rfc-editor.org/info/rfc2315>.
[RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630,
DOI 10.17487/RFC2630, June 1999,
<https://www.rfc-editor.org/info/rfc2630>.
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method",
RFC 2631, DOI 10.17487/RFC2631, June 1999,
<https://www.rfc-editor.org/info/rfc2631>.
[RFC2632] Ramsdell, B., Ed., "S/MIME Version 3 Certificate
Handling", RFC 2632, DOI 10.17487/RFC2632, June 1999,
<https://www.rfc-editor.org/info/rfc2632>.
[RFC2633] Ramsdell, B., Ed., "S/MIME Version 3 Message
Specification", RFC 2633, DOI 10.17487/RFC2633, June 1999,
<https://www.rfc-editor.org/info/rfc2633>.
[RFC2785] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup"
Attacks on the Diffie-Hellman Key Agreement Method for
S/MIME", RFC 2785, DOI 10.17487/RFC2785, March 2000,
<https://www.rfc-editor.org/info/rfc2785>.
[RFC3218] Rescorla, E., "Preventing the Million Message Attack on
Cryptographic Message Syntax", RFC 3218,
DOI 10.17487/RFC3218, January 2002,
<https://www.rfc-editor.org/info/rfc3218>.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys", BCP 86,
RFC 3766, DOI 10.17487/RFC3766, April 2004,
<https://www.rfc-editor.org/info/rfc3766>.
[RFC3850] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Certificate Handling",
RFC 3850, DOI 10.17487/RFC3850, July 2004,
<https://www.rfc-editor.org/info/rfc3850>.
Schaad, et al. Expires November 3, 2018 [Page 49]
Internet-Draft S/MIME 4.0 Message Specification May 2018
[RFC3851] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, DOI 10.17487/RFC3851, July 2004,
<https://www.rfc-editor.org/info/rfc3851>.
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",
RFC 3852, DOI 10.17487/RFC3852, July 2004,
<https://www.rfc-editor.org/info/rfc3852>.
[RFC4134] Hoffman, P., Ed., "Examples of S/MIME Messages", RFC 4134,
DOI 10.17487/RFC4134, July 2005,
<https://www.rfc-editor.org/info/rfc4134>.
[RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic
Hashes in Internet Protocols", RFC 4270,
DOI 10.17487/RFC4270, November 2005,
<https://www.rfc-editor.org/info/rfc4270>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>.
[RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Certificate
Handling", RFC 5750, DOI 10.17487/RFC5750, January 2010,
<https://www.rfc-editor.org/info/rfc5750>.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, DOI 10.17487/RFC5751, January
2010, <https://www.rfc-editor.org/info/rfc5751>.
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations
for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
RFC 6151, DOI 10.17487/RFC6151, March 2011,
<https://www.rfc-editor.org/info/rfc6151>.
[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
Considerations for the SHA-0 and SHA-1 Message-Digest
Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
<https://www.rfc-editor.org/info/rfc6194>.
[RFC6278] Herzog, J. and R. Khazan, "Use of Static-Static Elliptic
Curve Diffie-Hellman Key Agreement in Cryptographic
Message Syntax", RFC 6278, DOI 10.17487/RFC6278, June
2011, <https://www.rfc-editor.org/info/rfc6278>.
Schaad, et al. Expires November 3, 2018 [Page 50]
Internet-Draft S/MIME 4.0 Message Specification May 2018
[RFC7114] Leiba, B., "Creation of a Registry for smime-type
Parameter Values", RFC 7114, DOI 10.17487/RFC7114, January
2014, <https://www.rfc-editor.org/info/rfc7114>.
[RFC7905] Langley, A., Chang, W., Mavrogiannopoulos, N.,
Strombergson, J., and S. Josefsson, "ChaCha20-Poly1305
Cipher Suites for Transport Layer Security (TLS)",
RFC 7905, DOI 10.17487/RFC7905, June 2016,
<https://www.rfc-editor.org/info/rfc7905>.
[SMIMEv2] "S/MIME version v2".
This group of documents represents S/MIME version 2. This
set of documents are [RFC2311], [RFC2312], [RFC2313],
[RFC2314], and [RFC2315].
[SMIMEv3] "S/MIME version 3".
This group of documents represents S/MIME version 3. This
set of documents are [RFC2630], [RFC2631], [RFC2632],
[RFC2633], [RFC2634], and [RFC5035].
[SMIMEv3.1]
"S/MIME version 3.1".
This group of documents represents S/MIME version 3.1.
This set of documents are [RFC2634], [RFC3850], [RFC3851],
[RFC3852], and [RFC5035].
[SMIMEv3.2]
"S/MIME version 3.2".
This group of documents represents S/MIME version 3.2.
This set of documents are [RFC2634], [RFC5750], [RFC5751],
[RFC5652], and [RFC5035].
[SP800-56A]
National Institute of Standards and Technology (NIST),
"Special Publication 800-56A Revision 2: Recommendation
Pair-Wise Key Establishment Schemes Using Discrete
Logarithm Cryptography", May 2013.
[SP800-57]
National Institute of Standards and Technology (NIST),
"Special Publication 800-57: Recommendation for Key
Management", August 2005.
Schaad, et al. Expires November 3, 2018 [Page 51]
Internet-Draft S/MIME 4.0 Message Specification May 2018
[TripleDES]
Tuchman, W., "Hellman Presents No Shortcut Solutions to
DES"", IEEE Spectrum v. 16, n. 7, pp 40-41, July 1979.
Appendix A. ASN.1 Module
Note: The ASN.1 module contained herein is unchanged from RFC 3851
[SMIMEv3.1] with the exception of a change to the prefersBinaryInside
ASN.1 comment. This module uses the 1988 version of ASN.1.
SecureMimeMessageV3dot1
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) msg-v3dot1(21) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
-- Cryptographic Message Syntax [CMS]
SubjectKeyIdentifier, IssuerAndSerialNumber,
RecipientKeyIdentifier
FROM CryptographicMessageSyntax
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2001(14) };
-- id-aa is the arc with all new authenticated and unauthenticated
-- attributes produced by the S/MIME Working Group
id-aa OBJECT IDENTIFIER ::= {iso(1) member-body(2) usa(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) attributes(2)}
-- S/MIME Capabilities provides a method of broadcasting the
-- symmetric capabilities understood. Algorithms SHOULD be ordered
-- by preference and grouped by type
smimeCapabilities OBJECT IDENTIFIER ::= {iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15}
SMIMECapability ::= SEQUENCE {
capabilityID OBJECT IDENTIFIER,
parameters ANY DEFINED BY capabilityID OPTIONAL }
SMIMECapabilities ::= SEQUENCE OF SMIMECapability
-- Encryption Key Preference provides a method of broadcasting the
Schaad, et al. Expires November 3, 2018 [Page 52]
Internet-Draft S/MIME 4.0 Message Specification May 2018
-- preferred encryption certificate.
id-aa-encrypKeyPref OBJECT IDENTIFIER ::= {id-aa 11}
SMIMEEncryptionKeyPreference ::= CHOICE {
issuerAndSerialNumber [0] IssuerAndSerialNumber,
receipentKeyId [1] RecipientKeyIdentifier,
subjectAltKeyIdentifier [2] SubjectKeyIdentifier
}
-- receipentKeyId is spelt incorrectly, but kept for historical
-- reasons.
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs9(9) 16 }
id-cap OBJECT IDENTIFIER ::= { id-smime 11 }
-- The preferBinaryInside OID indicates an ability to receive
-- messages with binary encoding inside the CMS wrapper.
-- The preferBinaryInside attribute's value field is ABSENT.
id-cap-preferBinaryInside OBJECT IDENTIFIER ::= { id-cap 1 }
-- The following list OIDs to be used with S/MIME V3
-- Signature Algorithms Not Found in [RFC3370], [RFC5754], [RFC4056],
-- and [RFC3560]
--
-- md2WithRSAEncryption OBJECT IDENTIFIER ::=
-- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1)
-- 2}
--
-- Other Signed Attributes
--
-- signingTime OBJECT IDENTIFIER ::=
-- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
-- 5}
-- See [CMS] for a description of how to encode the attribute
-- value.
SMIMECapabilitiesParametersForRC2CBC ::= INTEGER
-- (RC2 Key Length (number of bits))
END
Schaad, et al. Expires November 3, 2018 [Page 53]
Internet-Draft S/MIME 4.0 Message Specification May 2018
Appendix B. Historic Mail Considerations
Over the course of updating the S/MIME specifications, the set of
recommended algorithms has been modified each time the document has
been updated. This means that if a user has historic emails and
their user agent has been updated to only support the current set of
recommended algorithms some of those old emails will no longer be
accessible. It is strongly suggested that user agents implement some
of the following algorithms for dealing with historic emails.
This appendix contains a number of references to documents that have
been obsoleted or replaced, this is intentional as frequently the
updated documents do not have the same information in them.
B.1. DigestAlgorithmIdentifier
The following algorithms have been called our for some level of
support by previous S/MIME specifications:
- SHA-1 was dropped in [SMIMEv4.0]. SHA-1 is no longer considered
to be secure as it is no longer collision-resistant. The IETF
statement on SHA-1 can be found in [RFC6194] but it is out-of-date
relative to the most recent advances.
- MD5 was dropped in [SMIMEv4.0]. MD5 is no longer considered to be
secure as it is no longer collision-resistant. Details can be
found in [RFC6151].
B.2. Signature Algorithms
There are a number of problems with validating signatures on
sufficiently historic messages. For this reason it is strongly
suggested that UAs treat these signatures differently from those on
current messages. These problems include:
- CAs are not required to keep certificates on a CRL beyond one
update after a certificate has expired. This means that unless
CRLs are cached as part of the message it is not always possible
to check if a certificate has been revoked. The same problems
exist with OCSP responses as they may be based on a CRL rather
than on the certificate database.
- RSA and DSA keys of less than 2048 bits are now considered by many
experts to be cryptographically insecure (due to advances in
computing power). Such keys were previously considered secure, so
processing of historic signed messages will often result in the
use of weak keys. Implementations that wish to support previous
versions of S/MIME or process old messages need to consider the
Schaad, et al. Expires November 3, 2018 [Page 54]
Internet-Draft S/MIME 4.0 Message Specification May 2018
security risks that result from smaller key sizes (e.g., spoofed
messages) versus the costs of denial of service.
[SMIMEv3.1] set the lower limit on suggested key sizes for
creating and validation at 1024 bits. Prior to that the lower
bound on key sizes was 512 bits.
- Hash functions used to validate signatures on historic messages
may longer be considered to be secure. (See below.) While there
are not currently any known practical pre-image or second pre-
image attacks against MD5 or SHA-1, the fact they are no longer
considered to be collision resistant the security levels of the
signatures are generally considered suspect. If a message is
known to be historic, that it it has been in the possession of the
client for some time, then it might still be considered to be
secure.
- The previous two issues apply to the certificates used to validate
the binding of the public key to the identity that signed the
message as well.
The following algorithms have been called out for some level of
support by previous S/MIME specifications:
- RSA with MD5 was dropped in [SMIMEv4.0]. MD5 is no longer
considered to be secure as it is no longer collision-resistant.
Details can be found in [RFC6151].
- RSA and DSA with SHA-1 were dropped in [SMIMEv4.0]. SHA-1 is no
longer considered to be secure as it is no longer collision-
resistant. The IETF statement on SHA-1 can be found in [RFC6194]
but it is out-of-date relative to the most recent advances.
- DSA with SHA-256 was dropped in [SMIMEv4.0]. DSA has been
replaced by elliptic curve versions.
As requirements for mandatory to implement has changed over time,
some issues have been created that can cause interoperability
problems:
- S/MIME v2 clients are only required to verify digital signatures
using the rsaEncryption algorithm with SHA-1 or MD5, and might not
implement id-dsa-with-sha1 or id-dsa at all.
- S/MIME v3 clients might only implement signing or signature
verification using id-dsa-with-sha1, and might also use id-dsa as
an AlgorithmIdentifier in this field.
Schaad, et al. Expires November 3, 2018 [Page 55]
Internet-Draft S/MIME 4.0 Message Specification May 2018
- Note that S/MIME v3.1 clients support verifying id-dsa-with-sha1
and rsaEncryption and might not implement sha256withRSAEncryption.
NOTE: Receiving clients SHOULD recognize id-dsa as equivalent to id-
dsa-with-sha1.
For 512-bit RSA with SHA-1 see [RFC3370] and [FIPS186-2] without
Change Notice 1, for 512-bit RSA with SHA-256 see [RFC5754] and
[FIPS186-2] without Change Notice 1, and for 1024-bit through
2048-bit RSA with SHA-256 see [RFC5754] and [FIPS186-2] with Change
Notice 1. The first reference provides the signature algorithm's
object identifier, and the second provides the signature algorithm's
definition.
For 512-bit DSA with SHA-1 see [RFC3370] and [FIPS186-2] without
Change Notice 1, for 512-bit DSA with SHA-256 see [RFC5754] and
[FIPS186-2] without Change Notice 1, for 1024-bit DSA with SHA-1 see
[RFC3370] and [FIPS186-2] with Change Notice 1, for 1024-bit and
above DSA with SHA-256 see [RFC5754] and [FIPS186-4]. The first
reference provides the signature algorithm's object identifier and
the second provides the signature algorithm's definition.
B.3. ContentEncryptionAlgorithmIdentifier
The following algorithms have been called out for some level of
support by previous S/MIME specifications:
- RC2/40 [RFC2268] was dropped in [SMIMEv3.2]. The algorithm is
known to be insecure and, if supported, should only be used to
decrypt existing email.
- DES EDE3 CBC [TripleDES], also known as "tripleDES" is dropped in
[SMIMEv4.0]. This algorithms is removed from the supported list
due to the fact that it has a 64-bit block size and the fact that
it offers less that 128-bits of security. This algorithm should
be supported only to decrypt existing email, it should not be used
to encrypt new emails.
B.4. KeyEncryptionAlgorithmIdentifier
The following algorithms have been called out for some level of
support by previous S/MIME specifications:
- DH ephemeral-static mode, as specified in [RFC3370] and
[SP800-57], was dropped in [SMIMEv4.0].
Schaad, et al. Expires November 3, 2018 [Page 56]
Internet-Draft S/MIME 4.0 Message Specification May 2018
- RSA key sizes have been increased over time. Decrypting old mail
with smaller key sizes is reasonable, however new mail should use
the updated key sizes.
For 1024-bit DH, see [RFC3370]. For 1024-bit and larger DH, see
[SP800-56A]; regardless, use the KDF, which is from X9.42, specified
in [RFC3370].
Appendix C. Moving S/MIME v2 Message Specification to Historic Status
The S/MIME v3 [SMIMEv3], v3.1 [SMIMEv3.1], and v3.2 [SMIMEv3.2] are
backwards compatible with the S/MIME v2 Message Specification
[SMIMEv2], with the exception of the algorithms (dropped RC2/40
requirement and added DSA and RSASSA-PSS requirements). Therefore,
it is recommended that RFC 2311 [SMIMEv2] be moved to Historic
status.
Appendix D. Acknowledgments
Many thanks go out to the other authors of the S/MIME version 2
Message Specification RFC: Steve Dusse, Paul Hoffman, Laurence
Lundblade, and Lisa Repka. Without v2, there wouldn't be a v3, v3.1,
v3.2 or v4.0.
Some of the examples in this document were stolen from [RFC4134].
Thanks go the the people who wrote and verified the examples in that
document.
A number of the members of the S/MIME Working Group have also worked
very hard and contributed to this document. Any list of people is
doomed to omission, and for that I apologize. In alphabetical order,
the following people stand out in my mind because they made direct
contributions to various versions of this document:
Tony Capel, Piers Chivers, Dave Crocker, Bill Flanigan, Peter
Gutmann, Alfred Hoenes, Paul Hoffman, Russ Housley, William Ottaway,
and John Pawling.
The version 4 update to the S/MIME documents was done under the
auspices of the LAMPS Working Group.
Authors' Addresses
Jim Schaad
August Cellars
Email: ietf@augustcellars.com
Schaad, et al. Expires November 3, 2018 [Page 57]
Internet-Draft S/MIME 4.0 Message Specification May 2018
Blake Ramsdell
Brute Squad Labs, Inc.
Email: blaker@gmail.com
Sean Turner
sn3rd
Email: sean@sn3rd.com
Schaad, et al. Expires November 3, 2018 [Page 58]