draft-ietf-smime-3851bis-07.txt   draft-ietf-smime-3851bis-08.txt 
S/MIME WG Blake Ramsdell, Brute Squad Labs S/MIME WG Blake Ramsdell, Brute Squad Labs
Internet Draft Sean Turner, IECA Internet Draft Sean Turner, IECA
Intended Status: Standard Track September 23, 2008 Intended Status: Standard Track October 2, 2008
Obsoletes: 3851 (when approved) Obsoletes: 3851 (when approved)
Expires: March 23, 2009 Expires: April 2, 2009
Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2
Message Specification Message Specification
draft-ietf-smime-3851bis-07.txt draft-ietf-smime-3851bis-08.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on March 23, 2008. This Internet-Draft will expire on April 2, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document defines Secure/Multipurpose Internet Mail Extensions This document defines Secure/Multipurpose Internet Mail Extensions
(S/MIME) version 3.2. S/MIME provides a consistent way to send and (S/MIME) version 3.2. 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,
skipping to change at page 2, line 28 skipping to change at page 2, line 28
1.1. Specification Overview....................................3 1.1. Specification Overview....................................3
1.2. Definitions...............................................4 1.2. Definitions...............................................4
1.3. Conventions used in this document.........................5 1.3. Conventions used in this document.........................5
1.4. Compatibility with Prior Practice of S/MIME...............6 1.4. Compatibility with Prior Practice of S/MIME...............6
1.5. Changes From S/MIME v3 to S/MIME v3.1.....................6 1.5. Changes From S/MIME v3 to S/MIME v3.1.....................6
1.6. Changes Since S/MIME v3.1.................................6 1.6. Changes Since S/MIME v3.1.................................6
2. CMS Options....................................................8 2. CMS Options....................................................8
2.1. DigestAlgorithmIdentifier.................................8 2.1. DigestAlgorithmIdentifier.................................8
2.2. SignatureAlgorithmIdentifier..............................8 2.2. SignatureAlgorithmIdentifier..............................8
2.3. KeyEncryptionAlgorithmIdentifier..........................9 2.3. KeyEncryptionAlgorithmIdentifier..........................9
2.4. General Syntax............................................9 2.4. General Syntax...........................................10
2.5. Attributes and the SignerInfo Type.......................10 2.5. Attributes and the SignerInfo Type.......................11
2.6. SignerIdentifier SignerInfo Type.........................14 2.6. SignerIdentifier SignerInfo Type.........................15
2.7. ContentEncryptionAlgorithmIdentifier.....................15 2.7. ContentEncryptionAlgorithmIdentifier.....................15
3. Creating S/MIME Messages......................................17 3. Creating S/MIME Messages......................................17
3.1. Preparing the MIME Entity for Signing, Enveloping or 3.1. Preparing the MIME Entity for Signing, Enveloping or
Compressing..............................................17 Compressing..............................................18
3.2. The application/pkcs7-mime Media Type....................22 3.2. The application/pkcs7-mime Media Type....................22
3.3. Creating an Enveloped-only Message.......................24 3.3. Creating an Enveloped-only Message.......................24
3.4. Creating a Signed-only Message...........................25 3.4. Creating a Signed-only Message...........................25
3.5. Creating an Compressed-only Message......................29 3.5. Creating an Compressed-only Message......................29
3.6. Multiple Operations......................................30 3.6. Multiple Operations......................................30
3.7. Creating a Certificate Management Message................30 3.7. Creating a Certificate Management Message................30
3.8. Registration Requests....................................31 3.8. Registration Requests....................................31
3.9. Identifying an S/MIME Message............................31 3.9. Identifying an S/MIME Message............................31
4. Certificate Processing........................................32 4. Certificate Processing........................................32
4.1. Key Pair Generation......................................32 4.1. Key Pair Generation......................................32
4.2. Signature Generation.....................................32 4.2. Signature Generation.....................................33
4.3. Signature Verification...................................32 4.3. Signature Verification...................................33
4.4. Encryption...............................................33 4.4. Encryption...............................................33
4.5. Decryption...............................................33 4.5. Decryption...............................................33
5. IANA Considerations...........................................33 5. IANA Considerations...........................................34
5.1. Media Type for application/pkcs7-mime....................34 5.1. Media Type for application/pkcs7-mime....................34
5.2. Media Type for application/pkcs7-signature...............35 5.2. Media Type for application/pkcs7-signature...............35
6. Security Considerations.......................................36 6. Security Considerations.......................................36
7. References....................................................38 7. References....................................................38
7.1. Normative References.....................................38 7.1. Normative References.....................................38
7.2. Informative References...................................40 7.2. Informative References...................................40
Appendix A. ASN.1 Module.........................................42 Appendix A. ASN.1 Module.........................................42
Appendix B. Moving S/MIME v2 Message Specification to Appendix B. Moving S/MIME v2 Message Specification to
Historic Status......................................44 Historic Status......................................44
Appendix C. Acknowledgements.....................................44
1. Introduction 1. Introduction
S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a
consistent way to send and receive secure MIME data. Based on the consistent way to send and receive secure MIME data. Based on the
popular Internet MIME standard, S/MIME provides the following popular Internet MIME standard, S/MIME provides the following
cryptographic security services for electronic messaging cryptographic security services for electronic messaging
applications: authentication, message integrity and non-repudiation applications: authentication, message integrity and non-repudiation
of origin (using digital signatures), and data confidentiality (using of origin (using digital signatures), and data confidentiality (using
encryption). As a supplementary service, S/MIME provides for message encryption). As a supplementary service, S/MIME provides for message
skipping to change at page 3, line 46 skipping to change at page 3, line 45
the encryption of FAX messages sent over the Internet. the encryption of FAX messages sent over the Internet.
1.1. Specification Overview 1.1. Specification Overview
This document describes a protocol for adding cryptographic signature This document describes a protocol for adding cryptographic signature
and encryption services to MIME data. The MIME standard [MIME-SPEC] and encryption services to MIME data. The MIME standard [MIME-SPEC]
provides a general structure for the content of Internet messages and provides a general structure for the content of Internet messages and
allows extensions for new content type based applications. allows extensions for new content type based applications.
This specification defines how to create a MIME body part that has This specification defines how to create a MIME body part that has
been cryptographically enhanced according to CMS [CMS], which is been cryptographically enhanced according to the Cryptographic
derived from PKCS #7 [PKCS-7]. This specification also defines the Message Syntax (CMS) RFC 3852 and RFC 4853 [CMS], which is derived
from PKCS #7 [PKCS-7]. This specification also defines the
application/pkcs7-mime media type that can be used to transport those application/pkcs7-mime media type that can be used to transport those
body parts. body parts.
This document also discusses how to use the multipart/signed media This document also discusses how to use the multipart/signed media
type defined in [MIME-SECURE] to transport S/MIME signed messages. type defined in [MIME-SECURE] to transport S/MIME signed messages.
multipart/signed is used in conjunction with the application/pkcs7- multipart/signed is used in conjunction with the application/pkcs7-
signature media type, which is used to transport a detached S/MIME signature media type, which is used to transport a detached S/MIME
signature. signature.
In order to create S/MIME messages, an S/MIME agent MUST follow the In order to create S/MIME messages, an S/MIME agent MUST follow the
skipping to change at page 5, line 42 skipping to change at page 5, line 42
"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 [MUSTSHOULD]. document are to be interpreted as described in [MUSTSHOULD].
We define some additional terms here: We define some additional terms here:
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 promoted at expect that a requirement marked as SHOULD+ will be promoted at
some future time to be a MUST. 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 a requirement marked as SHOULD- will be demoted to a MAY expect that a requirement marked as SHOULD- will be demoted to a
in a future version of this document. 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 future expect that this requirement will no longer be a MUST in a future
document. Although its status will be determined at a later document. Although its status will be determined at a later
time, it is reasonable to expect that if a future revision of a time, it is reasonable to expect that if a future revision of a
document alters the status of a MUST- requirement, it will remain document alters the status of a MUST- requirement, it will remain
at least a SHOULD or a SHOULD-. at least a SHOULD or a SHOULD-.
1.4. Compatibility with Prior Practice of S/MIME 1.4. Compatibility with Prior Practice of S/MIME
S/MIME version 3.2 agents SHOULD attempt to have the greatest S/MIME version 3.2 agents SHOULD 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 [SMIMEv3], and S/MIME version 3.1 is described in RFC 3850, inclusive and RFC 5035[SMIMEv3], and S/MIME version 3.1 is described
RFC 3851, RFC 3852, RFC 2634, RFC 4853, and RFC 5035 [SMIMEv3.1]. in RFC 3850, RFC 3851, RFC 3852, RFC 2634, RFC 4853, and RFC 5035
RFC 2311 also has historical information about the development of [SMIMEv3.1]. RFC 2311 also has historical information about the
S/MIME. development of S/MIME.
1.5. Changes From S/MIME v3 to S/MIME v3.1 1.5. Changes From S/MIME v3 to S/MIME v3.1
The RSA public key algorithm was changed to a MUST implement key The RSA public key algorithm was changed to a MUST implement key
wrapping algorithm, and the Diffie-Hellman algorithm changed to a wrapping algorithm, and the Diffie-Hellman algorithm changed to a
SHOULD implement. SHOULD implement.
The AES symmetric encryption algorithm has been included as a SHOULD The AES symmetric encryption algorithm has been included as a SHOULD
implement. implement.
skipping to change at page 6, line 46 skipping to change at page 6, line 46
has been added. has been added.
Use of the CompressedData CMS type is allowed, along with required Use of the CompressedData CMS type is allowed, along with required
media type and file extension additions. media type and file extension additions.
1.6. Changes Since S/MIME v3.1 1.6. Changes Since S/MIME v3.1
Editorial changes, e.g., replaced "MIME type" with "media type", Editorial changes, e.g., replaced "MIME type" with "media type",
content-type with Content-Type. content-type with Content-Type.
Moved "Conventions Used in This Document" to Section 1.2. Added Moved "Conventions Used in This Document" to Section 1.3. Added
definitions for SHOULD+, SHOULD-, and MUST-. definitions for SHOULD+, SHOULD-, and MUST-.
Sec 1.1 and Appendix A: Added references to RFCs for RSA-PSS, RSA- Sec 1.1 and Appendix A: Added references to RFCs for RSA-PSS, RSA-
OAEP, and SHA2 CMS Algorithms. Added CMS Multiple Signers OAEP, and SHA2 CMS Algorithms. Added CMS Multiple Signers
Clarification to CMS reference. Clarification to CMS reference.
Sec 1.3: Updated references to ASN.1 to X.680 and BER and DER to Sec 1.2: Updated references to ASN.1 to X.680 and BER and DER to
X.690. X.690.
Sec 1.4: Added references to S/MIME MSG 3.1 RFCs. Sec 1.4: Added references to S/MIME MSG 3.1 RFCs.
Sec 2.1 (digest algorithm): SHA-256 added as MUST, SHA-1 and MD5 made Sec 2.1 (digest algorithm): SHA-256 added as MUST, SHA-1 and MD5 made
SHOULD-. SHOULD-.
Sec 2.2 (signature algorithms): RSA with SHA-256 added as MUST, and Sec 2.2 (signature algorithms): RSA with SHA-256 added as MUST, and
DSA with SHA-256 added as SHOULD+, RSA with SHA-1, DSA with SHA-1, DSA with SHA-256 added as SHOULD+, RSA with SHA-1, DSA with SHA-1,
and RSA with MD5 changed to SHOULD-, and RSA-PSS with SHA-256 added and RSA with MD5 changed to SHOULD-, and RSA-PSS with SHA-256 added
skipping to change at page 7, line 38 skipping to change at page 7, line 38
Sec 2.5.2.1: Deleted entire section (discussed deprecated RC2). Sec 2.5.2.1: Deleted entire section (discussed deprecated RC2).
Sec 2.7, 2.7.1, Appendix A: references to RC2/40 removed. Sec 2.7, 2.7.1, Appendix A: references to RC2/40 removed.
Sec 2.7 (content encryption): AES-128 CBC added as MUST, AES-192 and Sec 2.7 (content encryption): AES-128 CBC added as MUST, AES-192 and
AES-256 CBC SHOULD+, tripleDES now SHOULD-. AES-256 CBC SHOULD+, tripleDES now SHOULD-.
Sec 2.7.1: Updated pointers from 2.7.2.1 through 2.7.2.4 to 2.7.1.1 Sec 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. to 2.7.1.2.
Sec 3.2.2: Replaced "encrypted" with "enveloped." Update OID example Sec 3.2.2: Replaced "encrypted" with "enveloped". Update OID example
to use AES-128 CBC oid. to use AES-128 CBC oid.
Sec 4: Updated reference to CERT v3.2. Sec 4: Updated reference to CERT v3.2.
Sec 4.1: Updated RSA and DSA key size discussion. Moved last four Sec 4.1: Updated RSA and DSA key size discussion. Moved last four
sentences to security considerations. Updated reference to randomness sentences to security considerations. Updated reference to randomness
requirements for security. requirements for security.
Sec 5: Added IANA registration templates to update media type Sec 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 8, line 32 skipping to change at page 8, line 32
Sending and receiving agents MUST support SHA-256 [CMS-SHA2] and Sending and receiving agents MUST support SHA-256 [CMS-SHA2] and
SHOULD- support SHA-1 [CMSALG]. Receiving agents SHOULD- support MD5 SHOULD- support SHA-1 [CMSALG]. Receiving agents SHOULD- support MD5
[CMSALG] for the purpose of providing backward compatibility with [CMSALG] for the purpose of providing backward compatibility with
MD5-digested S/MIME v2 SignedData objects. MD5-digested S/MIME v2 SignedData objects.
2.2. SignatureAlgorithmIdentifier 2.2. SignatureAlgorithmIdentifier
Receiving agents: Receiving agents:
- MUST support RSA with SHA-256, as specified in [CMS-SHA2] - MUST support RSA with SHA-256
- SHOULD+ support DSA with SHA-256, as specified in [CMS-SHA2] - SHOULD+ support DSA with SHA-256
- SHOULD+ support RSA-PSS with SHA-256, as specified in [RSAPSS] - SHOULD+ support RSA-PSS with SHA-256
- SHOULD- support RSA with SHA-1, as specified in [CMSALG] - SHOULD- support RSA with SHA-1
- SHOULD- support DSA with SHA-1, as specified in [CMSALG] - SHOULD- support DSA with SHA-1
- SHOULD- support RSA with MD5, as specified in [CMSALG]. - SHOULD- support RSA with MD5.
Sending agents: Sending agents:
- MUST support RSA with SHA-256, as specified in [CMS-SHA2] - MUST support RSA with SHA-256
- SHOULD+ support DSA with SHA-256, as specified in [CMS-SHA2] - SHOULD+ support DSA with SHA-256
- SHOULD+ support RSA-PSS with SHA-256, as specified in [RSAPSS] - SHOULD+ support RSA-PSS with SHA-256
- SHOULD- support RSA with SHA-1 or DSA with SHA-1, as specified in - SHOULD- support RSA with SHA-1 or DSA with SHA-1
[CMSALG]
- SHOULD- support RSA with MD5, as specified in [CMSALG]. - SHOULD- support RSA with MD5.
See section 4.1 for information on key size and algorithm references.
Note that S/MIME v3.1 clients support verifying id-dsa-with-sha1 and Note that S/MIME v3.1 clients support verifying id-dsa-with-sha1 and
rsaEncryption and might not implement sha256withRSAEncryption. Note rsaEncryption and might not implement sha256withRSAEncryption. Note
that S/MIME v3 clients might only implement signing or signature that S/MIME v3 clients might only implement signing or signature
verification using id-dsa-with-sha1, and might also use id-dsa as an verification using id-dsa-with-sha1, and might also use id-dsa as an
AlgorithmIdentifier in this field. Receiving clients SHOULD AlgorithmIdentifier in this field. Receiving clients SHOULD
recognize id-dsa as equivalent to id-dsa-with-sha1, and sending recognize id-dsa as equivalent to id-dsa-with-sha1, and sending
clients MUST use id-dsa-with-sha1 if using that algorithm. Also note clients MUST use id-dsa-with-sha1 if using that algorithm. Also note
that S/MIME v2 clients are only required to verify digital signatures that 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
skipping to change at page 11, line 18 skipping to change at page 11, line 26
- sMIMECapabilities (section 2.5.2 in this document) - sMIMECapabilities (section 2.5.2 in this document)
- sMIMEEncryptionKeyPreference (section 2.5.3 in this document) - sMIMEEncryptionKeyPreference (section 2.5.3 in this document)
- id-messageDigest (section 11.2 in [CMS]) - id-messageDigest (section 11.2 in [CMS])
- id-contentType (section 11.1 in [CMS]) - id-contentType (section 11.1 in [CMS])
Further, receiving agents SHOULD be able to handle zero or one Further, receiving agents SHOULD be able to handle zero or one
instance in the signingCertificate signed attribute, as defined in instance of the signingCertificate and signingCertificatev2 signed
section 5 of [ESS]. attributes, as defined in section 5 of RFC 2634 [ESS] and RFC 5035
[ESS].
Sending agents SHOULD generate one instance of the signingCertificate Sending agents SHOULD generate one instance of the signingCertificate
signed attribute in each SignerInfo structure. or signingCertificatev2 signed attribute in each SignerInfo
structure.
Additional attributes and values for these attributes might be Additional attributes and values for these attributes might be
defined in the future. Receiving agents SHOULD handle attributes or defined in the future. Receiving agents SHOULD handle attributes or
values that they do not recognize in a graceful manner. values that they do not recognize in a graceful manner.
Interactive sending agents that include signed attributes that are Interactive sending agents that include signed attributes that are
not listed here SHOULD display those attributes to the user, so that not listed here SHOULD display those attributes to the user, so that
the user is aware of all of the data being signed. the user is aware of all of the data being signed.
2.5.1. Signing-Time Attribute 2.5.1. Signing-Time Attribute
skipping to change at page 16, line 36 skipping to change at page 16, line 45
capability in the list (that is, the capability most preferred by the capability in the list (that is, the capability most preferred by the
intended recipient) that the sending agent knows how to encrypt. The intended recipient) that the sending agent knows how to encrypt. The
sending agent SHOULD use one of the capabilities in the list if the sending agent SHOULD use one of the capabilities in the list if the
agent reasonably expects the recipient to be able to decrypt the agent reasonably expects the recipient to be able to decrypt the
message. message.
2.7.1.2. Rule 2: Unknown Capabilities, Unknown Version of S/MIME 2.7.1.2. Rule 2: Unknown Capabilities, Unknown Version of S/MIME
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-128 because it is a stronger then the sending agent SHOULD use AES-128 because it is a stronger
algorithm and is required by S/MIME v3.2. If the sending agent algorithm and is required by S/MIME v3.2. If the sending agent
chooses not to use AES-128 in this step, it SHOULD use tripleDES. chooses not to use AES-128 in this step, it SHOULD use tripleDES.
2.7.2. Choosing Weak Encryption 2.7.2. Choosing Weak Encryption
All algorithms that use 40 bit keys are considered by many to be weak All algorithms that use 40 bit keys are considered by many to be weak
encryption. A sending agent that is controlled by a human SHOULD encryption. A sending agent that is controlled by a human SHOULD
allow a human sender to determine the risks of sending data using a allow a human sender to determine the risks of sending data using a
weak encryption algorithm before sending the data, and possibly allow weak encryption algorithm before sending the data, and possibly allow
skipping to change at page 29, line 4 skipping to change at page 29, line 8
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
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
7GhIGfHfYT64VQbnj756 7GhIGfHfYT64VQbnj756
--boundary42-- --boundary42--
The content that is digested (the first part of the multipart/signed) The content that is digested (the first part of the multipart/signed)
are the bytes: are the bytes:
43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 74 65 78 74 2f 70 6c 61 69 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 74 65 78 74 2f 70 6c 61 69
6e 0d 0a 0d 0a 54 68 69 73 20 69 73 20 61 20 63 6c 65 61 72 2d 73 69 6e 0d 0a 0d 0a 54 68 69 73 20 69 73 20 61 20 63 6c 65 61 72 2d 73 69
67 6e 65 64 20 6d 65 73 73 61 67 65 2e 0d 0a 67 6e 65 64 20 6d 65 73 73 61 67 65 2e 0d 0a
3.5. Creating an Compressed-only Message 3.5. 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.
Please note that versions of S/MIME prior to version 3.1 did not Please note that versions of S/MIME prior to version 3.1 did not
specify any use of CompressedData, and will not recognize it. The specify any use of CompressedData, and will not recognize it. The
use of a capability to indicate the ability to receive CompressedData use of a capability to indicate the ability to receive CompressedData
is described in [CMSCOMPR] and is the preferred method for is described in [CMSCOMPR] and is the preferred method for
compatibility. compatibility.
Step 1. The MIME entity to be compressed is prepared according Step 1. The MIME entity to be compressed is prepared according
to section 3.1. to section 3.1.
skipping to change at page 32, line 33 skipping to change at page 32, line 33
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 [RANDOM] and the private key MUST be deterministic random input [RANDOM] 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 512 An S/MIME user agent MUST NOT generate asymmetric keys less than 512
bits for use with the RSA or DSA signature algorithms. bits for use with the RSA or DSA signature algorithms.
For 512-bit RSA with SHA-1 see [CMSALG] and [FIPS186-2] without
Change Notice 1, for 512-bit RSA with SHA-256 see [CMS-SHA2] and
[FIPS186-2] without Change Notice 1, for 1024-bit through 2048-bit
RSA with SHA-256 see [CMS-SHA2] and [FIPS186-2] with Change Notice 1.
The first reference provides the signature algorithm's object
identifier and the second provides the signature algorithm's
definition.
For 512-bit DSA with SHA-1 see [CMSALG] and [FIPS186-2] without
Change Notice 1, for 512-bit DSA with SHA-256 see [CMS-SHA2] and
[FIPS186-2] without Change Notice 1, for 1024-bit DSA with SHA-1 see
[CMSALG] and [FIPS186-2] with Change Notice 1, for 1024-bit DSA with
SHA-256 see [CMS-SHA2] and [FIPS186-3]. The first reference provides
the signature algorithm's object identifier and the second provides
the signature algorithm's definition.
For 512-2048-bit RSA-PSS with SHA-256 see [RSAPSS].
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
signatures: signatures:
512 <= key size < 1024 : MAY (see Security Considerations) 512 <= key size < 1024 : MAY (see Security Considerations)
1024 <= key size <= 2048 : SHOULD (see Security Considerations) 1024 <= key size <= 2048 : SHOULD (see Security Considerations)
2048 < key size : MAY (see Security Considerations) 2048 < key size : MAY (see Security Considerations)
The following are the requirements for an S/MIME agent generated DSA The following are the requirements for an S/MIME agent generated DSA
signatures: signatures:
512 <= key size <= 1024 : SHOULD (see Security Considerations) 512 <= key size <= 1023 : MAY (see Security Considerations)
1024 = key size : SHOULD- (see Security Considerations)
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 signatures: signature verification of RSA signatures:
512 <= key size <= 2048 : MUST (see Security Considerations) 512 <= key size <= 2048 : MUST (see Security Considerations)
2048 < key size : MAY (see Security Considerations) 2048 < key size : MAY (see Security Considerations)
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 DSA signatures: signature verification of DSA signatures:
512 <= key size <= 1024 : SHOULD (see Security Considerations) 512 <= key size <= 1023 : MAY (see Security Considerations)
1024 = key size : SHOULD- (see Security Considerations)
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 algorithms: establishing keys for content encryption using the RSA algorithms:
512 <= key size < 1024 : MAY (see Security Considerations) 512 <= key size < 1024 : MAY (see Security Considerations)
1024 <= key size <= 2048 : SHOULD (see Security Considerations) 1024 <= key size <= 2048 : SHOULD (see Security Considerations)
2048 < key size : MAY (see Security Considerations) 2048 < key size : MAY (see Security Considerations)
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 DH algorithms: establishing keys for content encryption using the DH algorithms:
512 <= key size <= 1024 : SHOULD (see Security Considerations) 512 <= key size <= 1023 : MAY (see Security Considerations)
1024 = key size : SHOULD- (see Security Considerations)
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 algorithms: establishing keys for content decryption using the RSA algorithms:
512 <= key size <= 2048 : MUST (see Security Considerations) 512 <= key size <= 2048 : MUST (see Security Considerations)
2048 < key size : MAY (see Security Considerations) 2048 < key size : MAY (see Security Considerations)
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 DH algorithms: establishing keys for content decryption using the DH algorithms:
512 <= key size <= 1024 : SHOULD (see Security Considerations) 512 <= key size <= 1023 : MAY (see Security Considerations)
1024 = key size : SHOULD- (see Security Considerations)
5. IANA Considerations 5. IANA Considerations
The following is intended to provide sufficient information to update The following is intended to provide sufficient information to update
the media type registration for application/pkcs7-mime and the media type registration for application/pkcs7-mime and
application/pkcs7-signature to refer to this document as opposed to application/pkcs7-signature to refer to this document as opposed to
RFC 2311. RFC 2311.
Note that other documents can define additional MIME media types for Note that other documents can define additional MIME media types for
S/MIME. S/MIME.
skipping to change at page 36, line 19 skipping to change at page 36, line 19
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:
- The Million Message Attack described in RFC 3218 [MMA]. - The Million Message Attack described in RFC 3218 [MMA].
- The Diffie-Hellman "small-subgroup" attacks described in - The Diffie-Hellman "small-subgroup" attacks described in
RFC 2785 [DHSUB]. RFC 2785 [DHSUB].
- The attacks against hash algorithms described in - The attacks against hash algorithms described in
RFC 4270 [HASH-ATTACK] RFC 4270 [HASH-ATTACK].
This specification uses Public-Key Cryptography technologies. It is This specification uses Public-Key Cryptography technologies. It is
assumed that the private is protected to ensure that it is not assumed that the private is protected to ensure that it is not
accessed or altered by unauthorized parties. accessed or altered by unauthorized parties.
It is impossible for most people or software to estimate the value of It is impossible for most people or software to estimate the value of
a message's content. Further, it is impossible for most people or a message's content. Further, it is impossible for most people or
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 the RSA asymmetric key size in this
specification is based on the desire to provide 100 bits of security. specification is based on the desire to provide 100 bits of security.
The standards to offer the same level of security for DSA and DH are The standards to offer the same level of security for DSA and DH are
not yet available. In particular, [FIPS186-3] only defines DSA key not yet available. In particular, [FIPS186-2] without Change Notice
sizes up to 1024 bits. A revision to support larger key sizes is allowed DSA key sizes between 512 and 1024 bits and [FIPS186-2] with
being developed, and once it is available, implementors ought to Change Notice 1 only allowed DSA key sizes of 1024 bits. A revision
support DSA key sizes comparable to the RSA key sizes recommended in to support larger key sizes is being developed, and once it is
this specification. The key sizes that must be supported to conform available, implementors ought to support DSA key sizes comparable to
to this specification seem appropriate for the Internet based on the RSA key sizes recommended in this specification. The key sizes
[STRENGTH]. Of course, there are environments, such as financial and that must be supported to conform to this specification seem
medical system, that may select different key sizes. For this appropriate for the Internet based on [STRENGTH]. Of course, there
reason, an implementation MAY support key sizes beyond those are environments, such as financial and medical system, that may
recommended in this specification. select different key sizes. For this reason, an implementation MAY
support key sizes beyond those recommended in this specification.
Receiving agents that validate signatures and sending agents that 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
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 which would result in excessive send certificates with keys which would result in excessive
cryptographic processing, for example keys larger than those mandated cryptographic processing, for example keys larger than those mandated
in this specification, which could swamp the processing element. in this specification, which could swamp the processing element.
Agents which use such keys without first validating the certificate Agents which use such keys without first validating the certificate
to a trust anchor are advised to have some sort of cryptographic to a trust anchor are advised to have some sort of cryptographic
skipping to change at page 38, line 5 skipping to change at page 37, line 46
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 can go undetected if authentication is
not also used, which is the case when sending EnvelopedData without not also used, which is the case when sending EnvelopedData without
wrapping it in SignedData or enclosing SignedData within it. wrapping it in SignedData or enclosing SignedData within it.
If an implementation is concerned about compliance with NIST key size
recommendations, then see [SP800-57].
7. References 7. References
7.1. Normative References 7.1. Normative References
[CERT32] Ramsdell, B., and S. Turner, "S/MIME Version 3.2 [CERT32] Ramsdell, B., and S. Turner, "S/MIME Version 3.2
Certificate Handling", Certificate Handling",
draft-ietf-smime-3850-bis-6.txt, work-in-progress. draft-ietf-smime-3850-bis-08.txt, work-in-progress.
[CHARSETS] Character sets assigned by IANA. See [CHARSETS] Character sets assigned by IANA. See
http://www.iana.org/assignments/character-sets http://www.iana.org/assignments/character-sets
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
3852, July 2004. 3852, July 2004.
Housley, R., "Cryptographic Message Syntax (CMS) Housley, R., "Cryptographic Message Syntax (CMS)
Multiple Signer Clarification", RFC 4852, April 2007. Multiple Signer Clarification", RFC 4853, April 2007.
[CMSAES] Schaad, J., "Use of the Advanced Encryption Standard [CMSAES] Schaad, J., "Use of the Advanced Encryption Standard
(AES) Encryption Algorithm in Cryptographic Message (AES) Encryption Algorithm in Cryptographic Message
Syntax (CMS)", RFC 3565, July 2003. Syntax (CMS)", RFC 3565, July 2003.
[CMSALG] Housley, R., "Cryptographic Message Syntax (CMS) [CMSALG] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3370, August 2002. Algorithms", RFC 3370, August 2002.
[CMSCOMPR] Gutmann, P., "Compressed Data Content Type for [CMSCOMPR] Gutmann, P., "Compressed Data Content Type for
Cryptographic Message Syntax (CMS)", RFC 3274, June Cryptographic Message Syntax (CMS)", RFC 3274, June
2002. 2002.
[CMS-SHA2] Turner. S., "Using SHA2 Algorithms with Cryptographic [CMS-SHA2] Turner. S., "Using SHA2 Algorithms with Cryptographic
Message Syntax", draft-ietf-smime-sha2-07.txt, work in Message Syntax", draft-ietf-smime-sha2-08.txt, work in
progress. progress.
[CONTDISP] Troost, R., Dorner, S., and K. Moore, "Communicating [CONTDISP] Troost, R., Dorner, S., and K. Moore, "Communicating
Presentation Information in Internet Messages: The Presentation Information in Internet Messages: The
Content-Disposition Header Field", RFC 2183, August Content-Disposition Header Field", RFC 2183, August
1997. 1997.
[ESS] Hoffman, P., "Enhanced Security Services for S/MIME", [ESS] Hoffman, P., "Enhanced Security Services for S/MIME",
RFC 2634, June 1999. RFC 2634, June 1999.
Schaad, J., "ESS Update: Adding CertID Algorithm Schaad, J., "ESS Update: Adding CertID Algorithm
Agility", RFC 5035, August 2007. Agility", RFC 5035, August 2007.
[FIPS180-3] National Institute of Standards and Technology (NIST), [FIPS180-3] National Institute of Standards and Technology (NIST),
"Secure Hash Standard (SHS)", FIPS Publication 180-3, "Secure Hash Standard (SHS)", (draft) FIPS Publication
June 2007. 180-3, June 2007.
[FIPS186-3] National Institute of Standards and Technology (NIST), [FIPS186-2] National Institute of Standards and Technology (NIST),
"Digital Signature Standard (DSS)", FIPS Publication "Digital Signature Standard (DSS)", FIPS Publication
186-3, March 2006. 186-2, January 2000. [With Change Notice 1]
[FIPS186-3] National Institute of Standards and Technology (NIST),
FIPS Publication 186-3: Digital Signature Standard,
(draft) March 2006.
[MIME-SPEC] Freed, N. and N. Borenstein, "Multipurpose Internet [MIME-SPEC] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", RFC 2045, November 1996. Message Bodies", RFC 2045, November 1996.
Freed, N. and N. Borenstein, "Multipurpose Internet Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part Two: Media Types", RFC Mail Extensions (MIME) Part Two: Media Types", RFC
2046, November 1996. 2046, November 1996.
Moore, K., "MIME (Multipurpose Internet Mail Moore, K., "MIME (Multipurpose Internet Mail
skipping to change at page 41, line 41 skipping to change at page 41, line 44
Ramsdell, B., "S/MIME Version 3.1 Message Ramsdell, B., "S/MIME Version 3.1 Message
Specification", RFC 3851, July 2004. Specification", RFC 3851, July 2004.
Hoffman, P., "Enhanced Security Services for S/MIME", Hoffman, P., "Enhanced Security Services for S/MIME",
RFC 2634, June 1999. RFC 2634, June 1999.
Schaad, J., "ESS Update: Adding CertID Algorithm Schaad, J., "ESS Update: Adding CertID Algorithm
Agility", RFC 5035, August 2007. Agility", RFC 5035, August 2007.
[SP800-57] National Institute of Standards and Technology (NIST),
Special Publication 800-57: Recommendation for Key
Management, August 2005.
[STRENGTH] Orman, H., and P. Hoffman, "Determining Strengths For [STRENGTH] Orman, H., and P. Hoffman, "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys", BCP Public Keys Used For Exchanging Symmetric Keys", BCP
86, RFC 3766, April 2004. 86, RFC 3766, April 2004.
Appendix A. ASN.1 Module Appendix A. ASN.1 Module
NOTE: The ASN.1 module contained herein is unchanged from RFC 3851 NOTE: The ASN.1 module contained herein is unchanged from RFC 3851
[SMIMEv3.1] with the exception of a change to the prefersBinaryInside [SMIMEv3.1] with the exception of a change to the prefersBinaryInside
ASN.1 comment. This modules use the 1988 version of ASN.1. ASN.1 comment. This module uses the 1988 version of ASN.1.
SecureMimeMessageV3dot1 SecureMimeMessageV3dot1
{ iso(1) member-body(2) us(840) rsadsi(113549) { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) msg-v3dot1(21) } pkcs(1) pkcs-9(9) smime(16) modules(0) msg-v3dot1(21) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
skipping to change at page 44, line 8 skipping to change at page 44, line 8
-- value. -- value.
SMIMECapabilitiesParametersForRC2CBC ::= INTEGER SMIMECapabilitiesParametersForRC2CBC ::= INTEGER
-- (RC2 Key Length (number of bits)) -- (RC2 Key Length (number of bits))
END END
Appendix B. Moving S/MIME v2 Message Specification to Historic Status Appendix B. Moving S/MIME v2 Message Specification to Historic Status
The S/MIME v3 [SMIMEv3], v3.1 [SMIMEv3.1], and v3.2 (this document) The S/MIME v3 [SMIMEv3], v3.1 [SMIMEv3.1], and v3.2 (this document)
are backwards with the S/MIME v2 Message Specification [SMIMEv2], are backwards compatible with the S/MIME v2 Message Specification
with the exception of the algorithms (dropped RC2/40 requirement and [SMIMEv2], with the exception of the algorithms (dropped RC2/40
added DSA and RSA-PSS requirements). Therefore, it is recommended requirement and added DSA and RSA-PSS requirements). Therefore, it is
that RFC 2311 [SMIMEv2] be moved to Historic status. recommended that RFC 2311 [SMIMEv2] be moved to Historic status.
Appendix C. Acknowledgements Appendix C. Acknowledgements
Many thanks go out to the other authors of the S/MIME Version 2 Many thanks go out to the other authors of the S/MIME Version 2
Message Specification RFC: Steve Dusse, Paul Hoffman, Laurence Message Specification RFC: Steve Dusse, Paul Hoffman, Laurence
Lundblade and Lisa Repka. Without v2, there wouldn't be a v3, v3.1 or Lundblade and Lisa Repka. Without v2, there wouldn't be a v3, v3.1 or
v3.2. v3.2.
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
 End of changes. 50 change blocks. 
69 lines changed or deleted 106 lines changed or added

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