< draft-ietf-lamps-rfc5751-bis-06.txt   draft-ietf-lamps-rfc5751-bis-07.txt >
LAMPS J. Schaad LAMPS J. Schaad
Internet-Draft August Cellars Internet-Draft August Cellars
Obsoletes: 5751 (if approved) B. Ramsdell Obsoletes: 5751 (if approved) B. Ramsdell
Intended status: Standards Track Brute Squad Labs, Inc. Intended status: Standards Track Brute Squad Labs, Inc.
Expires: October 16, 2017 S. Turner Expires: October 15, 2018 S. Turner
sn3rd sn3rd
April 14, 2017 April 13, 2018
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-06 draft-ietf-lamps-rfc5751-bis-07
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 40 skipping to change at page 1, line 40
be discussed on the LAMPS mailing list. be discussed on the LAMPS mailing list.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://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 October 16, 2017. This Internet-Draft will expire on October 15, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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 (https://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
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 . . . . . . . . . . . . . . . . . . . . . . . . . 10 2. CMS Options . . . . . . . . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . . . . 12 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
skipping to change at page 3, line 23 skipping to change at page 3, line 23
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
3.1.4. Sample Canonical MIME Entity . . . . . . . . . . . . 23 3.1.4. Sample Canonical MIME Entity . . . . . . . . . . . . 23
3.2. The application/pkcs7-mime Media Type . . . . . . . . . . 24 3.2. The application/pkcs7-mime Media Type . . . . . . . . . . 24
3.2.1. The name and filename Parameters . . . . . . . . . . 25 3.2.1. The name and filename Parameters . . . . . . . . . . 25
3.2.2. The smime-type Parameter . . . . . . . . . . . . . . 26 3.2.2. The smime-type Parameter . . . . . . . . . . . . . . 26
3.3. Creating an Enveloped-Only Message . . . . . . . . . . . 27 3.3. Creating an Enveloped-Only Message . . . . . . . . . . . 27
3.4. Creating an Authenticated Enveloped-Only Message . . . . 27 3.4. Creating an Authenticated Enveloped-Only Message . . . . 28
3.5. Creating a Signed-Only Message . . . . . . . . . . . . . 29 3.5. Creating a Signed-Only Message . . . . . . . . . . . . . 29
3.5.1. Choosing a Format for Signed-Only Messages . . . . . 29 3.5.1. Choosing a Format for Signed-Only Messages . . . . . 29
3.5.2. Signing Using application/pkcs7-mime with SignedData 30 3.5.2. Signing Using application/pkcs7-mime with SignedData 30
3.5.3. Signing Using the multipart/signed Format . . . . . . 31 3.5.3. Signing Using the multipart/signed Format . . . . . . 31
3.6. Creating a Compressed-Only Message . . . . . . . . . . . 34 3.6. Creating a Compressed-Only Message . . . . . . . . . . . 34
3.7. Multiple Operations . . . . . . . . . . . . . . . . . . . 34 3.7. Multiple Operations . . . . . . . . . . . . . . . . . . . 34
3.8. Creating a Certificate Management Message . . . . . . . . 35 3.8. Creating a Certificate Management Message . . . . . . . . 35
3.9. Registration Requests . . . . . . . . . . . . . . . . . . 36 3.9. Registration Requests . . . . . . . . . . . . . . . . . . 36
3.10. Identifying an S/MIME Message . . . . . . . . . . . . . . 36 3.10. Identifying an S/MIME Message . . . . . . . . . . . . . . 36
4. Certificate Processing . . . . . . . . . . . . . . . . . . . 36 4. Certificate Processing . . . . . . . . . . . . . . . . . . . 36
skipping to change at page 3, line 49 skipping to change at page 3, line 49
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 authEnveloped-data 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 . . . . . . . . . . . . . . . . 53 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
Appendix C. Moving S/MIME v2 Message Specification to Historic Appendix C. Moving S/MIME v2 Message Specification to Historic
Status . . . . . . . . . . . . . . . . . . . . . . . 56 Status . . . . . . . . . . . . . . . . . . . . . . . 56
Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 57 Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 57
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57
1. Introduction 1. Introduction
skipping to change at page 5, line 39 skipping to change at page 5, line 39
1.2. Definitions 1.2. Definitions
For the purposes of this specification, the following definitions For the purposes of this specification, the following definitions
apply. apply.
ASN.1: Abstract Syntax Notation One, as defined in ITU-T ASN.1: Abstract Syntax Notation One, as defined in ITU-T
Recommendations X.680, X.681, X.682 and X.683 Recommendations X.680, X.681, X.682 and X.683
[ASN.1]. [ASN.1].
BER: Basic Encoding Rules for ASN.1, as defined in ITU- BER: Basic Encoding Rules for ASN.1, as defined in
T Recommendation X.690 [X.690]. ITU-T Recommendation X.690 [X.690].
Certificate: A type that binds an entity's name to a public key Certificate: A type that binds an entity's name to a public key
with a digital signature. with a digital signature.
DER: Distinguished Encoding Rules for ASN.1, as defined DER: Distinguished Encoding Rules for ASN.1, as defined
in ITU-T Recommendation X.690 [X.690]. in ITU-T Recommendation X.690 [X.690].
7-bit data: Text data with lines less than 998 characters 7-bit data: Text data with lines less than 998 characters
long, where none of the characters have the 8th long, where none of the characters have the 8th
bit set, and there are no NULL characters. <CR> bit set, and there are no NULL characters. <CR>
skipping to change at page 6, line 29 skipping to change at page 6, line 29
objects, MIME body parts that contain CMS content objects, MIME body parts that contain CMS content
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 against
unauthorized changes to data by ensuring 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 disclosed to
system entities unless they have been authorized system entities unless they have been authorized
to know the data. [RFC4949] to know the data. [RFC4949]
Data Origination: The corroboration that the source of the data
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 the additional requirement levels: 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
skipping to change at page 9, line 13 skipping to change at page 9, line 8
and AES-256 CBC SHOULD+, tripleDES now SHOULD-. and AES-256 CBC SHOULD+, tripleDES now SHOULD-.
Section 2.7.1: Updated pointers from 2.7.2.1 through 2.7.2.4 to Section 2.7.1: Updated pointers from 2.7.2.1 through 2.7.2.4 to
2.7.1.1 to 2.7.1.2. 2.7.1.1 to 2.7.1.2.
Section 3.1.1: Removed text about MIME character sets. Section 3.1.1: Removed text about MIME character sets.
Section 3.2.2 and 3.6: Replaced "encrypted" with "enveloped". Update Section 3.2.2 and 3.6: Replaced "encrypted" with "enveloped". Update
OID example to use AES-128 CBC oid. OID example to use AES-128 CBC oid.
Section 3.4.3.2: Replace micalg parameter for SHA-1 with sha-1. Section 3.4.3.2: Replace "micalg" parameter for "SHA-1" with "sha-1".
Section 4: Updated reference to CERT v3.2. Section 4: Updated reference to CERT v3.2.
Section 4.1: Updated RSA and DSA key size discussion. Moved last Section 4.1: Updated RSA and DSA key size discussion. Moved last
four sentences to security considerations. Updated reference to four sentences to security considerations. Updated reference to
randomness requirements for security. randomness requirements for security.
Section 5: Added IANA registration templates to update media type Section 5: Added IANA registration templates to update media type
registry to point to this document as opposed to RFC 2311. registry to point to this document as opposed to RFC 2311.
skipping to change at page 10, line 35 skipping to change at page 10, line 29
- MUST support SHA-256. - MUST support SHA-256.
- MUST support SHA-512. - MUST support SHA-512.
[RFC5754] provides the details for using these algorithms with [RFC5754] provides the details for using these algorithms with
S/MIME. S/MIME.
2.2. SignatureAlgorithmIdentifier 2.2. SignatureAlgorithmIdentifier
There are different sets of requirements placed on receiving and
sending agents. By having the different requirements, the maximum
amount of interoperability is achieved as it allows for specialized
protection of private key material but maximum signature validation.
Receiving agents: Receiving agents:
- MUST support ECDSA with curve P-256 and SHA-256. - MUST support ECDSA with curve P-256 and SHA-256.
- MUST support EdDSA with curve 25519 using PureEdDSA mode. - MUST support EdDSA with curve 25519 using PureEdDSA mode.
- MUST- support RSA with SHA-256. - MUST- support RSA PKCS#1 v1.5 with SHA-256.
- SHOULD support RSASSA-PSS with SHA-256. - SHOULD support RSASSA-PSS with SHA-256.
- MUST NOT support EdDSA using the pre-hash mode.
Sending agents: Sending agents:
- MUST support at least one of the following algorithms: ECDSA with - MUST support at least one of the following algorithms: ECDSA with
curve P-256 and SHA-256, or EdDSA with curve 25519 using PureEdDSA curve P-256 and SHA-256, or EdDSA with curve 25519 using PureEdDSA
mode. mode.
- MUST- support RSA with SHA-256. - MUST- support RSA PKCS#1 v1.5 with SHA-256.
- SHOULD support RSASSA-PSS with SHA-256. - SHOULD support RSASSA-PSS with SHA-256.
- MUST NOT support EdDSA using the pre-hash mode.
Both ECDSA and EdDSA are included in the list of required algorithms Both ECDSA and EdDSA are included in the list of required algorithms
for political reasons. NIST is unable to provide the seeds that were for political reasons. NIST is unable to provide the seeds that were
used to create their standardized curves, this means that there is a used to create their standardized curves, this means that there is a
section of the community which believes that there might be a section of the community which believes that there might be a back
backdoor to these curves. The EdDSA curves were, in part, created in door to these curves. The EdDSA curves were standardized in the IETF
response to this feeling. However, there are still significant in a more transparent method. However, there are still significant
sections of the industry which need to have NIST approved algorithms. sections of the industry which need to have NIST approved algorithms.
For this reason, both sets of curves are represented in the recieving For this reason, both sets of curves are represented in the receiving
agent list, but there is only a requirement for curve in the sending agent list, but there is only a requirement for curve in the sending
agent list. agent list. This requirement makes sure that maximum
interoperability between receivers and senders will exist.
See Section 4.1 for information on key size and algorithm references. See Section 4.1 for information on key size and algorithm references.
2.3. KeyEncryptionAlgorithmIdentifier 2.3. KeyEncryptionAlgorithmIdentifier
Receiving and sending agents: Receiving and sending agents:
- MUST support ECDH ephemeral-static mode for P-256, as specified in - MUST support ECDH ephemeral-static mode for P-256, as specified in
[RFC5753]. [RFC5753].
skipping to change at page 11, line 45 skipping to change at page 11, line 42
- MUST- support RSA Encryption, as specified in [RFC3370]. - MUST- support RSA Encryption, as specified in [RFC3370].
- SHOULD+ support RSAES-OAEP, as specified in [RFC3560]. - SHOULD+ support RSAES-OAEP, as specified in [RFC3560].
When ECDH ephemeral-static is used, a key wrap algorithm is also When ECDH ephemeral-static is used, a key wrap algorithm is also
specified in the KeyEncryptionAlgorithmIdentifier [RFC5652]. The specified in the KeyEncryptionAlgorithmIdentifier [RFC5652]. The
underlying encryption functions for the key wrap and content underlying encryption functions for the key wrap and content
encryption algorithm ([RFC3370] and [RFC3565]) and the key sizes for encryption algorithm ([RFC3370] and [RFC3565]) and the key sizes for
the two algorithms MUST be the same (e.g., AES-128 key wrap algorithm the two algorithms MUST be the same (e.g., AES-128 key wrap algorithm
with AES-128 content encryption algorithm). As both 128 and 256 bit with AES-128 content encryption algorithm). As both 128 and 256 bit
AES modes are mandatory-to-implment as content encryption algorithms AES modes are mandatory-to-implement as content encryption algorithms
(Section 2.7), both the AES-128 and AES-256 key wrap algorithms MUST (Section 2.7), both the AES-128 and AES-256 key wrap algorithms MUST
be supported when ECDH ephemeral-static is used. be supported when ECDH ephemeral-static is used.
Appendix B provides information on algorithms support in older Appendix B provides information on algorithms support in older
versions of S/MIME. versions of S/MIME.
2.4. General Syntax 2.4. General Syntax
There are several CMS content types. Of these, only the Data, There are several CMS content types. Of these, only the Data,
SignedData, EnvelopedData, AuthEnvelopedData, and CompressedData SignedData, EnvelopedData, AuthEnvelopedData, and CompressedData
skipping to change at page 14, line 22 skipping to change at page 14, line 22
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"). The presence key encipherment algorithms (such as "rsaEncryption"). The presence
of an algorthm based SMIME Capability attribute in this sequence of an algorithm based SMIME Capability attribute in this sequence
implies that the sender can deal with the algorithm as well as implies that the sender can deal with the algorithm as well as
undertanding the ASN.1 structures associated with that algorithm. understanding the ASN.1 structures associated with that algorithm.
There are also several identifiers that indicate support for other There are also several identifiers that indicate support for other
optional features such as binary encoding and compression. The 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. CMS defines SignedAttributes as a SET OF Attribute.
SignedAttributes as a SET OF Attribute. The SignedAttributes in a The SignedAttributes in a signerInfo MUST include a single instance
signerInfo MUST NOT include multiple instances of the of the SMIMECapabilities attribute. CMS defines the ASN.1 syntax for
SMIMECapabilities attribute. CMS defines the ASN.1 syntax for
Attribute to include attrValues SET OF AttributeValue. A Attribute to include attrValues SET OF AttributeValue. A
SMIMECapabilities attribute MUST only include a single instance of SMIMECapabilities attribute MUST only include a single instance of
AttributeValue. There MUST NOT be zero or multiple instances of AttributeValue. If a signature is detected to violate these
AttributeValue present in the attrValues SET OF AttributeValue. requirements, the signature SHOULD be treated as failing.
The semantics of the SMIMECapabilities attribute specify a partial The semantics of the SMIMECapabilities attribute specify a partial
list as to what the client announcing the SMIMECapabilities can list as to what the client announcing the SMIMECapabilities can
support. A client does not have to list every capability it support. A client does not have to list every capability it
supports, and need not list all its capabilities so that the supports, and need not list all its capabilities so that the
capabilities list doesn't get too long. In an SMIMECapabilities capabilities list doesn't get too long. In an SMIMECapabilities
attribute, the object identifiers (OIDs) are listed in order of their attribute, the object identifiers (OIDs) are listed in order of their
preference, but SHOULD be separated logically along the lines of preference, but SHOULD be separated logically along the lines of
their categories (signature algorithms, symmetric algorithms, key their categories (signature algorithms, symmetric algorithms, key
encipherment algorithms, etc.). encipherment algorithms, etc.).
The structure of the SMIMECapabilities attribute is to facilitate The structure of the SMIMECapabilities attribute is to facilitate
simple table lookups and binary comparisons in order to determine simple table lookups and binary comparisons in order to determine
matches. For instance, the DER-encoding for the SMIMECapability for matches. For instance, the encoding for the SMIMECapability for
AES-128 CBC MUST be identically encoded regardless of the sha256WithRSAEncryption includes rather than omits the NULL
implementation. Because of the requirement for identical encoding, parameter. Because of the requirement for identical encoding,
individuals documenting algorithms to be used in the individuals documenting algorithms to be used in the
SMIMECapabilities attribute SHOULD explicitly document the correct SMIMECapabilities attribute SHOULD explicitly document the correct
byte sequence for the common cases. byte sequence for the common cases.
For any capability, the associated parameters for the OID MUST For any capability, the associated parameters for the OID MUST
specify all of the parameters necessary to differentiate between two specify all of the parameters necessary to differentiate between two
instances of the same algorithm. instances of the same algorithm.
The OIDs that correspond to algorithms SHOULD use the same OID as the The OIDs that correspond to algorithms SHOULD use the same OID as the
actual algorithm, except in the case where the algorithm usage is actual algorithm, except in the case where the algorithm usage is
skipping to change at page 15, line 51 skipping to change at page 15, line 48
The encryption key preference attribute allows the signer to The encryption key preference attribute allows the signer to
unambiguously describe which of the signer's certificates has the unambiguously describe which of the signer's certificates has the
signer's preferred encryption key. This attribute is designed to signer's preferred encryption key. This attribute is designed to
enhance behavior for interoperating with those clients that use enhance behavior for interoperating with those clients that use
separate keys for encryption and signing. This attribute is used to separate keys for encryption and signing. This attribute is used to
convey to anyone viewing the attribute which of the listed convey to anyone viewing the attribute which of the listed
certificates is appropriate for encrypting a session key for future certificates is appropriate for encrypting a session key for future
encrypted messages. encrypted messages.
If present, the SMIMEEncryptionKeyPreference attribute MUST be a If present, the SMIMEEncryptionKeyPreference attribute MUST be a
SignedAttribute; it MUST NOT be an UnsignedAttribute. CMS defines SignedAttribute. CMS defines SignedAttributes as a SET OF Attribute.
SignedAttributes as a SET OF Attribute. The SignedAttributes in a The SignedAttributes in a signerInfo MUST include a single instance
signerInfo MUST NOT include multiple instances of the of the SMIMEEncryptionKeyPreference attribute. CMS defines the ASN.1
SMIMEEncryptionKeyPreference attribute. CMS defines the ASN.1 syntax syntax for Attribute to include attrValues SET OF AttributeValue. A
for Attribute to include attrValues SET OF AttributeValue. A
SMIMEEncryptionKeyPreference attribute MUST only include a single SMIMEEncryptionKeyPreference attribute MUST only include a single
instance of AttributeValue. There MUST NOT be zero or multiple instance of AttributeValue. If a signature is detected to violate
instances of AttributeValue present in the attrValues SET OF these requirements, the signature SHOULD be treated as failing.
AttributeValue.
The sending agent SHOULD include the referenced certificate in the The sending agent SHOULD include the referenced certificate in the
set of certificates included in the signed message if this attribute set of certificates included in the signed message if this attribute
is used. The certificate MAY be omitted if it has been previously is used. The certificate MAY be omitted if it has been previously
made available to the receiving agent. Sending agents SHOULD use made available to the receiving agent. Sending agents SHOULD use
this attribute if the commonly used or preferred encryption this attribute if the commonly used or preferred encryption
certificate is not the same as the certificate used to sign the certificate is not the same as the certificate used to sign the
message. message.
Receiving agents SHOULD store the preference data if the signature on Receiving agents SHOULD store the preference data if the signature on
skipping to change at page 19, line 7 skipping to change at page 19, line 4
If the following two conditions are met: If the following two conditions are met:
- the sending agent has no knowledge of the encryption capabilities - the sending agent has no knowledge of the encryption capabilities
of the recipient, and of the recipient, and
- the sending agent has no knowledge of the version of S/MIME of the - the sending agent has no knowledge of the version of S/MIME of the
recipient, recipient,
then the sending agent SHOULD use AES-256 GCM because it is a then the sending agent SHOULD use AES-256 GCM because it is a
stronger algorithm and is required by S/MIME v4.0. If the sending stronger algorithm and is required by S/MIME v4.0. If the sending
agent chooses not to use AES-256 GCM in this step, it SHOULD use agent chooses not to use AES-256 GCM in this step, given the
AES-128 CBC. presumption is that a client implementing AES-GCM would do both
AES-256 and AES-128, it SHOULD use AES-128 CBC.
2.7.2. Choosing Weak Encryption 2.7.2. Choosing Weak Encryption
All algorithms that use 112-bit keys are considered by many to be All algorithms that use 112-bit keys are considered by many to be
weak encryption. A sending agent that is controlled by a human weak encryption. A sending agent that is controlled by a human
SHOULD allow a human sender to determine the risks of sending data SHOULD allow a human sender to determine the risks of sending data
using a weak encryption algorithm before sending the data, and using a weak encryption algorithm before sending the data, and
possibly allow the human to use a stronger encryption method such as possibly allow the human to use a stronger encryption method such as
AES GCM or AES CBC. AES GCM or AES CBC.
skipping to change at page 21, line 12 skipping to change at page 21, line 12
When an S/MIME message is received, the security services on the When an S/MIME message is received, the security services on the
message are processed, and the result is the MIME entity. That MIME 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 entity is typically passed to a MIME-capable user agent where it is
further decoded and presented to the user or receiving application. further decoded and presented to the user or receiving application.
In order to protect outer, non-content-related message header fields In order to protect outer, non-content-related message header fields
(for instance, the "Subject", "To", "From", and "Cc" fields), the (for instance, the "Subject", "To", "From", and "Cc" fields), the
sending client MAY wrap a full MIME message in a message/rfc822 sending client MAY wrap a full MIME message in a message/rfc822
wrapper in order to apply S/MIME security services to these header 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 fields. It is up to the receiving client to decide how to present
this "inner" header along with the unprotected "outer" header. 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 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 entity has a Content-Type of message/rfc822, it can be assumed that
the intent was to provide header protection. This entity SHOULD be the intent was to provide header protection. This entity SHOULD be
presented as the top-level message, taking into account header presented as the top-level message, taking into account header
merging issues as previously discussed. merging issues as previously discussed.
3.1.1. Canonicalization 3.1.1. Canonicalization
Each MIME entity MUST be converted to a canonical form that is Each MIME entity MUST be converted to a canonical form that is
skipping to change at page 22, line 13 skipping to change at page 22, line 13
MUST be used. MUST be used.
3.1.2. Transfer Encoding 3.1.2. Transfer Encoding
When generating any of the secured MIME entities below, except the When generating any of the secured MIME entities below, except the
signing using the multipart/signed format, no transfer encoding is signing using the multipart/signed format, no transfer encoding is
required at all. S/MIME implementations MUST be able to deal with required at all. S/MIME implementations MUST be able to deal with
binary MIME objects. If no Content-Transfer-Encoding header field is binary MIME objects. If no Content-Transfer-Encoding header field is
present, the transfer encoding is presumed to be 7BIT. present, the transfer encoding is presumed to be 7BIT.
S/MIME implementations SHOULD however use transfer encoding described As a rule, S/MIME implementations SHOULD use transfer encoding
in Section 3.1.3 for all MIME entities they secure. The reason for described in Section 3.1.3 for all MIME entities they secure. The
securing only 7-bit MIME entities, even for enveloped data that are reason for securing only 7-bit MIME entities, even for enveloped data
not exposed to the transport, is that it allows the MIME entity to be that is not exposed to the transport, is that it allows the MIME
handled in any environment without changing it. For example, a entity to be handled in any environment without changing it. For
trusted gateway might remove the envelope, but not the signature, of example, a trusted gateway might remove the envelope, but not the
a message, and then forward the signed message on to the end signature, of a message, and then forward the signed message on to
recipient so that they can verify the signatures directly. If the the end recipient so that they can verify the signatures directly.
transport internal to the site is not 8-bit clean, such as on a wide- If the transport internal to the site is not 8-bit clean, such as on
area network with a single mail gateway, verifying the signature will a wide-area network with a single mail gateway, verifying the
not be possible unless the original MIME entity was only 7-bit data. signature will not be possible unless the original MIME entity was
only 7-bit data.
S/MIME implementations that "know" that all intended recipients are In the case where S/MIME implementations can determine that all
capable of handling inner (all but the outermost) binary MIME objects intended recipients are capable of handling inner (all but the
SHOULD use binary encoding as opposed to a 7-bit-safe transfer outermost) binary MIME objects SHOULD use binary encoding as opposed
encoding for the inner entities. The use of a 7-bit-safe encoding to a 7-bit-safe transfer encoding for the inner entities. The use of
(such as base64) would unnecessarily expand the message size. a 7-bit-safe encoding (such as base64) unnecessarily expands the
Implementations MAY "know" that recipient implementations are capable message size. Implementations MAY determine that recipient
of handling inner binary MIME entities either by interpreting the id- implementations are capable of handling inner binary MIME entities
cap-preferBinaryInside SMIMECapabilities attribute, by prior either by interpreting the id-cap-preferBinaryInside
agreement, or by other means. SMIMECapabilities attribute, by prior agreement, or by other means.
If one or more intended recipients are unable to handle inner binary If one or more intended recipients are unable to handle inner binary
MIME objects, or if this capability is unknown for any of the MIME objects, or if this capability is unknown for any of the
intended recipients, S/MIME implementations SHOULD use transfer intended recipients, S/MIME implementations SHOULD use transfer
encoding described in Section 3.1.3 for all MIME entities they encoding described in Section 3.1.3 for all MIME entities they
secure. secure.
3.1.3. Transfer Encoding for Signing Using multipart/signed 3.1.3. Transfer Encoding for Signing Using multipart/signed
If a multipart/signed entity is ever to be transmitted over the If a multipart/signed entity is ever to be transmitted over the
skipping to change at page 23, line 22 skipping to change at page 23, line 25
invalidate the signature. invalidate the signature.
- The agent could transmit the data anyway, which would most likely - The agent could transmit the data anyway, which would most likely
result in the 8th bit being corrupted; this too would invalidate result in the 8th bit being corrupted; this too would invalidate
the signature. the signature.
- The agent could return the message to the sender. - The agent could return the message to the sender.
[RFC1847] prohibits an agent from changing the transfer encoding of [RFC1847] prohibits an agent from changing the transfer encoding of
the first part of a multipart/signed message. If a compliant agent the first part of a multipart/signed message. If a compliant agent
that cannot transmit 8-bit or binary data encounters a that cannot transmit 8-bit or binary data encountered a
multipart/signed message with 8-bit or binary data in the first part, 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. it would have to return the message to the sender as undeliverable.
3.1.4. Sample Canonical MIME Entity 3.1.4. Sample Canonical MIME Entity
This example shows a multipart/mixed message with full transfer This example shows a multipart/mixed message with full transfer
encoding. This message contains a text part and an attachment. The encoding. This message contains a text part and an attachment. The
sample message text includes characters that are not ASCII and thus sample message text includes characters that are not ASCII and thus
need to be transfer encoded. Though not shown here, the end of each 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 line is <CR><LF>. The line ending of the MIME headers, the text, and
skipping to change at page 25, line 29 skipping to change at page 25, line 29
For the application/pkcs7-mime, sending agents SHOULD emit the For the application/pkcs7-mime, sending agents SHOULD emit the
optional "name" parameter to the Content-Type field for compatibility optional "name" parameter to the Content-Type field for compatibility
with older systems. Sending agents SHOULD also emit the optional with older systems. Sending agents SHOULD also emit the optional
Content-Disposition field [RFC2138] with the "filename" parameter. Content-Disposition field [RFC2138] with the "filename" parameter.
If a sending agent emits the above parameters, the value of the If a sending agent emits the above parameters, the value of the
parameters SHOULD be a file name with the appropriate extension: parameters SHOULD be a file name with the appropriate extension:
Media Type File Media Type File
Extension Extension
application/pkcs7-mime (SignedData, EnvelopedData) .p7m application/pkcs7-mime (SignedData, EnvelopedData, .p7m
AuthEnvelopedData)
application/pkcs7-mime (degenerate SignedData certificate .p7c application/pkcs7-mime (degenerate SignedData certificate .p7c
management message) management message)
application/pkcs7-mime (CompressedData) .p7z application/pkcs7-mime (CompressedData) .p7z
application/pkcs7-signature (SignedData) .p7s application/pkcs7-signature (SignedData) .p7s
In addition, the file name SHOULD be limited to eight characters In addition, the file name SHOULD be limited to eight characters
followed by a three-letter extension. The eight-character filename followed by a three-letter extension. The eight-character filename
base can be any distinct name; the use of the filename base "smime" 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 SHOULD be used to indicate that the MIME entity is associated with
S/MIME. S/MIME.
skipping to change at page 27, line 9 skipping to change at page 27, line 9
"authEnveloped" or "enveloped" without having to tunnel into the CMS "authEnveloped" or "enveloped" without having to tunnel into the CMS
payload. payload.
A registry for additional smime-type parameter values has been A registry for additional smime-type parameter values has been
defined in [RFC7114]. defined in [RFC7114].
3.3. Creating an Enveloped-Only Message 3.3. Creating an 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. It is important to note that sending enveloped without signing it. It is important to note that sending enveloped
but not signed messages does not provide for data integrity. It is but not signed messages does not provide for data integrity. The
possible to replace ciphertext in such a way that the processed Enveloped-Only structure does not support authenticated symmetric
message will still be valid, but the meaning can be altered. 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 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 EnvelopedData. In addition to encrypting CMS object of type EnvelopedData. In addition to encrypting
a copy of the content-encryption key for each recipient, a a copy of the content-encryption key for each recipient, a
copy of the content-encryption key SHOULD be encrypted for copy of the content-encryption key SHOULD be encrypted for
the originator and included in the EnvelopedData (see the originator and included in the EnvelopedData (see
[RFC5652], Section 6). [RFC5652], Section 6).
skipping to change at page 27, line 52 skipping to change at page 28, line 11
bWx8+MDFbbpXadCDgO8/nUkUNYeNxJtuzubGgzoyEd8Ch4H/dd9gdzTd+taTEgS0ip bWx8+MDFbbpXadCDgO8/nUkUNYeNxJtuzubGgzoyEd8Ch4H/dd9gdzTd+taTEgS0ip
dSJuNnkVY4/M652jKKHRLFf02hosdR8wQwYJKoZIhvcNAQcBMBQGCCqGSIb3DQMHBA dSJuNnkVY4/M652jKKHRLFf02hosdR8wQwYJKoZIhvcNAQcBMBQGCCqGSIb3DQMHBA
gtaMXpRwZRNYAgDsiSf8Z9P43LrY4OxUk660cu1lXeCSFOSOpOJ7FuVyU= 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 data integrity. It is important to note that confidentiality and data integrity. It is important to note that
sending authenticated enveloped messages does not provide for sending authenticated enveloped messages does not provide for
authentication when using S/MIME. It is possible to replace origination when using S/MIME. It is possible for a third party to
ciphertext in such a way that the processed message will still be replace ciphertext in such a way that the processed message will
valid, but the meaning can be altered. However this is substantially still be valid, but the meaning can be altered. However this is
more difficult than it is for an enveloped-only message as the 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 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]).
skipping to change at page 33, line 15 skipping to change at page 33, line 15
(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=sha-1;
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
skipping to change at page 41, line 49 skipping to change at page 41, line 49
encrypt messages need to be cautious of cryptographic processing encrypt messages need to be cautious of cryptographic processing
usage when validating signatures and encrypting messages using keys usage when validating signatures and encrypting messages using keys
larger than those mandated in this specification. An attacker could larger than those mandated in this specification. An attacker could
send certificates with keys that would result in excessive send certificates with keys that would result in excessive
cryptographic processing, for example, keys larger than those cryptographic processing, for example, keys larger than those
mandated in this specification, which could swamp the processing mandated in this specification, which could swamp the processing
element. Agents that use such keys without first validating the element. Agents that use such keys without first validating the
certificate to a trust anchor are advised to have some sort of certificate to a trust anchor are advised to have some sort of
cryptographic resource management system to prevent such attacks. cryptographic resource management system to prevent such attacks.
Using weak cryptography in S/MIME offers little actual security over Some cryptographic algorithms such as RC2 offer little actual
sending plaintext. However, other features of S/MIME, such as the security over sending plaintext. Other algorithms such as TripleDES,
specification of AES and the ability to announce stronger provide security but are no longer considered to be state of the art.
cryptographic capabilities to parties with whom you communicate, S/MIME requires the use of current state of the art algorithms such
allow senders to create messages that use strong encryption. Using as AES and provides the ability to announce starter cryptographic
weak cryptography is never recommended unless the only alternative is capabilities to parties with whom you communicate. This allows the
no cryptography. 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 RSA and DSA keys of less than 2048 bits are now considered by many
experts to be cryptographically insecure (due to advances in experts to be cryptographically insecure (due to advances in
computing power), and should no longer be used to protect messages. computing power), and should no longer be used to protect messages.
Such keys were previously considered secure, so processing previously Such keys were previously considered secure, so processing previously
received signed and encrypted mail will often result in the use of received signed and encrypted mail will often result in the use of
weak keys. Implementations that wish to support previous versions of weak keys. Implementations that wish to support previous versions of
S/MIME or process old messages need to consider the security risks S/MIME or process old messages need to consider the security risks
that result from smaller key sizes (e.g., spoofed messages) versus that result from smaller key sizes (e.g., spoofed messages) versus
the costs of denial of service. If an implementation supports the costs of denial of service. If an implementation supports
skipping to change at page 43, line 11 skipping to change at page 43, line 15
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.
Visual indicators on messages may need to have the signature Visual indicators on messages may need to have the signature
validation code checked periodically if the indicator is supposed to validation code checked periodically if the indicator is supposed to
give information on the current status of a message. give information on the current status of a message.
Many people assume that the use of an authenticated encryption Many people assume that the use of an authenticated encryption
algorithm is all that is needed to be in a situtation where the algorithm is all that is needed to be in a situation where the sender
sender of the message will be authenticated. In almost all cases of the message will be authenticated. In almost all cases this is
this is not a correct statement. There are a number of preconditions not a correct statement. There are a number of preconditions that
that need to hold for an authenticated encryption algorithm to need to hold for an authenticated encryption algorithm to provide
provide this service: this service:
- The starting key must be bound to a single entity. The use of a - 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 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 sent by one of the entities that held the key but will not
identify a specific entity. identify a specific entity.
- The message must have exactly one sender and one recipient. - The message must have exactly one sender and one recipient.
Having more than one recipient would allow for the second Having more than one recipient would allow for the second
recipient to create a message that the first recipient would recipient to create a message that the first recipient would
believe is from the sender by stripping them as a recipient from believe is from the sender by stripping them as a recipient from
skipping to change at page 44, line 17 skipping to change at page 44, line 20
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 concern need to provide some type of padding so that the length of a concern need to provide some type of padding so that the length of
the message does not provide this information. 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. 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].
[CHARSETS] [CHARSETS]
"Character sets assigned by IANA.", "Character sets assigned by IANA.",
<http://www.iana.org/assignments/character-sets.>. <http://www.iana.org/assignments/character-sets.>.
[CMS] "Cryptograhic Message Syntax". [CMS] "Cryptographic Message Syntax".
This is the set of documents dealing with the This is the set of documents dealing with the
cryptographic message syntax and refers to [RFC5652] and cryptographic message syntax and refers to [RFC5652] and
[RFC5083]. [RFC5083].
[ESS] "Enhanced Security Services for S/MIME". [ESS] "Enhanced Security Services for S/MIME".
This is the set of documents dealing with enhanged This is the set of documents dealing with enhanced
security services and refers to [RFC2634] and [RFC5035]. security services and refers to [RFC2634] and [RFC5035].
[FIPS186-4] [FIPS186-4]
National Institute of Standards and Technology (NIST), National Institute of Standards and Technology (NIST),
"Digital Signature Standard (DSS)", Federal Information "Digital Signature Standard (DSS)", Federal Information
Processing Standards Publication 186-4, July 2013. Processing Standards Publication 186-4, July 2013.
[I-D.ietf-curdle-cms-ecdh-new-curves] [I-D.ietf-curdle-cms-ecdh-new-curves]
Housley, R., "Use of the Elliptic Curve Diffie-Hellamn Key Housley, R., "Use of the Elliptic Curve Diffie-Hellman Key
Agreement Algorithm with X25519 and X448 in the Agreement Algorithm with X25519 and X448 in the
Cryptographic Message Syntax (CMS)", draft-ietf-curdle- Cryptographic Message Syntax (CMS)", draft-ietf-curdle-
cms-ecdh-new-curves-02 (work in progress), March 2017. cms-ecdh-new-curves-10 (work in progress), August 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-03 4.0 Certificate Handling", draft-ietf-lamps-rfc5750-bis-04
(work in progress), March 2017. (work in progress), April 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
Multipart/Encrypted", RFC 1847, DOI 10.17487/RFC1847, Multipart/Encrypted", RFC 1847, DOI 10.17487/RFC1847,
October 1995, <http://www.rfc-editor.org/info/rfc1847>. October 1995, <https://www.rfc-editor.org/info/rfc1847>.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<http://www.rfc-editor.org/info/rfc2045>. <https://www.rfc-editor.org/info/rfc2045>.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
DOI 10.17487/RFC2046, November 1996, DOI 10.17487/RFC2046, November 1996,
<http://www.rfc-editor.org/info/rfc2046>. <https://www.rfc-editor.org/info/rfc2046>.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text", Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, DOI 10.17487/RFC2047, November 1996, RFC 2047, DOI 10.17487/RFC2047, November 1996,
<http://www.rfc-editor.org/info/rfc2047>. <https://www.rfc-editor.org/info/rfc2047>.
[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Five: Conformance Criteria and Extensions (MIME) Part Five: Conformance Criteria and
Examples", RFC 2049, DOI 10.17487/RFC2049, November 1996, Examples", RFC 2049, DOI 10.17487/RFC2049, November 1996,
<http://www.rfc-editor.org/info/rfc2049>. <https://www.rfc-editor.org/info/rfc2049>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2138] Rigney, C., Rubens, A., Simpson, W., and S. Willens, [RFC2138] Rigney, C., Rubens, A., Simpson, W., and S. Willens,
"Remote Authentication Dial In User Service (RADIUS)", "Remote Authentication Dial In User Service (RADIUS)",
RFC 2138, DOI 10.17487/RFC2138, April 1997, RFC 2138, DOI 10.17487/RFC2138, April 1997,
<http://www.rfc-editor.org/info/rfc2138>. <https://www.rfc-editor.org/info/rfc2138>.
[RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", [RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME",
RFC 2634, DOI 10.17487/RFC2634, June 1999, RFC 2634, DOI 10.17487/RFC2634, June 1999,
<http://www.rfc-editor.org/info/rfc2634>. <https://www.rfc-editor.org/info/rfc2634>.
[RFC3274] Gutmann, P., "Compressed Data Content Type for [RFC3274] Gutmann, P., "Compressed Data Content Type for
Cryptographic Message Syntax (CMS)", RFC 3274, Cryptographic Message Syntax (CMS)", RFC 3274,
DOI 10.17487/RFC3274, June 2002, DOI 10.17487/RFC3274, June 2002,
<http://www.rfc-editor.org/info/rfc3274>. <https://www.rfc-editor.org/info/rfc3274>.
[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3370, DOI 10.17487/RFC3370, August 2002, Algorithms", RFC 3370, DOI 10.17487/RFC3370, August 2002,
<http://www.rfc-editor.org/info/rfc3370>. <https://www.rfc-editor.org/info/rfc3370>.
[RFC3560] Housley, R., "Use of the RSAES-OAEP Key Transport [RFC3560] Housley, R., "Use of the RSAES-OAEP Key Transport
Algorithm in Cryptographic Message Syntax (CMS)", Algorithm in Cryptographic Message Syntax (CMS)",
RFC 3560, DOI 10.17487/RFC3560, July 2003, RFC 3560, DOI 10.17487/RFC3560, July 2003,
<http://www.rfc-editor.org/info/rfc3560>. <https://www.rfc-editor.org/info/rfc3560>.
[RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES)
Encryption Algorithm in Cryptographic Message Syntax Encryption Algorithm in Cryptographic Message Syntax
(CMS)", RFC 3565, DOI 10.17487/RFC3565, July 2003, (CMS)", RFC 3565, DOI 10.17487/RFC3565, July 2003,
<http://www.rfc-editor.org/info/rfc3565>. <https://www.rfc-editor.org/info/rfc3565>.
[RFC4056] Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in [RFC4056] Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in
Cryptographic Message Syntax (CMS)", RFC 4056, Cryptographic Message Syntax (CMS)", RFC 4056,
DOI 10.17487/RFC4056, June 2005, DOI 10.17487/RFC4056, June 2005,
<http://www.rfc-editor.org/info/rfc4056>. <https://www.rfc-editor.org/info/rfc4056>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<http://www.rfc-editor.org/info/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", RFC 4288, DOI 10.17487/RFC4288, Registration Procedures", RFC 4288, DOI 10.17487/RFC4288,
December 2005, <http://www.rfc-editor.org/info/rfc4288>. December 2005, <https://www.rfc-editor.org/info/rfc4288>.
[RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail [RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail
Extensions (MIME) Part Four: Registration Procedures", Extensions (MIME) Part Four: Registration Procedures",
BCP 13, RFC 4289, DOI 10.17487/RFC4289, December 2005, BCP 13, RFC 4289, DOI 10.17487/RFC4289, December 2005,
<http://www.rfc-editor.org/info/rfc4289>. <https://www.rfc-editor.org/info/rfc4289>.
[RFC5035] Schaad, J., "Enhanced Security Services (ESS) Update: [RFC5035] Schaad, J., "Enhanced Security Services (ESS) Update:
Adding CertID Algorithm Agility", RFC 5035, Adding CertID Algorithm Agility", RFC 5035,
DOI 10.17487/RFC5035, August 2007, DOI 10.17487/RFC5035, August 2007,
<http://www.rfc-editor.org/info/rfc5035>. <https://www.rfc-editor.org/info/rfc5035>.
[RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS)
Authenticated-Enveloped-Data Content Type", RFC 5083, Authenticated-Enveloped-Data Content Type", RFC 5083,
DOI 10.17487/RFC5083, November 2007, DOI 10.17487/RFC5083, November 2007,
<http://www.rfc-editor.org/info/rfc5083>. <https://www.rfc-editor.org/info/rfc5083>.
[RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated [RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated
Encryption in the Cryptographic Message Syntax (CMS)", Encryption in the Cryptographic Message Syntax (CMS)",
RFC 5084, DOI 10.17487/RFC5084, November 2007, RFC 5084, DOI 10.17487/RFC5084, November 2007,
<http://www.rfc-editor.org/info/rfc5084>. <https://www.rfc-editor.org/info/rfc5084>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009, RFC 5652, DOI 10.17487/RFC5652, September 2009,
<http://www.rfc-editor.org/info/rfc5652>. <https://www.rfc-editor.org/info/rfc5652>.
[RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve [RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve
Cryptography (ECC) Algorithms in Cryptographic Message Cryptography (ECC) Algorithms in Cryptographic Message
Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January
2010, <http://www.rfc-editor.org/info/rfc5753>. 2010, <https://www.rfc-editor.org/info/rfc5753>.
[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic
Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January
2010, <http://www.rfc-editor.org/info/rfc5754>. 2010, <https://www.rfc-editor.org/info/rfc5754>.
[SMIMEv4.0] [SMIMEv4.0]
"S/MIME version 4.0". "S/MIME version 4.0".
This group of documents represents S/MIME version 4.0. This group of documents represents S/MIME version 4.0.
This set of documents are [RFC2634], This set of documents are [RFC2634],
[I-D.ietf-lamps-rfc5750-bis], [[This Document]], [I-D.ietf-lamps-rfc5750-bis], [[This Document]],
[RFC5652], and [RFC5035]. [RFC5652], and [RFC5035].
[X.680] "Information Technology - Abstract Syntax Notation One [X.680] "Information Technology - Abstract Syntax Notation One
skipping to change at page 47, line 50 skipping to change at page 48, line 14
[X.681] "Information Technology - Abstract Syntax Notation One [X.681] "Information Technology - Abstract Syntax Notation One
(ASN.1): Information object specification", ITU-T X.681, (ASN.1): Information object specification", ITU-T X.681,
ISO/IEC 8824-2:2008, November 2008. ISO/IEC 8824-2:2008, November 2008.
[X.682] "Information Technology - Abstract Syntax Notation One [X.682] "Information Technology - Abstract Syntax Notation One
(ASN.1): Constraint specification", ITU-T X.682, ISO/ (ASN.1): Constraint specification", ITU-T X.682, ISO/
IEC 8824-3:2008, November 2008. IEC 8824-3:2008, November 2008.
[X.683] "Information Technology - Abstract Syntax Notation One [X.683] "Information Technology - Abstract Syntax Notation One
(ASN.1): Parameteriztion of ASN.1 specifications", (ASN.1): Parameterization of ASN.1 specifications",
ITU-T X.683, ISO/IEC 8824-4:2008, November 2008. ITU-T X.683, ISO/IEC 8824-4:2008, November 2008.
[X.690] "Information Technology - ASN.1 encoding rules: [X.690] "Information Technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules Encoding Rules (CER) and Distinguished Encoding Rules
(DER).", ITU-T X.690, ISO/IEC 8825-1:2002, July 2002. (DER).", ITU-T X.690, ISO/IEC 8825-1:2002, July 2002.
7.2. Informative References 7.2. Informative References
[FIPS186-2] [FIPS186-2]
National Institute of Standards and Technology (NIST), National Institute of Standards and Technology (NIST),
"Digital Signature Standard (DSS) [With Change Notice 1]", "Digital Signature Standard (DSS) [With Change Notice 1]",
Federal Information Processing Standards Federal Information Processing Standards
Publication 186-2, January 2000. Publication 186-2, January 2000.
[RFC2268] Rivest, R., "A Description of the RC2(r) Encryption [RFC2268] Rivest, R., "A Description of the RC2(r) Encryption
Algorithm", RFC 2268, DOI 10.17487/RFC2268, March 1998, Algorithm", RFC 2268, DOI 10.17487/RFC2268, March 1998,
<http://www.rfc-editor.org/info/rfc2268>. <https://www.rfc-editor.org/info/rfc2268>.
[RFC2311] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and [RFC2311] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and
L. Repka, "S/MIME Version 2 Message Specification", L. Repka, "S/MIME Version 2 Message Specification",
RFC 2311, DOI 10.17487/RFC2311, March 1998, RFC 2311, DOI 10.17487/RFC2311, March 1998,
<http://www.rfc-editor.org/info/rfc2311>. <https://www.rfc-editor.org/info/rfc2311>.
[RFC2312] Dusse, S., Hoffman, P., Ramsdell, B., and J. Weinstein, [RFC2312] Dusse, S., Hoffman, P., Ramsdell, B., and J. Weinstein,
"S/MIME Version 2 Certificate Handling", RFC 2312, "S/MIME Version 2 Certificate Handling", RFC 2312,
DOI 10.17487/RFC2312, March 1998, DOI 10.17487/RFC2312, March 1998,
<http://www.rfc-editor.org/info/rfc2312>. <https://www.rfc-editor.org/info/rfc2312>.
[RFC2313] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", [RFC2313] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5",
RFC 2313, DOI 10.17487/RFC2313, March 1998, RFC 2313, DOI 10.17487/RFC2313, March 1998,
<http://www.rfc-editor.org/info/rfc2313>. <https://www.rfc-editor.org/info/rfc2313>.
[RFC2314] Kaliski, B., "PKCS #10: Certification Request Syntax [RFC2314] Kaliski, B., "PKCS #10: Certification Request Syntax
Version 1.5", RFC 2314, DOI 10.17487/RFC2314, March 1998, Version 1.5", RFC 2314, DOI 10.17487/RFC2314, March 1998,
<http://www.rfc-editor.org/info/rfc2314>. <https://www.rfc-editor.org/info/rfc2314>.
[RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax
Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998, Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998,
<http://www.rfc-editor.org/info/rfc2315>. <https://www.rfc-editor.org/info/rfc2315>.
[RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630, [RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630,
DOI 10.17487/RFC2630, June 1999, DOI 10.17487/RFC2630, June 1999,
<http://www.rfc-editor.org/info/rfc2630>. <https://www.rfc-editor.org/info/rfc2630>.
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method",
RFC 2631, DOI 10.17487/RFC2631, June 1999, RFC 2631, DOI 10.17487/RFC2631, June 1999,
<http://www.rfc-editor.org/info/rfc2631>. <https://www.rfc-editor.org/info/rfc2631>.
[RFC2632] Ramsdell, B., Ed., "S/MIME Version 3 Certificate [RFC2632] Ramsdell, B., Ed., "S/MIME Version 3 Certificate
Handling", RFC 2632, DOI 10.17487/RFC2632, June 1999, Handling", RFC 2632, DOI 10.17487/RFC2632, June 1999,
<http://www.rfc-editor.org/info/rfc2632>. <https://www.rfc-editor.org/info/rfc2632>.
[RFC2633] Ramsdell, B., Ed., "S/MIME Version 3 Message [RFC2633] Ramsdell, B., Ed., "S/MIME Version 3 Message
Specification", RFC 2633, DOI 10.17487/RFC2633, June 1999, Specification", RFC 2633, DOI 10.17487/RFC2633, June 1999,
<http://www.rfc-editor.org/info/rfc2633>. <https://www.rfc-editor.org/info/rfc2633>.
[RFC2785] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup" [RFC2785] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup"
Attacks on the Diffie-Hellman Key Agreement Method for S/ Attacks on the Diffie-Hellman Key Agreement Method for
MIME", RFC 2785, DOI 10.17487/RFC2785, March 2000, S/MIME", RFC 2785, DOI 10.17487/RFC2785, March 2000,
<http://www.rfc-editor.org/info/rfc2785>. <https://www.rfc-editor.org/info/rfc2785>.
[RFC3218] Rescorla, E., "Preventing the Million Message Attack on [RFC3218] Rescorla, E., "Preventing the Million Message Attack on
Cryptographic Message Syntax", RFC 3218, Cryptographic Message Syntax", RFC 3218,
DOI 10.17487/RFC3218, January 2002, DOI 10.17487/RFC3218, January 2002,
<http://www.rfc-editor.org/info/rfc3218>. <https://www.rfc-editor.org/info/rfc3218>.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys", BCP 86, Public Keys Used For Exchanging Symmetric Keys", BCP 86,
RFC 3766, DOI 10.17487/RFC3766, April 2004, RFC 3766, DOI 10.17487/RFC3766, April 2004,
<http://www.rfc-editor.org/info/rfc3766>. <https://www.rfc-editor.org/info/rfc3766>.
[RFC3850] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail [RFC3850] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Certificate Handling", Extensions (S/MIME) Version 3.1 Certificate Handling",
RFC 3850, DOI 10.17487/RFC3850, July 2004, RFC 3850, DOI 10.17487/RFC3850, July 2004,
<http://www.rfc-editor.org/info/rfc3850>. <https://www.rfc-editor.org/info/rfc3850>.
[RFC3851] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail [RFC3851] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification", Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, DOI 10.17487/RFC3851, July 2004, RFC 3851, DOI 10.17487/RFC3851, July 2004,
<http://www.rfc-editor.org/info/rfc3851>. <https://www.rfc-editor.org/info/rfc3851>.
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",
RFC 3852, DOI 10.17487/RFC3852, July 2004, RFC 3852, DOI 10.17487/RFC3852, July 2004,
<http://www.rfc-editor.org/info/rfc3852>. <https://www.rfc-editor.org/info/rfc3852>.
[RFC4134] Hoffman, P., Ed., "Examples of S/MIME Messages", RFC 4134, [RFC4134] Hoffman, P., Ed., "Examples of S/MIME Messages", RFC 4134,
DOI 10.17487/RFC4134, July 2005, DOI 10.17487/RFC4134, July 2005,
<http://www.rfc-editor.org/info/rfc4134>. <https://www.rfc-editor.org/info/rfc4134>.
[RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic
Hashes in Internet Protocols", RFC 4270, Hashes in Internet Protocols", RFC 4270,
DOI 10.17487/RFC4270, November 2005, DOI 10.17487/RFC4270, November 2005,
<http://www.rfc-editor.org/info/rfc4270>. <https://www.rfc-editor.org/info/rfc4270>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<http://www.rfc-editor.org/info/rfc4949>. <https://www.rfc-editor.org/info/rfc4949>.
[RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet [RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Certificate Mail Extensions (S/MIME) Version 3.2 Certificate
Handling", RFC 5750, DOI 10.17487/RFC5750, January 2010, Handling", RFC 5750, DOI 10.17487/RFC5750, January 2010,
<http://www.rfc-editor.org/info/rfc5750>. <https://www.rfc-editor.org/info/rfc5750>.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, DOI 10.17487/RFC5751, January Specification", RFC 5751, DOI 10.17487/RFC5751, January
2010, <http://www.rfc-editor.org/info/rfc5751>. 2010, <https://www.rfc-editor.org/info/rfc5751>.
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations
for the MD5 Message-Digest and the HMAC-MD5 Algorithms", for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
RFC 6151, DOI 10.17487/RFC6151, March 2011, RFC 6151, DOI 10.17487/RFC6151, March 2011,
<http://www.rfc-editor.org/info/rfc6151>. <https://www.rfc-editor.org/info/rfc6151>.
[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
Considerations for the SHA-0 and SHA-1 Message-Digest Considerations for the SHA-0 and SHA-1 Message-Digest
Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
<http://www.rfc-editor.org/info/rfc6194>. <https://www.rfc-editor.org/info/rfc6194>.
[RFC6278] Herzog, J. and R. Khazan, "Use of Static-Static Elliptic [RFC6278] Herzog, J. and R. Khazan, "Use of Static-Static Elliptic
Curve Diffie-Hellman Key Agreement in Cryptographic Curve Diffie-Hellman Key Agreement in Cryptographic
Message Syntax", RFC 6278, DOI 10.17487/RFC6278, June Message Syntax", RFC 6278, DOI 10.17487/RFC6278, June
2011, <http://www.rfc-editor.org/info/rfc6278>. 2011, <https://www.rfc-editor.org/info/rfc6278>.
[RFC7114] Leiba, B., "Creation of a Registry for smime-type [RFC7114] Leiba, B., "Creation of a Registry for smime-type
Parameter Values", RFC 7114, DOI 10.17487/RFC7114, January Parameter Values", RFC 7114, DOI 10.17487/RFC7114, January
2014, <http://www.rfc-editor.org/info/rfc7114>. 2014, <https://www.rfc-editor.org/info/rfc7114>.
[RFC7905] Langley, A., Chang, W., Mavrogiannopoulos, N., [RFC7905] Langley, A., Chang, W., Mavrogiannopoulos, N.,
Strombergson, J., and S. Josefsson, "ChaCha20-Poly1305 Strombergson, J., and S. Josefsson, "ChaCha20-Poly1305
Cipher Suites for Transport Layer Security (TLS)", Cipher Suites for Transport Layer Security (TLS)",
RFC 7905, DOI 10.17487/RFC7905, June 2016, RFC 7905, DOI 10.17487/RFC7905, June 2016,
<http://www.rfc-editor.org/info/rfc7905>. <https://www.rfc-editor.org/info/rfc7905>.
[SMIMEv2] "S/MIME version v2". [SMIMEv2] "S/MIME version v2".
This group of documents represents S/MIME version 2. This This group of documents represents S/MIME version 2. This
set of documents are [RFC2311], [RFC2312], [RFC2313], set of documents are [RFC2311], [RFC2312], [RFC2313],
[RFC2314], and [RFC2315]. [RFC2314], and [RFC2315].
[SMIMEv3] "S/MIME version 3". [SMIMEv3] "S/MIME version 3".
This group of documents represents S/MIME version 3. This This group of documents represents S/MIME version 3. This
skipping to change at page 54, line 5 skipping to change at page 54, line 10
This appendix contains a number of references to documents that have This appendix contains a number of references to documents that have
been obsoleted or replaced, this is intentional as frequently the been obsoleted or replaced, this is intentional as frequently the
updated documents do not have the same information in them. updated documents do not have the same information in them.
B.1. DigestAlgorithmIdentifier B.1. DigestAlgorithmIdentifier
The following algorithms have been called our for some level of The following algorithms have been called our for some level of
support by previous S/MIME specifications: support by previous S/MIME specifications:
- SHA-1 was dropped in [SMIMEv4.0]. SHA-1 is no longer considerd to - SHA-1 was dropped in [SMIMEv4.0]. SHA-1 is no longer considered
be secure as it is no longer collision-resistant. The IETF 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 statement on SHA-1 can be found in [RFC6194] but it is out-of-date
relative to the most recient advances. relative to the most recent advances.
- MD5 was dropped in [SMIMEv4.0]. MD5 is no longer considered to be - MD5 was dropped in [SMIMEv4.0]. MD5 is no longer considered to be
secure as it is no longer collision-resistant. Details can be secure as it is no longer collision-resistant. Details can be
found in [RFC6151]. found in [RFC6151].
B.2. Signature Algorithms B.2. Signature Algorithms
There are a number of problems with validating signatures on There are a number of problems with validating signatures on
sufficently historic messages. For this reason it is strongly sufficiently historic messages. For this reason it is strongly
suggested that UAs treat these signatures differently from those on suggested that UAs treat these signatures differently from those on
current messages. These problems include: current messages. These problems include:
- CAs are not required to keep certificates on a CRL beyond one - CAs are not required to keep certificates on a CRL beyond one
update after a certificate has expired. This means that unless update after a certificate has expired. This means that unless
CRLs are cached as part of the message it is not always possible CRLs are cached as part of the message it is not always possible
to check if a certificate has been revoked. The same problems to check if a certificate has been revoked. The same problems
exist with OCSP responses as they may be based on a CRL rather exist with OCSP responses as they may be based on a CRL rather
than on the certificate database. than on the certificate database.
skipping to change at page 54, line 45 skipping to change at page 54, line 50
messages) versus the costs of denial of service. messages) versus the costs of denial of service.
[SMIMEv3.1] set the lower limit on suggested key sizes for [SMIMEv3.1] set the lower limit on suggested key sizes for
creating and validation at 1024 bits. Prior to that the lower creating and validation at 1024 bits. Prior to that the lower
bound on key sizes was 512 bits. bound on key sizes was 512 bits.
- Hash functions used to validate signatures on historic messages - Hash functions used to validate signatures on historic messages
may longer be considered to be secure. (See below.) While there may longer be considered to be secure. (See below.) While there
are not currently any known practical pre-image or second pre- are not currently any known practical pre-image or second pre-
image attacks against MD5 or SHA-1, the fact they are no longer image attacks against MD5 or SHA-1, the fact they are no longer
considered to be collision resistent the security levels of the considered to be collision resistant the security levels of the
signatures are generally considered suspect. 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 previous two issues apply to the certificates used to validate
the binding of the public key to the identity that signed the the binding of the public key to the identity that signed the
message as well. message as well.
The following algorithms have been called out for some level of The following algorithms have been called out for some level of
support by previous S/MIME specifications: support by previous S/MIME specifications:
- RSA with MD5 was dropped in [SMIMEv4.0]. MD5 is no longer - RSA with MD5 was dropped in [SMIMEv4.0]. MD5 is no longer
considered to be secure as it is no longer collision-resistant. considered to be secure as it is no longer collision-resistant.
Details can be found in [RFC6151]. Details can be found in [RFC6151].
- RSA and DSA with SHA-1 were dropped in [SMIMEv4.0]. SHA-1 is no - 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- longer considered to be secure as it is no longer collision-
resistant. The IETF statment on SHA-1 can be found in [RFC6194] resistant. The IETF statement on SHA-1 can be found in [RFC6194]
but it is out-of-date relative to the most recent advances. but it is out-of-date relative to the most recent advances.
- DSA with SHA-256 was dropped in [SMIMEv4.0]. DSA has been - DSA with SHA-256 was dropped in [SMIMEv4.0]. DSA has been
replaced by elliptic curve versions. replaced by elliptic curve versions.
As requirements for manditory to implement has changed over time, As requirements for mandatory to implement has changed over time,
some issues have been created that can cause interopatability some issues have been created that can cause interoperability
problems: problems:
- S/MIME v2 clients are only required to verify digital signatures - S/MIME v2 clients are only required to verify digital signatures
using the rsaEncryption algorithm with SHA-1 or MD5, and might not using the rsaEncryption algorithm with SHA-1 or MD5, and might not
implement id-dsa-with-sha1 or id-dsa at all. implement id-dsa-with-sha1 or id-dsa at all.
- S/MIME v3 clients might only implement signing or signature - S/MIME v3 clients might only implement signing or signature
verification using id-dsa-with-sha1, and might also use id-dsa as verification using id-dsa-with-sha1, and might also use id-dsa as
an AlgorithmIdentifier in this field. an AlgorithmIdentifier in this field.
- Note that S/MIME v3.1 clients support verifying id-dsa-with-sha1 - Note that S/MIME v3.1 clients support verifying id-dsa-with-sha1
and rsaEncryption and might not implement sha256withRSAEncryption. and rsaEncryption and might not implement sha256withRSAEncryption.
NOTE: Receiving clients SHOULD recognize id-dsa as equivalent to id- NOTE: Receiving clients SHOULD recognize id-dsa as equivalent to id-
dsa-with-sha1, and sending clients MUST use id-dsa-with-sha1 if using dsa-with-sha1.
that algorithm.
For 512-bit RSA with SHA-1 see [RFC3370] and [FIPS186-2] without 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 Change Notice 1, for 512-bit RSA with SHA-256 see [RFC5754] and
[FIPS186-2] without Change Notice 1, and for 1024-bit through [FIPS186-2] without Change Notice 1, and for 1024-bit through
2048-bit RSA with SHA-256 see [RFC5754] and [FIPS186-2] with Change 2048-bit RSA with SHA-256 see [RFC5754] and [FIPS186-2] with Change
Notice 1. The first reference provides the signature algorithm's Notice 1. 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 512-bit DSA with SHA-1 see [RFC3370] and [FIPS186-2] without For 512-bit DSA with SHA-1 see [RFC3370] and [FIPS186-2] without
 End of changes. 104 change blocks. 
162 lines changed or deleted 181 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/