draft-ietf-smime-3851bis-08.txt   draft-ietf-smime-3851bis-09.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 October 2, 2008 Intended Status: Standard Track April 6, 2009
Obsoletes: 3851 (when approved) Obsoletes: 3851 (when approved)
Expires: April 2, 2009 Expires: October 6, 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-08.txt draft-ietf-smime-3851bis-09.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79. This document may contain material
have been or will be disclosed, and any of which he or she becomes from IETF Documents or IETF Contributions published or made publicly
aware will be disclosed, in accordance with Section 6 of BCP 79. available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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."
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 April 2, 2008. This Internet-Draft will expire on October 6, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
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,
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 3851. reduce data size. This document obsoletes RFC 3851.
Discussion Discussion
This draft is being discussed on the 'ietf-smime' mailing list. To This draft is being discussed on the 'ietf-smime' mailing list. To
subscribe, send a message to ietf-smime-request@imc.org with the subscribe, send a message to ietf-smime-request@imc.org with the
single word subscribe in the body of the message. There is a Web site single word subscribe in the body of the message. There is a Web site
for the mailing list at <http://www.imc.org/ietf-smime/>. for the mailing list at <http://www.imc.org/ietf-smime/>.
skipping to change at page 2, line 18 skipping to change at page 2, line 35
Discussion Discussion
This draft is being discussed on the 'ietf-smime' mailing list. To This draft is being discussed on the 'ietf-smime' mailing list. To
subscribe, send a message to ietf-smime-request@imc.org with the subscribe, send a message to ietf-smime-request@imc.org with the
single word subscribe in the body of the message. There is a Web site single word subscribe in the body of the message. There is a Web site
for the mailing list at <http://www.imc.org/ietf-smime/>. for the mailing list at <http://www.imc.org/ietf-smime/>.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
1.1. Specification Overview....................................3 1.1. Specification Overview....................................4
1.2. Definitions...............................................4 1.2. Definitions...............................................5
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.................................7
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...........................................10 2.4. General Syntax...........................................10
2.5. Attributes and the SignerInfo Type.......................11 2.5. Attributes and the SignerInfo Type.......................11
2.6. SignerIdentifier SignerInfo Type.........................15 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..............................................18 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.......................25
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 a 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................31
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.....................................33 4.2. Signature Generation.....................................33
4.3. Signature Verification...................................33 4.3. Signature Verification...................................33
4.4. Encryption...............................................33 4.4. Encryption...............................................34
4.5. Decryption...............................................33 4.5. Decryption...............................................34
5. IANA Considerations...........................................34 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...................................41
Appendix A. ASN.1 Module.........................................42 Appendix A. ASN.1 Module.........................................43
Appendix B. Moving S/MIME v2 Message Specification to Appendix B. Moving S/MIME v2 Message Specification to Historic
Historic Status......................................44 Status...............................................45
Appendix C. Acknowledgments......................................45
Authors' Addresses...............................................45
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 6, line 7 skipping to change at page 6, line 24
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 ought to attempt to have the greatest
interoperability possible with agents for prior versions of S/MIME. interoperability possible with agents for prior versions of S/MIME.
S/MIME version 2 is described in RFC 2311 through RFC 2315 inclusive S/MIME version 2 is described in RFC 2311 through RFC 2315 inclusive
[SMIMEv2], S/MIME version 3 is described in RFC 2630 through RFC 2634 [SMIMEv2], S/MIME version 3 is described in RFC 2630 through RFC 2634
inclusive and RFC 5035[SMIMEv3], and S/MIME version 3.1 is described inclusive and RFC 5035[SMIMEv3], and S/MIME version 3.1 is described
in RFC 3850, RFC 3851, RFC 3852, RFC 2634, RFC 4853, and RFC 5035 in RFC 3850, RFC 3851, RFC 3852, RFC 2634, RFC 4853, and RFC 5035
[SMIMEv3.1]. RFC 2311 also has historical information about the [SMIMEv3.1]. RFC 2311 also has historical information about the
development of 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
skipping to change at page 7, line 19 skipping to change at page 7, line 37
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
as SHOULD+. Also added note about what S/MIME v3.1 clients support. as SHOULD+. Also added note about what S/MIME v3.1 clients support.
Sec 2.3 (key encryption): DH changed to SHOULD- and RSA-OAEP added as Sec 2.3 (key encryption): DH changed to SHOULD- and RSA-OAEP added as
SHOULD+. SHOULD+. Elaborated requirements for key wrap algorithm.
Sec 2.5.1: Added requirement that receiving agents MUST support both Sec 2.5.1: Added requirement that receiving agents MUST support both
GeneralizedTime and UTCTime. GeneralizedTime and UTCTime.
Sec 2.5.2: Replaced reference "sha1WithRSAEncrption" with Sec 2.5.2: Replaced reference "sha1WithRSAEncryption" with
"sha256WithRSAEncryption", "DES-3EDE-CBC" with "AES-128 CBC", and "sha256WithRSAEncryption", "DES-3EDE-CBC" with "AES-128 CBC", and
deleted the RC5 example. deleted the RC5 example.
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.1.1: Removed text about MIME character sets.
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 3.4.3.2: Replace micalg parameter for SHA-1 with sha-1.
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.
Sec 6: Updated Security Considerations. Sec 6: Updated Security Considerations.
skipping to change at page 9, line 41 skipping to change at page 10, line 5
Receiving and sending agents: Receiving and sending agents:
- MUST support RSA Encryption, as specified in [CMSALG] - MUST support RSA Encryption, as specified in [CMSALG]
- SHOULD+ support RSA-OAEP, as specified in [RSAOAEP] - SHOULD+ support RSA-OAEP, as specified in [RSAOAEP]
- SHOULD- support DH ephemeral-static mode, as specified - SHOULD- support DH ephemeral-static mode, as specified
in [CMSALG]. in [CMSALG].
When DH ephemeral-static is used, a key wrap algorithm is also
specified in the KeyEncryptionAlgorithmIdentifier [CMS]. The
underlying encryption functions for the key wrap and content
encryption algorithm ([CMSALG] and [CMSAES]) and the key sizes for
the two algorithms MUST be the same (e.g., AES 128 key wrap algorithm
with AES 128 content encryption algorithm). As AES 128 CBC is the
mandatory to implement content encryption algorithm thus, when DH
ephemeral-static is supported, AES-128 key wrap algorithm MUST also
be supported.
Note that S/MIME v3.1 clients might only implement key encryption and Note that S/MIME v3.1 clients might only implement key encryption and
decryption using the rsaEncryption algorithm. Note that S/MIME v3 decryption using the rsaEncryption algorithm. Note that S/MIME v3
clients might only implement key encryption and decryption using the clients might only implement key encryption and decryption using the
Diffie-Hellman algorithm. Also note that S/MIME v2 clients are only Diffie-Hellman algorithm. Also note that S/MIME v2 clients are only
capable of decrypting content-encryption keys using the rsaEncryption capable of decrypting content-encryption keys using the rsaEncryption
algorithm. algorithm.
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,
skipping to change at page 19, line 47 skipping to change at page 20, line 15
environment which can be considered their canonical representation. environment which can be considered their canonical representation.
In general, canonicalization will be performed by the non-security In general, canonicalization will be performed by the non-security
part of the sending agent rather than the S/MIME implementation. part of the sending agent rather than the S/MIME implementation.
The most common and important canonicalization is for text, which is The most common and important canonicalization is for text, which is
often represented differently in different environments. MIME often represented differently in different environments. MIME
entities of major type "text" MUST have both their line endings and entities of major type "text" MUST have both their line endings and
character set canonicalized. The line ending MUST be the pair of character set canonicalized. The line ending MUST be the pair of
characters <CR><LF>, and the charset SHOULD be a registered charset characters <CR><LF>, and the charset SHOULD be a registered charset
[CHARSETS]. The details of the canonicalization are specified in [CHARSETS]. The details of the canonicalization are specified in
[MIME-SPEC]. The chosen charset SHOULD be named in the charset [MIME-SPEC].
parameter so that the receiving agent can unambiguously determine the
charset used.
Note that some charsets such as ISO-2022 have multiple Note that some charsets such as ISO-2022 have multiple
representations for the same characters. When preparing such text representations for the same characters. When preparing such text
for signing, the canonical representation specified for the charset for signing, the canonical representation specified for the charset
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
skipping to change at page 28, line 16 skipping to change at page 28, line 31
signature is being verified. The value of the micalg parameter is signature is being verified. The value of the micalg parameter is
dependent on the message digest algorithm(s) used in the calculation dependent on the message digest algorithm(s) used in the calculation
of the Message Integrity Check. If multiple message digest of the Message Integrity Check. If multiple message digest
algorithms are used they MUST be separated by commas per [MIME- algorithms are used they MUST be separated by commas per [MIME-
SECURE]. The values to be placed in the micalg parameter SHOULD be SECURE]. The values to be placed in the micalg parameter SHOULD be
from the following: from the following:
Algorithm Value used Algorithm Value used
MD5 md5 MD5 md5
SHA-1 sha1 SHA-1 sha-1
SHA-224 sha224 SHA-224 sha-224
SHA-256 sha256 SHA-256 sha-256
SHA-384 sha384 SHA-384 sha-384
SHA-512 sha512 SHA-512 sha-512
Any other (defined separately in algorithm profile or "unknown" Any other (defined separately in algorithm profile or "unknown"
if not defined) if not defined)
(Historical note: some early implementations of S/MIME emitted and (Historical note: some early implementations of S/MIME emitted and
expected "rsa-md5" and "rsa-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. parameter value that they do not recognize. Future names for this
parameter will be consistent with the IANA "Hash Function Textual
The SHA-224, SHA-384, and SHA-512 algorithms [FIPS180-3] are not Names" registry.
currently recommended in S/MIME, and are included here for
completeness.
3.4.3.3. Sample multipart/signed Message 3.4.3.3. Sample multipart/signed Message
Content-Type: multipart/signed; Content-Type: multipart/signed;
protocol="application/pkcs7-signature"; protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42 micalg=sha1; boundary=boundary42
--boundary42 --boundary42
Content-Type: text/plain Content-Type: text/plain
This is a clear-signed message. This is a clear-signed message.
--boundary42 --boundary42
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
skipping to change at page 33, line 10 skipping to change at page 33, line 22
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. the signature algorithm's definition.
For 512-2048-bit RSA-PSS with SHA-256 see [RSAPSS]. 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) key size <= 1023 : SHOULD NOT (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 <= 1023 : MAY (see Security Considerations) key size <= 1023 : SHOULD NOT (see Security Considerations)
1024 = key size : SHOULD- (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) key size <= 1023 : MAY (see Security Considerations)
1023 <= 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 <= 1023 : MAY (see Security Considerations) key size <= 1023 : MAY (see Security Considerations)
1024 = key size : SHOULD- (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) key size <= 1023 : SHOULD NOT (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 <= 1023 : MAY (see Security Considerations) key size <= 1023 : SHOULD NOT (see Security Considerations)
1024 = key size : SHOULD- (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) key size <= 1023 : MAY (see Security Considerations)
1024 <= 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 <= 1023 : MAY (see Security Considerations) key size <= 1023 : MAY (see Security Considerations)
1024 = key size : SHOULD- (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
skipping to change at page 34, line 36 skipping to change at page 35, line 4
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.
5.1. Media Type for application/pkcs7-mime 5.1. Media Type for application/pkcs7-mime
Type name: application Type name: application
Subtype Name: pkcs7-mime Subtype Name: pkcs7-mime
Required Parameters: NONE Required Parameters: NONE
Optional Parameters: smime-type/signed-data Optional Parameters: smime-type/signed-data
smime-type/enveloped-data smime-type/enveloped-data
smime-type/compressed-data smime-type/compressed-data
smime-type/certs-only smime-type/certs-only
name
Encoding Considerations: See Section 3 of this document Encoding Considerations: See Section 3 of this document
Security Considerations: See Section 6 of this document Security Considerations: See Section 6 of this document
Interoperability Considerations: See Sections 1-6 of this document Interoperability Considerations: See Sections 1-6 of this document
Published Specification: RFC 2311, RFC 2633, and this document Published Specification: RFC 2311, RFC 2633, and this document
Applications that use this media type: Security applications Applications that use this media type: Security applications
skipping to change at page 36, line 22 skipping to change at page 36, line 36
- 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 key 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,
skipping to change at page 37, line 16 skipping to change at page 37, line 31
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
resource management system to prevent such attacks. resource management system to prevent such attacks.
Today, 512-bit RSA, DSA, and DH keys are considered by many experts
to be cryptographically insecure.
Using weak cryptography in S/MIME offers little actual security over Using weak cryptography in S/MIME offers little actual security over
sending plaintext. However, other features of S/MIME, such as the sending plaintext. However, other features of S/MIME, such as the
specification of AES and the ability to announce stronger specification of AES and the ability to announce stronger
cryptographic capabilities to parties with whom you communicate, cryptographic capabilities to parties with whom you communicate,
allow senders to create messages that use strong encryption. Using allow senders to create messages that use strong encryption. Using
weak cryptography is never recommended unless the only alternative is weak cryptography is never recommended unless the only alternative is
no cryptography. When feasible, sending and receiving agents SHOULD no cryptography.
inform senders and recipients of the relative cryptographic strength
of messages. RSA and DSA keys of less than 1024 bits are now considered by many
experts to be cryptographically insecure (due to advances in
computing power), and should no longer be used to protect messages.
Such keys were previously considered secure, so processing previously
received signed and encrypted mail will often result in the use of
weak keys. Implementations that wish to support previous versions of
S/MIME or process old messages need to consider the security risks
that result from smaller key sizes (e.g., spoofed messages) versus
the costs of denial of service. If an implementation supports
verification of digital signatures generated with RSA and DSA keys of
less than 1024 bits, it MUST warn the user. Implementers should
consider providing different warnings for newly received messages and
previously stored messages. Server implementations (e.g., secure
mail list servers) where user warnings are not appropriate SHOULD
reject messages with weak signatures.
Implementers SHOULD be aware that multiple active key pairs can be Implementers SHOULD be aware that multiple active key pairs can be
associated with a single individual. For example, one key pair can associated with a single individual. For example, one key pair can
be used to support confidentiality, while a different key pair can be be used to support confidentiality, while a different key pair can be
used for digital signatures. used for digital signatures.
If a sending agent is sending the same message using different If a sending agent is sending the same message using different
strengths of cryptography, an attacker watching the communications strengths of cryptography, an attacker watching the communications
channel might be able to determine the contents of the strongly- channel might be able to determine the contents of the strongly-
encrypted message by decrypting the weakly-encrypted version. In encrypted message by decrypting the weakly-encrypted version. In
skipping to change at page 38, line 5 skipping to change at page 38, line 27
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 If an implementation is concerned about compliance with NIST key size
recommendations, then see [SP800-57]. recommendations, then see [SP800-57].
If messaging environments make use of the fact that a message is
signed to change the behavior of message processing (examples would
be running rules or UI display hints), without first verifying that
the message is actually signed and knowing the state of the
signature, can lead to incorrect handling of the message. Visual
indicators on messages may need to have the signature validation code
check periodically if the indicator is supposed to give information
on the current status of a message.
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-3850bis-
draft-ietf-smime-3850-bis-08.txt, work-in-progress. 09.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 4853, 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-08.txt, work in Message Syntax", draft-ietf-smime-sha2-11.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),
"Secure Hash Standard (SHS)", (draft) FIPS Publication
180-3, June 2007.
[FIPS186-2] 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-2, January 2000. [With Change Notice 1] 186-2, January 2000. [With Change Notice 1].
[FIPS186-3] National Institute of Standards and Technology (NIST), [FIPS186-3] National Institute of Standards and Technology (NIST),
FIPS Publication 186-3: Digital Signature Standard, FIPS Publication 186-3: Digital Signature Standard,
(draft) March 2006. (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
skipping to change at page 40, line 7 skipping to change at page 40, line 46
[RANDOM] Eastlake 3rd, D., Crocker, S., and J. Schiller, [RANDOM] Eastlake 3rd, D., Crocker, S., and J. Schiller,
"Randomness Requirements for Security", BCP 106, RFC "Randomness Requirements for Security", BCP 106, RFC
4086, June 2005. 4086, June 2005.
[RSAPSS] Schaad, J., "Use of RSASA-PSS Signature Algorithm in [RSAPSS] Schaad, J., "Use of RSASA-PSS Signature Algorithm in
Cryptographic Message Syntax (CMS)", RFC 4056, June Cryptographic Message Syntax (CMS)", RFC 4056, June
2005. 2005.
[RSAOAEP] Housley, R. "Use of the RSAES-OAEP Key Transport [RSAOAEP] Housley, R. "Use of the RSAES-OAEP Key Transport
Algorithm in the Cryptographic Message Syntax (CMS)", Algorithm in the Cryptographic Message Syntax (CMS)",
RFC 3560, July 2003.
[X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824- [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-
1:2002. Information Technology - Abstract Syntax 1:2002. Information Technology - Abstract Syntax
Notation One (ASN.1): Specification of basic Notation One (ASN.1): Specification of basic
notation. notation.
[X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825- [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-
1:2002. Information Technology - ASN.1 encoding 1:2002. Information Technology - ASN.1 encoding
rules: Specification of Basic Encoding Rules (BER), rules: Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and Distinguished Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER). Encoding Rules (DER).
skipping to change at page 42, line 30 skipping to change at page 43, line 30
IMPORTS IMPORTS
-- Cryptographic Message Syntax [CMS] -- Cryptographic Message Syntax [CMS]
SubjectKeyIdentifier, IssuerAndSerialNumber, SubjectKeyIdentifier, IssuerAndSerialNumber,
RecipientKeyIdentifier RecipientKeyIdentifier
FROM CryptographicMessageSyntax FROM CryptographicMessageSyntax
{ 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) cms-2001(14) }; pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2001(14) };
-- id-aa is the arc with all new authenticated and unauthenticated -- id-aa is the arc with all new authenticated and unauthenticated
-- attributes produced the by S/MIME Working Group -- attributes produced by the S/MIME Working Group
id-aa OBJECT IDENTIFIER ::= {iso(1) member-body(2) usa(840) id-aa OBJECT IDENTIFIER ::= {iso(1) member-body(2) usa(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) attributes(2)} rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) attributes(2)}
-- S/MIME Capabilities provides a method of broadcasting the -- S/MIME Capabilities provides a method of broadcasting the
-- symmetric capabilities understood. Algorithms SHOULD be ordered -- symmetric capabilities understood. Algorithms SHOULD be ordered
-- by preference and grouped by type -- by preference and grouped by type
smimeCapabilities OBJECT IDENTIFIER ::= {iso(1) member-body(2) smimeCapabilities OBJECT IDENTIFIER ::= {iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15} us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15}
skipping to change at page 43, line 13 skipping to change at page 44, line 13
-- preferred encryption certificate. -- preferred encryption certificate.
id-aa-encrypKeyPref OBJECT IDENTIFIER ::= {id-aa 11} id-aa-encrypKeyPref OBJECT IDENTIFIER ::= {id-aa 11}
SMIMEEncryptionKeyPreference ::= CHOICE { SMIMEEncryptionKeyPreference ::= CHOICE {
issuerAndSerialNumber [0] IssuerAndSerialNumber, issuerAndSerialNumber [0] IssuerAndSerialNumber,
receipentKeyId [1] RecipientKeyIdentifier, receipentKeyId [1] RecipientKeyIdentifier,
subjectAltKeyIdentifier [2] SubjectKeyIdentifier subjectAltKeyIdentifier [2] SubjectKeyIdentifier
} }
-- receipentKeyId is spelt incorrectly, but kept for historical
-- reasons.
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs9(9) 16 } rsadsi(113549) pkcs(1) pkcs9(9) 16 }
id-cap OBJECT IDENTIFIER ::= { id-smime 11 } id-cap OBJECT IDENTIFIER ::= { id-smime 11 }
-- The preferBinaryInside OID indicates an ability to receive -- The preferBinaryInside OID indicates an ability to receive
-- messages with binary encoding inside the CMS wrapper. -- messages with binary encoding inside the CMS wrapper.
-- The preferBinaryInside attribute's value field is ABSENT. -- The preferBinaryInside attribute's value field is ABSENT.
id-cap-preferBinaryInside OBJECT IDENTIFIER ::= { id-cap 1 } id-cap-preferBinaryInside OBJECT IDENTIFIER ::= { id-cap 1 }
-- The following list the OIDs to be used with S/MIME V3 -- The following list OIDs to be used with S/MIME V3
-- Signature Algorithms Not Found in [CMSALG], [CMS-SHA2], [RSAPSS], -- Signature Algorithms Not Found in [CMSALG], [CMS-SHA2], [RSAPSS],
-- and [RSAOAEP] -- and [RSAOAEP]
-- --
-- md2WithRSAEncryption OBJECT IDENTIFIER ::= -- md2WithRSAEncryption OBJECT IDENTIFIER ::=
-- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) -- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1)
-- 2} -- 2}
skipping to change at page 44, line 13 skipping to change at page 45, line 13
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 compatible with the S/MIME v2 Message Specification are backwards compatible with the S/MIME v2 Message Specification
[SMIMEv2], with the exception of the algorithms (dropped RC2/40 [SMIMEv2], with the exception of the algorithms (dropped RC2/40
requirement and added DSA and RSA-PSS requirements). Therefore, it is requirement and added DSA and RSA-PSS requirements). Therefore, it is
recommended that RFC 2311 [SMIMEv2] be moved to Historic status. recommended that RFC 2311 [SMIMEv2] be moved to Historic status.
Appendix C. Acknowledgements Appendix C. Acknowledgments
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
doomed to omission, and for that I apologize. In alphabetical order, doomed to omission, and for that I apologize. In alphabetical order,
the following people stand out in my mind due to the fact that they the following people stand out in my mind due to the fact that they
made direct contributions to this document. made direct contributions to this document.
Tony Capel, Piers Chivers, Dave Crocker, Bill Flanigan, Peter Tony Capel, Piers Chivers, Dave Crocker, Bill Flanigan, Peter
Gutmann, Alfred Hoenes, Paul Hoffman, Russ Housley, William Ottaway, Gutmann, Alfred Hoenes, Paul Hoffman, Russ Housley, William Ottaway,
John Pawling, and Jim Schaad. John Pawling, and Jim Schaad.
Author's Addresses Authors' Addresses
Blake Ramsdell Blake Ramsdell
Brute Squad Labs, Inc. Brute Squad Labs, Inc.
Email: blaker@gmail.com Email: blaker@gmail.com
Sean Turner Sean Turner
IECA, Inc. IECA, Inc.
3057 Nutley Street, Suite 106 3057 Nutley Street, Suite 106
Fairfax, VA 22031 Fairfax, VA 22031
USA USA
Email: turners@ieca.com Email: turners@ieca.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 51 change blocks. 
69 lines changed or deleted 117 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/