< draft-ietf-lamps-rfc5751-bis-03.txt   draft-ietf-lamps-rfc5751-bis-04.txt >
LAMPS J. Schaad LAMPS J. Schaad
Internet-Draft August Cellars Internet-Draft August Cellars
Obsoletes: RFC5751 (if approved) B. Ramsdell Obsoletes: RFC5751 (if approved) B. Ramsdell
Intended status: Standards Track Brute Squad Labs, Inc. Intended status: Standards Track Brute Squad Labs, Inc.
Expires: August 27, 2017 S. Turner Expires: September 14, 2017 S. Turner
sn3rd sn3rd
February 23, 2017 March 13, 2017
Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
Message Specification Message Specification
draft-ietf-lamps-rfc5751-bis-03 draft-ietf-lamps-rfc5751-bis-04
Abstract Abstract
This document defines Secure/Multipurpose Internet Mail Extensions This document defines Secure/Multipurpose Internet Mail Extensions
(S/MIME) version 4.0. S/MIME provides a consistent way to send and (S/MIME) version 4.0. S/MIME provides a consistent way to send and
receive secure MIME data. Digital signatures provide authentication, receive secure MIME data. Digital signatures provide authentication,
message integrity, and non-repudiation with proof of origin. message integrity, and non-repudiation with proof of origin.
Encryption provides data confidentiality. Compression can be used to Encryption provides data confidentiality. Compression can be used to
reduce data size. This document obsoletes RFC 5751. reduce data size. This document obsoletes RFC 5751.
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 27, 2017. This Internet-Draft will expire on September 14, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 42 skipping to change at page 2, line 42
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Specification Overview . . . . . . . . . . . . . . . . . 4 1.1. Specification Overview . . . . . . . . . . . . . . . . . 4
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Conventions Used in This Document . . . . . . . . . . . . 6 1.3. Conventions Used in This Document . . . . . . . . . . . . 6
1.4. Compatibility with Prior Practice of S/MIME . . . . . . . 7 1.4. Compatibility with Prior Practice of S/MIME . . . . . . . 7
1.5. Changes from S/MIME v3 to S/MIME v3.1 . . . . . . . . . . 7 1.5. Changes from S/MIME v3 to S/MIME v3.1 . . . . . . . . . . 7
1.6. Changes from S/MIME v3.1 to S/MIME v3.2 . . . . . . . . . 8 1.6. Changes from S/MIME v3.1 to S/MIME v3.2 . . . . . . . . . 8
1.7. Changes for S/MIME v4.0 . . . . . . . . . . . . . . . . . 9 1.7. Changes for S/MIME v4.0 . . . . . . . . . . . . . . . . . 9
2. CMS Options . . . . . . . . . . . . . . . . . . . . . . . . . 9 2. CMS Options . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1. DigestAlgorithmIdentifier . . . . . . . . . . . . . . . . 10 2.1. DigestAlgorithmIdentifier . . . . . . . . . . . . . . . . 10
2.2. SignatureAlgorithmIdentifier . . . . . . . . . . . . . . 10 2.2. SignatureAlgorithmIdentifier . . . . . . . . . . . . . . 10
2.3. KeyEncryptionAlgorithmIdentifier . . . . . . . . . . . . 11 2.3. KeyEncryptionAlgorithmIdentifier . . . . . . . . . . . . 11
2.4. General Syntax . . . . . . . . . . . . . . . . . . . . . 11 2.4. General Syntax . . . . . . . . . . . . . . . . . . . . . 12
2.4.1. Data Content Type . . . . . . . . . . . . . . . . . . 12 2.4.1. Data Content Type . . . . . . . . . . . . . . . . . . 12
2.4.2. SignedData Content Type . . . . . . . . . . . . . . . 12 2.4.2. SignedData Content Type . . . . . . . . . . . . . . . 12
2.4.3. EnvelopedData Content Type . . . . . . . . . . . . . 12 2.4.3. EnvelopedData Content Type . . . . . . . . . . . . . 12
2.4.4. AuthEnvelopedData Content Type . . . . . . . . . . . 12 2.4.4. AuthEnvelopedData Content Type . . . . . . . . . . . 12
2.4.5. CompressedData Content Type . . . . . . . . . . . . . 12 2.4.5. CompressedData Content Type . . . . . . . . . . . . . 12
2.5. Attributes and the SignerInfo Type . . . . . . . . . . . 13 2.5. Attributes and the SignerInfo Type . . . . . . . . . . . 13
2.5.1. Signing Time Attribute . . . . . . . . . . . . . . . 13 2.5.1. Signing Time Attribute . . . . . . . . . . . . . . . 13
2.5.2. SMIME Capabilities Attribute . . . . . . . . . . . . 14 2.5.2. SMIME Capabilities Attribute . . . . . . . . . . . . 14
2.5.3. Encryption Key Preference Attribute . . . . . . . . . 15 2.5.3. Encryption Key Preference Attribute . . . . . . . . . 15
2.6. SignerIdentifier SignerInfo Type . . . . . . . . . . . . 16 2.6. SignerIdentifier SignerInfo Type . . . . . . . . . . . . 17
2.7. ContentEncryptionAlgorithmIdentifier . . . . . . . . . . 17 2.7. ContentEncryptionAlgorithmIdentifier . . . . . . . . . . 17
2.7.1. Deciding Which Encryption Method to Use . . . . . . . 17 2.7.1. Deciding Which Encryption Method to Use . . . . . . . 17
2.7.2. Choosing Weak Encryption . . . . . . . . . . . . . . 19 2.7.2. Choosing Weak Encryption . . . . . . . . . . . . . . 19
2.7.3. Multiple Recipients . . . . . . . . . . . . . . . . . 19 2.7.3. Multiple Recipients . . . . . . . . . . . . . . . . . 19
3. Creating S/MIME Messages . . . . . . . . . . . . . . . . . . 19 3. Creating S/MIME Messages . . . . . . . . . . . . . . . . . . 19
3.1. Preparing the MIME Entity for Signing, Enveloping, or 3.1. Preparing the MIME Entity for Signing, Enveloping, or
Compressing . . . . . . . . . . . . . . . . . . . . . . . 20 Compressing . . . . . . . . . . . . . . . . . . . . . . . 20
3.1.1. Canonicalization . . . . . . . . . . . . . . . . . . 21 3.1.1. Canonicalization . . . . . . . . . . . . . . . . . . 21
3.1.2. Transfer Encoding . . . . . . . . . . . . . . . . . . 22 3.1.2. Transfer Encoding . . . . . . . . . . . . . . . . . . 22
3.1.3. Transfer Encoding for Signing Using multipart/signed 22 3.1.3. Transfer Encoding for Signing Using multipart/signed 22
skipping to change at page 3, line 42 skipping to change at page 3, line 42
3.10. Identifying an S/MIME Message . . . . . . . . . . . . . . 36 3.10. Identifying an S/MIME Message . . . . . . . . . . . . . . 36
4. Certificate Processing . . . . . . . . . . . . . . . . . . . 36 4. Certificate Processing . . . . . . . . . . . . . . . . . . . 36
4.1. Key Pair Generation . . . . . . . . . . . . . . . . . . . 37 4.1. Key Pair Generation . . . . . . . . . . . . . . . . . . . 37
4.2. Signature Generation . . . . . . . . . . . . . . . . . . 37 4.2. Signature Generation . . . . . . . . . . . . . . . . . . 37
4.3. Signature Verification . . . . . . . . . . . . . . . . . 37 4.3. Signature Verification . . . . . . . . . . . . . . . . . 37
4.4. Encryption . . . . . . . . . . . . . . . . . . . . . . . 38 4.4. Encryption . . . . . . . . . . . . . . . . . . . . . . . 38
4.5. Decryption . . . . . . . . . . . . . . . . . . . . . . . 38 4.5. Decryption . . . . . . . . . . . . . . . . . . . . . . . 38
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
5.1. Media Type for application/pkcs7-mime . . . . . . . . . . 38 5.1. Media Type for application/pkcs7-mime . . . . . . . . . . 38
5.2. Media Type for application/pkcs7-signature . . . . . . . 39 5.2. Media Type for application/pkcs7-signature . . . . . . . 39
5.3. Register authEnvelopedData smime-type . . . . . . . . . . 40 5.3. Register authEnveloped-data smime-type . . . . . . . . . 40
6. Security Considerations . . . . . . . . . . . . . . . . . . . 40 6. Security Considerations . . . . . . . . . . . . . . . . . . . 40
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
7.1. Normative References . . . . . . . . . . . . . . . . . . 44 7.1. Normative References . . . . . . . . . . . . . . . . . . 44
7.2. Informative References . . . . . . . . . . . . . . . . . 48 7.2. Informative References . . . . . . . . . . . . . . . . . 48
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 51 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 51
Appendix B. Historic Mail Considerations . . . . . . . . . . . . 53 Appendix B. Historic Mail Considerations . . . . . . . . . . . . 53
B.1. DigestAlgorithmIdentifier . . . . . . . . . . . . . . . . 54 B.1. DigestAlgorithmIdentifier . . . . . . . . . . . . . . . . 54
B.2. Signature Algorithms . . . . . . . . . . . . . . . . . . 54 B.2. Signature Algorithms . . . . . . . . . . . . . . . . . . 54
B.3. ContentEncryptionAlgorithmIdentifier . . . . . . . . . . 56 B.3. ContentEncryptionAlgorithmIdentifier . . . . . . . . . . 56
B.4. KeyEncryptionAlgorithmIdentifier . . . . . . . . . . . . 56 B.4. KeyEncryptionAlgorithmIdentifier . . . . . . . . . . . . 56
skipping to change at page 6, line 30 skipping to change at page 6, line 30
types, or both. types, or both.
Sending agent: Software that creates S/MIME CMS content types, Sending agent: Software that creates S/MIME CMS content types,
MIME body parts that contain CMS content types, or MIME body parts that contain CMS content types, or
both. both.
S/MIME agent: User software that is a receiving agent, a sending S/MIME agent: User software that is a receiving agent, a sending
agent, or both. agent, or both.
Data Integrity Service: A security service that protects againist Data Integrity Service: A security service that protects againist
unauthorized changes to data by insuring that unauthorized changes to data by ensuring that
changes to the data are detectable. [RFC4949] changes to the data are detectable. [RFC4949]
Data Confidentiality: The property that data is not discolsed to Data Confidentiality: The property that data is not discolsed to
system entities unless they have been authorize to system entities unless they have been authorized
know the data. [RFC4949] to know the data. [RFC4949]
Data Origination: The corroboration that the source of the data Data Origination: The corroboration that the source of the data
received is as claimed. [RFC4949]. received is as claimed. [RFC4949].
1.3. Conventions Used in This Document 1.3. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
We define some additional terms here: We define the additional requirement levels:
SHOULD+ This term means the same as SHOULD. However, the authors SHOULD+ This term means the same as SHOULD. However, the authors
expect that a requirement marked as SHOULD+ will be expect that a requirement marked as SHOULD+ will be
promoted at some future time to be a MUST. promoted at some future time to be a MUST.
SHOULD- This term means the same as SHOULD. However, the authors SHOULD- This term means the same as SHOULD. However, the authors
expect that a requirement marked as SHOULD- will be demoted expect that a requirement marked as SHOULD- will be demoted
to a MAY in a future version of this document. to a MAY in a future version of this document.
MUST- This term means the same as MUST. However, the authors MUST- This term means the same as MUST. However, the authors
expect that this requirement will no longer be a MUST in a expect that this requirement will no longer be a MUST in a
future document. Although its status will be determined at future document. Although its status will be determined at
a later time, it is reasonable to expect that if a future a later time, it is reasonable to expect that if a future
revision of a document alters the status of a MUST- revision of a document alters the status of a MUST-
requirement, it will remain at least a SHOULD or a SHOULD-. requirement, it will remain at least a SHOULD or a SHOULD-.
The term RSA in this document almost always refers to the PKCS#1 v1.5
RSA signature or encryption algorithms even when not qualified as
such. There are a couple of places where it refers to the general
RSA cryptographic operation, these can be determined from the context
where it is used.
1.4. Compatibility with Prior Practice of S/MIME 1.4. Compatibility with Prior Practice of S/MIME
S/MIME version 4.0 agents ought to attempt to have the greatest S/MIME version 4.0 agents ought to attempt to have the greatest
interoperability possible with agents for prior versions of S/MIME. interoperability possible with agents for prior versions of S/MIME.
S/MIME version 2 is described in RFC 2311 through RFC 2315 inclusive S/MIME version 2 is described in RFC 2311 through RFC 2315 inclusive
[SMIMEv2], S/MIME version 3 is described in RFC 2630 through RFC 2634 [SMIMEv2], S/MIME version 3 is described in RFC 2630 through RFC 2634
inclusive and RFC 5035 [SMIMEv3], S/MIME version 3.1 is described in inclusive and RFC 5035 [SMIMEv3], S/MIME version 3.1 is described in
RFC 3850, RFC 3851, RFC 3852, RFC 2634, and RFC 5035 [SMIMEv3.1], and RFC 3850, RFC 3851, RFC 3852, RFC 2634, and RFC 5035 [SMIMEv3.1], and
S/MIME version 3.2 is described in [SMIMEv3.2]. [RFC2311] also has S/MIME version 3.2 is described in [SMIMEv3.2]. [RFC2311] also has
historical information about the development of S/MIME. historical information about the development of S/MIME.
skipping to change at page 9, line 36 skipping to change at page 9, line 41
1.7. Changes for S/MIME v4.0 1.7. Changes for S/MIME v4.0
- Add the use of AuthEnvelopedData, including defining and - Add the use of AuthEnvelopedData, including defining and
registering an smime-type value (Section 2.4.4 and Section 3.4). registering an smime-type value (Section 2.4.4 and Section 3.4).
- Update the content encryption algorithms (Section 2.7 and - Update the content encryption algorithms (Section 2.7 and
Section 2.7.1.2): Add AES-256 GCM, add ChaCha200-Poly1305, remove Section 2.7.1.2): Add AES-256 GCM, add ChaCha200-Poly1305, remove
AES-192 CBC, mark tripleDES as historic. AES-192 CBC, mark tripleDES as historic.
- Update the set of signature algorithms (Section 2.2: Add EdDSA and - Update the set of signature algorithms (Section 2.2): Add EdDSA
ECDSA, mark DSA as historic and ECDSA, mark DSA as historic
- Update the set of digest algorithms (Section 2.1: Add SHA-512, - Update the set of digest algorithms (Section 2.1): Add SHA-512,
mark SHA-1 as historic. mark SHA-1 as historic.
- Update the size of keys to be used for RSA encryption and RSA - Update the size of keys to be used for RSA encryption and RSA
signing (Section 4). signing (Section 4).
- Create Appendix B which deals with considerations for dealing with - Create Appendix B which deals with considerations for dealing with
historic email messages. historic email messages.
2. CMS Options 2. CMS Options
skipping to change at page 14, line 16 skipping to change at page 14, line 21
19YY; if YY is less than 50, the year is interpreted as 20YY. 19YY; if YY is less than 50, the year is interpreted as 20YY.
Receiving agents MUST be able to process signing-time attributes that Receiving agents MUST be able to process signing-time attributes that
are encoded in either UTCTime or GeneralizedTime. are encoded in either UTCTime or GeneralizedTime.
2.5.2. SMIME Capabilities Attribute 2.5.2. SMIME Capabilities Attribute
The SMIMECapabilities attribute includes signature algorithms (such The SMIMECapabilities attribute includes signature algorithms (such
as "sha256WithRSAEncryption"), symmetric algorithms (such as "AES-128 as "sha256WithRSAEncryption"), symmetric algorithms (such as "AES-128
CBC"), authenticated symmetric algorithms (such as "AES-128 GCM") and CBC"), authenticated symmetric algorithms (such as "AES-128 GCM") and
key encipherment algorithms (such as "rsaEncryption"). There are key encipherment algorithms (such as "rsaEncryption"). The presence
also several identifiers that indicate support for other optional of an algorthm based SMIME Capability attribute in this sequence
features such as binary encoding and compression. The implies that the sender can deal with the algorithm as well as
undertanding the ASN.1 structures associated with that algorithm.
There are also several identifiers that indicate support for other
optional features such as binary encoding and compression. The
SMIMECapabilities were designed to be flexible and extensible so SMIMECapabilities were designed to be flexible and extensible so
that, in the future, a means of identifying other capabilities and that, in the future, a means of identifying other capabilities and
preferences such as certificates can be added in a way that will not preferences such as certificates can be added in a way that will not
cause current clients to break. cause current clients to break.
If present, the SMIMECapabilities attribute MUST be a If present, the SMIMECapabilities attribute MUST be a
SignedAttribute; it MUST NOT be an UnsignedAttribute. CMS defines SignedAttribute; it MUST NOT be an UnsignedAttribute. CMS defines
SignedAttributes as a SET OF Attribute. The SignedAttributes in a SignedAttributes as a SET OF Attribute. The SignedAttributes in a
signerInfo MUST NOT include multiple instances of the signerInfo MUST NOT include multiple instances of the
SMIMECapabilities attribute. CMS defines the ASN.1 syntax for SMIMECapabilities attribute. CMS defines the ASN.1 syntax for
skipping to change at page 26, line 15 skipping to change at page 26, line 15
the file extensions. the file extensions.
3.2.2. The smime-type Parameter 3.2.2. The smime-type Parameter
The application/pkcs7-mime content type defines the optional "smime- The application/pkcs7-mime content type defines the optional "smime-
type" parameter. The intent of this parameter is to convey details type" parameter. The intent of this parameter is to convey details
about the security applied (signed or enveloped) along with about the security applied (signed or enveloped) along with
information about the contained content. This specification defines information about the contained content. This specification defines
the following smime-types. the following smime-types.
Name CMS Type Inner Content Name CMS Type Inner Content
enveloped-data EnvelopedData id-data enveloped-data EnvelopedData id-data
signed-data SignedData id-data signed-data SignedData id-data
certs-only SignedData id-data certs-only SignedData id-data
compressed-data CompressedData id-data compressed-data CompressedData id-data
authEnvelopedData AuthEnvelopedData id-data authEnveloped-data AuthEnvelopedData id-data
In order for consistency to be obtained with future specifications, In order for consistency to be obtained with future specifications,
the following guidelines SHOULD be followed when assigning a new the following guidelines SHOULD be followed when assigning a new
smime-type parameter. smime-type parameter.
1. If both signing and encryption can be applied to the content, 1. If both signing and encryption can be applied to the content,
then three values for smime-type SHOULD be assigned "signed-*", then three values for smime-type SHOULD be assigned "signed-*",
"authEnv-*", and "enveloped-*". If one operation can be "authEnv-*", and "enveloped-*". If one operation can be
assigned, then this can be omitted. Thus, since "certs-only" can assigned, then this can be omitted. Thus, since "certs-only" can
only be signed, "signed-" is omitted. only be signed, "signed-" is omitted.
skipping to change at page 27, line 34 skipping to change at page 27, line 34
object. object.
Step 4. The ContentInfo object is inserted into an Step 4. The ContentInfo object is inserted into an
application/pkcs7-mime MIME entity. application/pkcs7-mime MIME entity.
The smime-type parameter for enveloped-only messages is "enveloped- The smime-type parameter for enveloped-only messages is "enveloped-
data". The file extension for this type of message is ".p7m". data". The file extension for this type of message is ".p7m".
A sample message would be: A sample message would be:
Content-Type: application/pkcs7-mime; name=smime.p7m; Content-Type: application/pkcs7-mime; name=smime.p7m;
smime-type=enveloped-data smime-type=enveloped-data
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m Content-Disposition: attachment; filename=smime.p7m
MIIBHgYJKoZIhvcNAQcDoIIBDzCCAQsCAQAxgcAwgb0CAQAwJjASMRAwDgYDVQQDEwdDYXJ MIIBHgYJKoZIhvcNAQcDoIIBDzCCAQsCAQAxgcAwgb0CAQAwJjASMRAwDgYDVQQDEw
sUlNBAhBGNGvHgABWvBHTbi7NXXHQMA0GCSqGSIb3DQEBAQUABIGAC3EN5nGIiJi2lsGPcP dDYXJsUlNBAhBGNGvHgABWvBHTbi7NXXHQMA0GCSqGSIb3DQEBAQUABIGAC3EN5nGI
2iJ97a4e8kbKQz36zg6Z2i0yx6zYC4mZ7mX7FBs3IWg+f6KgCLx3M1eCbWx8+MDFbbpXadC iJi2lsGPcP2iJ97a4e8kbKQz36zg6Z2i0yx6zYC4mZ7mX7FBs3IWg+f6KgCLx3M1eC
DgO8/nUkUNYeNxJtuzubGgzoyEd8Ch4H/dd9gdzTd+taTEgS0ipdSJuNnkVY4/M652jKKHR bWx8+MDFbbpXadCDgO8/nUkUNYeNxJtuzubGgzoyEd8Ch4H/dd9gdzTd+taTEgS0ip
LFf02hosdR8wQwYJKoZIhvcNAQcBMBQGCCqGSIb3DQMHBAgtaMXpRwZRNYAgDsiSf8Z9P43 dSJuNnkVY4/M652jKKHRLFf02hosdR8wQwYJKoZIhvcNAQcBMBQGCCqGSIb3DQMHBA
LrY4OxUk660cu1lXeCSFOSOpOJ7FuVyU= gtaMXpRwZRNYAgDsiSf8Z9P43LrY4OxUk660cu1lXeCSFOSOpOJ7FuVyU=
3.4. Creating an Authenticated Enveloped-Only Message 3.4. Creating an Authenticated Enveloped-Only Message
This section describes the format for enveloping a MIME entity This section describes the format for enveloping a MIME entity
without signing it. Authenticated enveloped messages provide without signing it. Authenticated enveloped messages provide
confidentiality and integrity. It is important to note that sending confidentiality and data integrity. It is important to note that
authenticated enveloped messages does not provide for authentication sending authenticated enveloped messages does not provide for
when using S/MIME. It is possible to replace ciphertext in such a authentication when using S/MIME. It is possible to replace
way that the processed message will still be valid, but the meaning ciphertext in such a way that the processed message will still be
can be altered. However this is substantially more difficult than it valid, but the meaning can be altered. However this is substantially
is for an enveloped-only message as the more difficult than it is for an enveloped-only message as the
Step 1. The MIME entity to be enveloped is prepared according to Step 1. The MIME entity to be enveloped is prepared according to
Section 3.1. Section 3.1.
Step 2. The MIME entity and other required data is processed into a Step 2. The MIME entity and other required data is processed into a
CMS object of type AuthEnvelopedData. In addition to CMS object of type AuthEnvelopedData. In addition to
encrypting a copy of the content-encryption key for each encrypting a copy of the content-encryption key for each
recipient, a copy of the content-encryption key SHOULD be recipient, a copy of the content-encryption key SHOULD be
encrypted for the originator and included in the encrypted for the originator and included in the
AuthEnvelopedData (see [RFC5083]). AuthEnvelopedData (see [RFC5083]).
Step 3. The AuthEnvelopedData object is wrapped in a CMS ContentInfo Step 3. The AuthEnvelopedData object is wrapped in a CMS ContentInfo
object. object.
Step 4. The ContentInfo object is inserted into an Step 4. The ContentInfo object is inserted into an
application/pkcs7-mime MIME entity. application/pkcs7-mime MIME entity.
The smime-type parameter for authenticated enveloped-only messages is The smime-type parameter for authenticated enveloped-only messages is
"authEnvelopedData". The file extension for this type of message is "authEnveloped-data". The file extension for this type of message is
".p7m". ".p7m".
A sample message would be: A sample message would be:
Content-Type: application/pkcs7-mime; smime-type=authEnvelopedData; Content-Type: application/pkcs7-mime; smime-type=authEnveloped-data;
name=smime.p7m name=smime.p7m
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m Content-Disposition: attachment; filename=smime.p7m
MIIDWQYLKoZIhvcNAQkQARegggNIMIIDRAIBADGBvjCBuwIBADAmMBIxEDAO MIIDWQYLKoZIhvcNAQkQARegggNIMIIDRAIBADGBvjCBuwIBADAmMBIxEDAO
BgNVBAMTB0NhcmxSU0ECEEY0a8eAAFa8EdNuLs1dcdAwCwYJKoZIhvcNAQEB BgNVBAMTB0NhcmxSU0ECEEY0a8eAAFa8EdNuLs1dcdAwCwYJKoZIhvcNAQEB
BIGAgyZJo0ERTxA4xdTri5P5tVMyh0RARepTUCORZvlUbcUlaI8IpJZH3/J1 BIGAgyZJo0ERTxA4xdTri5P5tVMyh0RARepTUCORZvlUbcUlaI8IpJZH3/J1
Fv6MxTRS4O/K+ZcTlQmYeWLQvwdltQdOIP3mhpqXzTnOYhTK1IDtF2zx75Lg Fv6MxTRS4O/K+ZcTlQmYeWLQvwdltQdOIP3mhpqXzTnOYhTK1IDtF2zx75Lg
vE+ilpcLIzXfJB4RCBPtBWaHAof4Wb+VMQvLkk9OolX4mRSH1LPktgAwggJq vE+ilpcLIzXfJB4RCBPtBWaHAof4Wb+VMQvLkk9OolX4mRSH1LPktgAwggJq
BgkqhkiG9w0BBwEwGwYJYIZIAWUDBAEGMA4EDGPizioC9OHSsnNx4oCCAj7Y BgkqhkiG9w0BBwEwGwYJYIZIAWUDBAEGMA4EDGPizioC9OHSsnNx4oCCAj7Y
skipping to change at page 31, line 5 skipping to change at page 31, line 5
Step 4. The ContentInfo object is inserted into an Step 4. The ContentInfo object is inserted into an
application/pkcs7-mime MIME entity. application/pkcs7-mime MIME entity.
The smime-type parameter for messages using application/pkcs7-mime The smime-type parameter for messages using application/pkcs7-mime
with SignedData is "signed-data". The file extension for this type with SignedData is "signed-data". The file extension for this type
of message is ".p7m". of message is ".p7m".
A sample message would be: A sample message would be:
Content-Type: application/pkcs7-mime; smime-type=signed-data; Content-Type: application/pkcs7-mime; smime-type=signed-data;
name=smime.p7m name=smime.p7m
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m Content-Disposition: attachment; filename=smime.p7m
MIIDmQYJKoZIhvcNAQcCoIIDijCCA4YCAQExCTAHBgUrDgMCGjAtBgkqhkiG9w0BBwGgIAQ MIIDmQYJKoZIhvcNAQcCoIIDijCCA4YCAQExCTAHBgUrDgMCGjAtBgkqhkiG9w0BBw
eDQpUaGlzIGlzIHNvbWUgc2FtcGxlIGNvbnRlbnQuoIIC4DCCAtwwggKboAMCAQICAgDIMA GgIAQeDQpUaGlzIGlzIHNvbWUgc2FtcGxlIGNvbnRlbnQuoIIC4DCCAtwwggKboAMC
kGByqGSM44BAMwEjEQMA4GA1UEAxMHQ2FybERTUzAeFw05OTA4MTcwMTEwNDlaFw0zOTEyM AQICAgDIMAkGByqGSM44BAMwEjEQMA4GA1UEAxMHQ2FybERTUzAeFw05OTA4MTcwMT
zEyMzU5NTlaMBMxETAPBgNVBAMTCEFsaWNlRFNTMIIBtjCCASsGByqGSM44BAEwggEeAoGB EwNDlaFw0zOTEyMzEyMzU5NTlaMBMxETAPBgNVBAMTCEFsaWNlRFNTMIIBtjCCASsG
AIGNze2D6gqeOT7CSCij5EeT3Q7XqA7sU8WrhAhP/5Thc0h+DNbzREjR/p+vpKGJL+HZMMg ByqGSM44BAEwggEeAoGBAIGNze2D6gqeOT7CSCij5EeT3Q7XqA7sU8WrhAhP/5Thc0
23j+bv7dM3F9piuR10DcMkQiVm96nXvn89J8v3UOoi1TxP7AHCEdNXYjDw7Wz41UIddU5dh h+DNbzREjR/p+vpKGJL+HZMMg23j+bv7dM3F9piuR10DcMkQiVm96nXvn89J8v3UOo
DEeL3/nbCElzfy5FEbteQJllzzflvbAhUA4kemGkVmuBPG2o+4NyErYov3k80CgYAmONAUi i1TxP7AHCEdNXYjDw7Wz41UIddU5dhDEeL3/nbCElzfy5FEbteQJllzzflvbAhUA4k
TKqOfs+bdlLWWpMdiM5BAI1XPLLGjDDHlBd3ZtZ4s2qBT1YwHuiNrhuB699ikIlp/R1z0oI emGkVmuBPG2o+4NyErYov3k80CgYAmONAUiTKqOfs+bdlLWWpMdiM5BAI1XPLLGjDD
Xks+kPht6pzJIYo7dhTpzi5dowfNI4W4LzABfG1JiRGJNkS9+MiVSlNWteL5c+waYTYfEX/ HlBd3ZtZ4s2qBT1YwHuiNrhuB699ikIlp/R1z0oIXks+kPht6pzJIYo7dhTpzi5dow
Cve3RUP+YdMLRgUpgObo2OQOBhAACgYBc47ladRSWC6l63eM/qeysXty9txMRNKYWiSgRI9 fNI4W4LzABfG1JiRGJNkS9+MiVSlNWteL5c+waYTYfEX/Cve3RUP+YdMLRgUpgObo2
k0hmd1dRMSPUNbb+VRv/qJ8qIbPiR9PQeNW2PIu0WloErjhdbOBoA/6CN+GvIkq1MauCcNH OQOBhAACgYBc47ladRSWC6l63eM/qeysXty9txMRNKYWiSgRI9k0hmd1dRMSPUNbb+
u8Iv2YUgFxirGX6FYvxuzTU0pY39mFHssQyhPB+QUD9RqdjTjPypeL08oPluKOBgTB/MAwG VRv/qJ8qIbPiR9PQeNW2PIu0WloErjhdbOBoA/6CN+GvIkq1MauCcNHu8Iv2YUgFxi
A1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFHBEPoIub4feStN14z0 rGX6FYvxuzTU0pY39mFHssQyhPB+QUD9RqdjTjPypeL08oPluKOBgTB/MAwGA1UdEw
gvEMrk/EfMB0GA1UdDgQWBBS+bKGz48H37UNwpM4TAeL945f+zTAfBgNVHREEGDAWgRRBbG EB/wQCMAAwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFHBEPoIub4feStN14z0g
ljZURTU0BleGFtcGxlLmNvbTAJBgcqhkjOOAQDAzAAMC0CFFUMpBkfQiuJcSIzjYNqtT1na vEMrk/EfMB0GA1UdDgQWBBS+bKGz48H37UNwpM4TAeL945f+zTAfBgNVHREEGDAWgR
79FAhUAn2FTUlQLXLLd2ud2HeIQUltDXr0xYzBhAgEBMBgwEjEQMA4GA1UEAxMHQ2FybERT RBbGljZURTU0BleGFtcGxlLmNvbTAJBgcqhkjOOAQDAzAAMC0CFFUMpBkfQiuJcSIz
UwICAMgwBwYFKw4DAhowCQYHKoZIzjgEAwQuMCwCFD1cSW6LIUFzeXle3YI5SKSBer/sAhQ jYNqtT1na79FAhUAn2FTUlQLXLLd2ud2HeIQUltDXr0xYzBhAgEBMBgwEjEQMA4GA1
mCq7s/CTFHOEjgASeUjbMpx5g6A== UEAxMHQ2FybERTUwICAMgwBwYFKw4DAhowCQYHKoZIzjgEAwQuMCwCFD1cSW6LIUFz
eXle3YI5SKSBer/sAhQmCq7s/CTFHOEjgASeUjbMpx5g6A==
3.5.3. Signing Using the multipart/signed Format 3.5.3. Signing Using the multipart/signed Format
This format is a clear-signing format. Recipients without any S/MIME This format is a clear-signing format. Recipients without any S/MIME
or CMS processing facilities are able to view the message. It makes or CMS processing facilities are able to view the message. It makes
use of the multipart/signed media type described in [RFC1847]. The use of the multipart/signed media type described in [RFC1847]. The
multipart/signed media type has two parts. The first part contains multipart/signed media type has two parts. The first part contains
the MIME entity that is signed; the second part contains the the MIME entity that is signed; the second part contains the
"detached signature" CMS SignedData object in which the "detached signature" CMS SignedData object in which the
encapContentInfo eContent field is absent. encapContentInfo eContent field is absent.
skipping to change at page 33, line 14 skipping to change at page 33, line 14
(Historical note: some early implementations of S/MIME emitted and (Historical note: some early implementations of S/MIME emitted and
expected "rsa-md5", "rsa-sha1", and "sha1" for the micalg parameter.) expected "rsa-md5", "rsa-sha1", and "sha1" for the micalg parameter.)
Receiving agents SHOULD be able to recover gracefully from a micalg Receiving agents SHOULD be able to recover gracefully from a micalg
parameter value that they do not recognize. Future names for this parameter value that they do not recognize. Future names for this
parameter will be consistent with the IANA "Hash Function Textual parameter will be consistent with the IANA "Hash Function Textual
Names" registry. Names" registry.
3.5.3.3. Sample multipart/signed Message 3.5.3.3. Sample multipart/signed Message
Content-Type: multipart/signed; Content-Type: multipart/signed;
micalg=SHA1; micalg=SHA1;
boundary="----=_NextBoundry____Fri,_06_Sep_2002_00:25:21"; boundary="----=_NextBoundry____Fri,_06_Sep_2002_00:25:21";
protocol="application/pkcs7-signature" protocol="application/pkcs7-signature"
This is a multi-part message in MIME format. This is a multi-part message in MIME format.
------=_NextBoundry____Fri,_06_Sep_2002_00:25:21 ------=_NextBoundry____Fri,_06_Sep_2002_00:25:21
This is some sample content. This is some sample content.
------=_NextBoundry____Fri,_06_Sep_2002_00:25:21 ------=_NextBoundry____Fri,_06_Sep_2002_00:25:21
Content-Type: application/pkcs7-signature; name=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s Content-Disposition: attachment; filename=smime.p7s
MIIDdwYJKoZIhvcNAQcCoIIDaDCCA2QCAQExCTAHBgUrDgMCGjALBgkqhkiG9w0BBwGgggL MIIDdwYJKoZIhvcNAQcCoIIDaDCCA2QCAQExCTAHBgUrDgMCGjALBgkqhkiG9w0BBw
gMIIC3DCCApugAwIBAgICAMgwCQYHKoZIzjgEAzASMRAwDgYDVQQDEwdDYXJsRFNTMB4XDT GgggLgMIIC3DCCApugAwIBAgICAMgwCQYHKoZIzjgEAzASMRAwDgYDVQQDEwdDYXJs
k5MDgxNzAxMTA0OVoXDTM5MTIzMTIzNTk1OVowEzERMA8GA1UEAxMIQWxpY2VEU1MwggG2M RFNTMB4XDTk5MDgxNzAxMTA0OVoXDTM5MTIzMTIzNTk1OVowEzERMA8GA1UEAxMIQW
IIBKwYHKoZIzjgEATCCAR4CgYEAgY3N7YPqCp45PsJIKKPkR5PdDteoDuxTxauECE//lOFz xpY2VEU1MwggG2MIIBKwYHKoZIzjgEATCCAR4CgYEAgY3N7YPqCp45PsJIKKPkR5Pd
SH4M1vNESNH+n6+koYkv4dkwyDbeP5u/t0zcX2mK5HXQNwyRCJWb3qde+fz0ny/dQ6iLVPE DteoDuxTxauECE//lOFzSH4M1vNESNH+n6+koYkv4dkwyDbeP5u/t0zcX2mK5HXQNw
/sAcIR01diMPDtbPjVQh11Tl2EMR4vf+dsISXN/LkURu15AmWXPN+W9sCFQDiR6YaRWa4E8 yRCJWb3qde+fz0ny/dQ6iLVPE/sAcIR01diMPDtbPjVQh11Tl2EMR4vf+dsISXN/Lk
baj7g3IStii/eTzQKBgCY40BSJMqo5+z5t2UtZakx2IzkEAjVc8ssaMMMeUF3dm1nizaoFP URu15AmWXPN+W9sCFQDiR6YaRWa4E8baj7g3IStii/eTzQKBgCY40BSJMqo5+z5t2U
VjAe6I2uG4Hr32KQiWn9HXPSgheSz6Q+G3qnMkhijt2FOnOLl2jB80jhbgvMAF8bUmJEYk2 tZakx2IzkEAjVc8ssaMMMeUF3dm1nizaoFPVjAe6I2uG4Hr32KQiWn9HXPSgheSz6Q
RL34yJVKU1a14vlz7BphNh8Rf8K97dFQ/5h0wtGBSmA5ujY5A4GEAAKBgFzjuVp1FJYLqXr +G3qnMkhijt2FOnOLl2jB80jhbgvMAF8bUmJEYk2RL34yJVKU1a14vlz7BphNh8Rf8
d4z+p7Kxe3L23ExE0phaJKBEj2TSGZ3V1ExI9Q1tv5VG/+onyohs+JH09B41bY8i7RaWgSu K97dFQ/5h0wtGBSmA5ujY5A4GEAAKBgFzjuVp1FJYLqXrd4z+p7Kxe3L23ExE0phaJ
OF1s4GgD/oI34a8iSrUxq4Jw0e7wi/ZhSAXGKsZfoVi/G7NNTSljf2YUeyxDKE8H5BQP1Gp KBEj2TSGZ3V1ExI9Q1tv5VG/+onyohs+JH09B41bY8i7RaWgSuOF1s4GgD/oI34a8i
2NOM/Kl4vTyg+W4o4GBMH8wDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0j SrUxq4Jw0e7wi/ZhSAXGKsZfoVi/G7NNTSljf2YUeyxDKE8H5BQP1Gp2NOM/Kl4vTy
BBgwFoAUcEQ+gi5vh95K03XjPSC8QyuT8R8wHQYDVR0OBBYEFL5sobPjwfftQ3CkzhMB4v3 g+W4o4GBMH8wDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0jBBgwFo
jl/7NMB8GA1UdEQQYMBaBFEFsaWNlRFNTQGV4YW1wbGUuY29tMAkGByqGSM44BAMDMAAwLQ AUcEQ+gi5vh95K03XjPSC8QyuT8R8wHQYDVR0OBBYEFL5sobPjwfftQ3CkzhMB4v3j
IUVQykGR9CK4lxIjONg2q1PWdrv0UCFQCfYVNSVAtcst3a53Yd4hBSW0NevTFjMGECAQEwG l/7NMB8GA1UdEQQYMBaBFEFsaWNlRFNTQGV4YW1wbGUuY29tMAkGByqGSM44BAMDMA
DASMRAwDgYDVQQDEwdDYXJsRFNTAgIAyDAHBgUrDgMCGjAJBgcqhkjOOAQDBC4wLAIUM/mG AwLQIUVQykGR9CK4lxIjONg2q1PWdrv0UCFQCfYVNSVAtcst3a53Yd4hBSW0NevTFj
f6gkgp9Z0XtRdGimJeB/BxUCFGFFJqwYRt1WYcIOQoGiaowqGzVI MGECAQEwGDASMRAwDgYDVQQDEwdDYXJsRFNTAgIAyDAHBgUrDgMCGjAJBgcqhkjOOA
QDBC4wLAIUM/mGf6gkgp9Z0XtRdGimJeB/BxUCFGFFJqwYRt1WYcIOQoGiaowqGzVI
------=_NextBoundry____Fri,_06_Sep_2002_00:25:21-- ------=_NextBoundry____Fri,_06_Sep_2002_00:25:21--
The content that is digested (the first part of the multipart/signed) The content that is digested (the first part of the multipart/signed)
consists of the bytes: consists of the bytes:
54 68 69 73 20 69 73 20 73 6f 6d 65 20 73 61 6d 70 6c 65 20 63 6f 6e 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 74 65 6e 74 2e 0d 0a
3.6. Creating a Compressed-Only Message 3.6. Creating a Compressed-Only Message
This section describes the format for compressing a MIME entity. This section describes the format for compressing a MIME entity.
skipping to change at page 36, line 33 skipping to change at page 36, line 33
type information, and it becomes a bit difficult to identify S/MIME type information, and it becomes a bit difficult to identify S/MIME
messages. The following table lists criteria for determining whether messages. The following table lists criteria for determining whether
or not a message is an S/MIME message. A message is considered an 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. 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 file suffix in the table below comes from the "name" parameter in
the Content-Type header field, or the "filename" parameter on the the Content-Type header field, or the "filename" parameter on the
Content-Disposition header field. These parameters that give the Content-Disposition header field. These parameters that give the
file suffix are not listed below as part of the parameter section. file suffix are not listed below as part of the parameter section.
Media type parameters file Media type parameters file suffix
suffix application/pkcs7-mime n/a n/a
application/pkcs7-mime n/a n/a multipart/signed protocol= n/a
multipart/signed protocol="application/pkcs7-signature" n/a "application/pkcs7-signature"
application/octet- n/a p7m, application/octet-stream n/a p7m, p7s,
stream p7s, p7c, p7z
p7c,
p7z
4. Certificate Processing 4. Certificate Processing
A receiving agent MUST provide some certificate retrieval mechanism A receiving agent MUST provide some certificate retrieval mechanism
in order to gain access to certificates for recipients of digital in order to gain access to certificates for recipients of digital
envelopes. This specification does not cover how S/MIME agents envelopes. This specification does not cover how S/MIME agents
handle certificates, only what they do after a certificate has been handle certificates, only what they do after a certificate has been
validated or rejected. S/MIME certificate issues are covered in validated or rejected. S/MIME certificate issues are covered in
[RFC5750]. [RFC5750].
skipping to change at page 37, line 16 skipping to change at page 37, line 14
"store and protect" certificates for correspondents in such a way so "store and protect" certificates for correspondents in such a way so
as to guarantee their later retrieval. as to guarantee their later retrieval.
4.1. Key Pair Generation 4.1. Key Pair Generation
All generated key pairs MUST be generated from a good source of non- All generated key pairs MUST be generated from a good source of non-
deterministic random input [RFC4086] and the private key MUST be deterministic random input [RFC4086] and the private key MUST be
protected in a secure fashion. protected in a secure fashion.
An S/MIME user agent MUST NOT generate asymmetric keys less than 2048 An S/MIME user agent MUST NOT generate asymmetric keys less than 2048
bits for use with the RSA signature algorithm. bits for use with an RSA signature algorithm.
For 2048-bit through 4096-bit RSA with SHA-256 see [RFC5754] and For 2048-bit through 4096-bit RSA with SHA-256 see [RFC5754] and
[FIPS186-4]. The first reference provides the signature algorithm's [FIPS186-4]. The first reference provides the signature algorithm's
object identifier, and the second provides the signature algorithm's object identifier, and the second provides the signature algorithm's
definition. definition.
For RSASSA-PSS with SHA-256, see [RFC4056]. For RSAES-OAEP, see For RSASSA-PSS with SHA-256, see [RFC4056]. For RSAES-OAEP, see
[RFC3560]. [RFC3560].
4.2. Signature Generation 4.2. Signature Generation
The following are the requirements for an S/MIME agent generated RSA The following are the requirements for an S/MIME agent generated RSA
and RSASSA-PSS signatures: and RSASSA-PSS signatures:
key size <= 2047 : SHOULD NOT (see Historic Mail Considerations) key size <= 2047 : SHOULD NOT (Note 1)
2048 <= key size <= 4096 : SHOULD (see Security Considerations) 2048 <= key size <= 4096 : SHOULD (see Security Considerations)
4096 < key size : MAY (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. Key sizes for ECDSA and EdDSA are fixed by the curve.
4.3. Signature Verification 4.3. Signature Verification
The following are the requirements for S/MIME receiving agents during The following are the requirements for S/MIME receiving agents during
signature verification of RSA and RSASSA-PSS signatures: signature verification of RSA and RSASSA-PSS signatures:
key size <= 2047 : SHOULD NOT (see Historic Mail Considerations) key size <= 2047 : SHOULD NOT (Note 1)
2048 <= key size <= 4096 : MUST (see Security Considerations) 2048 <= key size <= 4096 : MUST (Note 2)
4096 < key size : MAY (see Security Considerations) 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. Key sizes for ECDSA and EdDSA are fixed by the curve.
4.4. Encryption 4.4. Encryption
The following are the requirements for an S/MIME agent when The following are the requirements for an S/MIME agent when
establishing keys for content encryption using the RSA, and RSA-OAEP establishing keys for content encryption using the RSA, and RSA-OAEP
algorithms: algorithms:
key size <= 2047 : SHOULD NOT (see Historic Mail Considerations) key size <= 2047 : SHOULD NOT (Note 1)
2048 <= key size <= 4096 : SHOULD (see Security Considerations) 2048 <= key size <= 4096 : SHOULD (Note 2)
4096 < key size : MAY (see Security Considerations) 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. Key sizes for ECDH are fixed by the curve.
4.5. Decryption 4.5. Decryption
The following are the requirements for an S/MIME agent when The following are the requirements for an S/MIME agent when
establishing keys for content decryption using the RSA and RSAES-OAEP establishing keys for content decryption using the RSA and RSAES-OAEP
algorithms: algorithms:
key size <= 2047 : MAY (see Historic Mail Considerations) key size <= 2047 : MAY (Note 1)
2048 <= key size <= 4096 : MUST (see Security Considerations) 2048 <= key size <= 4096 : MUST (Note 2)
4096 < key size : MAY (see Security Considerations) 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. Key sizes for ECDH are fixed by the curve.
5. IANA Considerations 5. IANA Considerations
The following information updates the media type registration for The following information updates the media type registration for
application/pkcs7-mime and application/pkcs7-signature to refer to application/pkcs7-mime and application/pkcs7-signature to refer to
this document as opposed to RFC 2311. this document as opposed to RFC 2311.
Note that other documents can define additional MIME media types for Note that other documents can define additional MIME media types for
skipping to change at page 39, line 28 skipping to change at page 39, line 28
Security Considerations: See Section 6 of this document Security Considerations: See Section 6 of this document
Interoperability Considerations: See Sections 1-6 of this document Interoperability Considerations: See Sections 1-6 of this document
Published Specification: RFC 2311, RFC 2633, and this document Published Specification: RFC 2311, RFC 2633, and this document
Applications that use this media type: Security applications Applications that use this media type: Security applications
Additional information: NONE Additional information: NONE
Person & email to contact for further information: Person & email to contact for further information: iesg@ietf.org
S/MIME working group chairs smime-chairs@ietf.org
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: NONE Restrictions on usage: NONE
Author: Sean Turner Author: Sean Turner
Change Controller: S/MIME working group delegated from the IESG Change Controller: S/MIME working group delegated from the IESG
5.2. Media Type for application/pkcs7-signature 5.2. Media Type for application/pkcs7-signature
skipping to change at page 40, line 24 skipping to change at page 40, line 24
Security Considerations: See Section 6 of this document Security Considerations: See Section 6 of this document
Interoperability Considerations: See Sections 1-6 of this document Interoperability Considerations: See Sections 1-6 of this document
Published Specification: RFC 2311, RFC 2633, and this document Published Specification: RFC 2311, RFC 2633, and this document
Applications that use this media type: Security applications Applications that use this media type: Security applications
Additional information: NONE Additional information: NONE
Person & email to contact for further information: Person & email to contact for further information: iesg@ietf.org
S/MIME working group chairs smime-chairs@ietf.org
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: NONE Restrictions on usage: NONE
Author: Sean Turner Author: Sean Turner
Change Controller: S/MIME working group delegated from the IESG Change Controller: S/MIME working group delegated from the IESG
5.3. Register authEnvelopedData smime-type 5.3. Register authEnveloped-data smime-type
IANA is required to register the following value in the "Parameter IANA is required to register the following value in the "Parameter
Values for the smime-type Parameter" registry. The values to be Values for the smime-type Parameter" registry. The values to be
registered are: registered are:
smime-type value: authEnvelopedData smime-type value: authEnveloped-data
Reference: [[This Document, Section 3.2.2]] Reference: [[This Document, Section 3.2.2]]
6. Security Considerations 6. Security Considerations
Cryptographic algorithms will be broken or weakened over time. Cryptographic algorithms will be broken or weakened over time.
Implementers and users need to check that the cryptographic Implementers and users need to check that the cryptographic
algorithms listed in this document continue to provide the expected algorithms listed in this document continue to provide the expected
level of security. The IETF from time to time may issue documents level of security. The IETF from time to time may issue documents
dealing with the current state of the art. For example: dealing with the current state of the art. For example:
skipping to change at page 41, line 29 skipping to change at page 41, line 29
software to estimate the actual cost of recovering an encrypted software to estimate the actual cost of recovering an encrypted
message content that is encrypted with a key of a particular size. message content that is encrypted with a key of a particular size.
Further, it is quite difficult to determine the cost of a failed Further, it is quite difficult to determine the cost of a failed
decryption if a recipient cannot process a message's content. Thus, decryption if a recipient cannot process a message's content. Thus,
choosing between different key sizes (or choosing whether to just use choosing between different key sizes (or choosing whether to just use
plaintext) is also impossible for most people or software. However, plaintext) is also impossible for most people or software. However,
decisions based on these criteria are made all the time, and decisions based on these criteria are made all the time, and
therefore this specification gives a framework for using those therefore this specification gives a framework for using those
estimates in choosing algorithms. estimates in choosing algorithms.
The choice of 2048 bits as the RSA asymmetric key size in this 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 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 security. The key sizes that must be supported to conform to this
specification seem appropriate for the Internet based on [RFC3766]. specification seem appropriate for the Internet based on [RFC3766].
Of course, there are environments, such as financial and medical Of course, there are environments, such as financial and medical
systems, that may select different key sizes. For this reason, an systems, that may select different key sizes. For this reason, an
implementation MAY support key sizes beyond those recommended in this implementation MAY support key sizes beyond those recommended in this
specification. specification.
Receiving agents that validate signatures and sending agents that Receiving agents that validate signatures and sending agents that
encrypt messages need to be cautious of cryptographic processing encrypt messages need to be cautious of cryptographic processing
skipping to change at page 42, line 37 skipping to change at page 42, line 37
used for digital signatures. used for digital signatures.
If a sending agent is sending the same message using different If a sending agent is sending the same message using different
strengths of cryptography, an attacker watching the communications strengths of cryptography, an attacker watching the communications
channel might be able to determine the contents of the strongly channel might be able to determine the contents of the strongly
encrypted message by decrypting the weakly encrypted version. In encrypted message by decrypting the weakly encrypted version. In
other words, a sender SHOULD NOT send a copy of a message using other words, a sender SHOULD NOT send a copy of a message using
weaker cryptography than they would use for the original of the weaker cryptography than they would use for the original of the
message. message.
Modification of the ciphertext can go undetected if authentication is Modification of the ciphertext in EnvelopedData can go undetected if
not also used, which is the case when sending EnvelopedData without authentication is not also used, which is the case when sending
wrapping it in SignedData or enclosing SignedData within it. This is EnvelopedData without wrapping it in SignedData or enclosing
one of the reasons for moving from EnvelopedData to AuthEnvelopedData SignedData within it. This is one of the reasons for moving from
as the authenticated encryption algorithms provide the authentication EnvelopedData to AuthEnvelopedData as the authenticated encryption
without needing the SignedData layer. algorithms provide the authentication without needing the SignedData
layer.
If an implementation is concerned about compliance with National If an implementation is concerned about compliance with National
Institute of Standards and Technology (NIST) key size Institute of Standards and Technology (NIST) key size
recommendations, then see [SP800-57]. recommendations, then see [SP800-57].
If messaging environments make use of the fact that a message is If messaging environments make use of the fact that a message is
signed to change the behavior of message processing (examples would signed to change the behavior of message processing (examples would
be running rules or UI display hints), without first verifying that be running rules or UI display hints), without first verifying that
the message is actually signed and knowing the state of the the message is actually signed and knowing the state of the
signature, this can lead to incorrect handling of the message. signature, this can lead to incorrect handling of the message.
skipping to change at page 43, line 37 skipping to change at page 43, line 38
- A direct path needs to exist from the starting key to the key used - 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 as the content encryption key (CEK) which guarantees that no third
party could have seen the resulting CEK. This means that one party could have seen the resulting CEK. This means that one
needs to be using an algorithm that is called a "Direct needs to be using an algorithm that is called a "Direct
Encryption" or a "Direct Key Agreement" algorithm in other Encryption" or a "Direct Key Agreement" algorithm in other
contexts. This means that the starting key is used directly as 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 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. which then is transformed into the CEK via a KDF step.
S/MIME implementations almost universally use ephemeral-static rather S/MIME implementations almost universally use ephemeral-static rather
than static-static key agreement and do not use a pre-existing shared than static-static key agreement and do not use a shared secret for
secret when doing encryption, this means that the first precondition encryption, this means that the first precondition is not met. There
is not met. There is a document [RFC6278] which defined how to use is a document [RFC6278] which defined how to use static-static key
static-static key agreement with CMS so that is readably doable. agreement with CMS so that is readably doable. Currently, all S/MIME
Currently, all S/MIME key agreement methods derive a KEK and wrap a key agreement methods derive a KEK and wrap a CEK. This violates the
CEK. This violates the third precondition above. New key key third precondition above. New key agreement algorithms that directly
agreement algorithms that directly created the CEK without creating created the CEK without creating an intervening KEK would need to be
an intervening KEK would need to be defined. defined.
Even when all of the preconditions are met and origination of a Even when all of the preconditions are met and origination of a
message is established by the use of an authenticated encryption message is established by the use of an authenticated encryption
algorithm, users need to be aware that there is no way to prove this 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 to a third party. This is because either of the parties can
successfully create the message (or just alter the content) based on 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 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 origination is always built on a presumption that "I did not send
this message to myself." this message to myself."
All of the authenticated encryption algorithms in this document use All of the authenticated encryption algorithms in this document use
counter mode for the encryption portion of the algorithm. This means 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 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 text length and the plain text length are always the same. This
information can enable passive observers to infer information based information can enable passive observers to infer information based
solely on the length of the message. Applications for which this is solely on the length of the message. Applications for which this is
a significant problem need to provide some type of padding algorithm a concern need to provide some type of padding so that the length of
so that the length of the message does not provide this information. the message does not provide this information.
7. References 7. References
7.1. Normative References 7.1. Normative References
[ASN.1] "Information Technology - Abstract Syntax Notation [ASN.1] "Information Technology - Abstract Syntax Notation
(ASN.1)". (ASN.1)".
ASN.1 syntax consists of the following references [X.680], ASN.1 syntax consists of the following references [X.680],
[X.681], [X.682], and [X.683]. [X.681], [X.682], and [X.683].
skipping to change at page 45, line 13 skipping to change at page 45, line 13
cms-ecdh-new-curves-01 (work in progress), September 2016. cms-ecdh-new-curves-01 (work in progress), September 2016.
[I-D.ietf-curdle-cms-eddsa-signatures] [I-D.ietf-curdle-cms-eddsa-signatures]
Housley, R., "Use of EdDSA Signatures in the Cryptographic Housley, R., "Use of EdDSA Signatures in the Cryptographic
Message Syntax (CMS)", draft-ietf-curdle-cms-eddsa- Message Syntax (CMS)", draft-ietf-curdle-cms-eddsa-
signatures-03 (work in progress), January 2017. signatures-03 (work in progress), January 2017.
[I-D.ietf-lamps-rfc5750-bis] [I-D.ietf-lamps-rfc5750-bis]
Schaad, J., Ramsdell, B., and S. Turner, "Secure/ Schaad, J., Ramsdell, B., and S. Turner, "Secure/
Multipurpose Internet Mail Extensions (S/ MIME) Version Multipurpose Internet Mail Extensions (S/ MIME) Version
4.0 Certificate Handling", draft-ietf-lamps-rfc5750-bis-01 4.0 Certificate Handling", draft-ietf-lamps-rfc5750-bis-02
(work in progress), October 2016. (work in progress), February 2017.
[MIME-SPEC] [MIME-SPEC]
"MIME Message Specifications". "MIME Message Specifications".
This is the set of documents that define how to use MIME. This is the set of documents that define how to use MIME.
This set of documents is [RFC2045], [RFC2046], [RFC2047], This set of documents is [RFC2045], [RFC2046], [RFC2047],
[RFC2049], [RFC4288], and [RFC4289]. [RFC2049], [RFC4288], and [RFC4289].
[RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed,
"Security Multiparts for MIME: Multipart/Signed and "Security Multiparts for MIME: Multipart/Signed and
skipping to change at page 57, line 26 skipping to change at page 57, line 26
A number of the members of the S/MIME Working Group have also worked 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 very hard and contributed to this document. Any list of people is
doomed to omission, and for that I apologize. In alphabetical order, doomed to omission, and for that I apologize. In alphabetical order,
the following people stand out in my mind because they made direct the following people stand out in my mind because they made direct
contributions to various versions of this document: contributions to various versions of this document:
Tony Capel, Piers Chivers, Dave Crocker, Bill Flanigan, Peter Tony Capel, Piers Chivers, Dave Crocker, Bill Flanigan, Peter
Gutmann, Alfred Hoenes, Paul Hoffman, Russ Housley, William Ottaway, Gutmann, Alfred Hoenes, Paul Hoffman, Russ Housley, William Ottaway,
and John Pawling. and John Pawling.
The version 4 update to the S/MIME documents was done under the
auspices of the LAMPS Working Group.
Authors' Addresses Authors' Addresses
Jim Schaad Jim Schaad
August Cellars August Cellars
Email: ietf@augustcellars.com Email: ietf@augustcellars.com
Blake Ramsdell Blake Ramsdell
Brute Squad Labs, Inc. Brute Squad Labs, Inc.
 End of changes. 45 change blocks. 
139 lines changed or deleted 162 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/