< draft-ietf-smime-3851bis-09.txt   draft-ietf-smime-3851bis-10.txt >
S/MIME WG Blake Ramsdell, Brute Squad Labs S/MIME WG B. Ramsdell
Internet Draft Sean Turner, IECA Internet Draft Brute Squad Labs
Intended Status: Standard Track April 6, 2009 Intended Status: Standard Track S. Turner
Obsoletes: 3851 (when approved) Obsoletes: 3851 (when approved) IECA
Expires: October 6, 2009 Expires: October 27, 2009 April 27, 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-09.txt draft-ietf-smime-3851bis-10.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 October 6, 2009. This Internet-Draft will expire on October 27, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 43 skipping to change at page 2, line 43
1. Introduction...................................................3 1. Introduction...................................................3
1.1. Specification Overview....................................4 1.1. Specification Overview....................................4
1.2. Definitions...............................................5 1.2. Definitions...............................................5
1.3. Conventions used in this document.........................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.................................7 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..............................9
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......................................18
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.......................25 3.3. Creating an Enveloped-only Message.......................25
3.4. Creating a Signed-only Message...........................25 3.4. Creating a Signed-only Message...........................26
3.5. Creating a 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................31 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............................32
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...............................................34 4.4. Encryption...............................................34
4.5. Decryption...............................................34 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....................35
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...................................41 7.2. Informative References...................................41
Appendix A. ASN.1 Module.........................................43 Appendix A. ASN.1 Module.........................................43
Appendix B. Moving S/MIME v2 Message Specification to Historic Appendix B. Moving S/MIME v2 Message Specification to Historic
Status...............................................45 Status...............................................45
Appendix C. Acknowledgments......................................45 Appendix C. Acknowledgments......................................45
Authors' Addresses...............................................45 Authors' Addresses...............................................45
skipping to change at page 7, line 19 skipping to change at page 7, line 19
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.3. 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 RSASSA-PSS,
OAEP, and SHA2 CMS Algorithms. Added CMS Multiple Signers RSAES-OAEP, and SHA2 CMS Algorithms. Added CMS Multiple Signers
Clarification to CMS reference. Clarification to CMS reference.
Sec 1.2: 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 RSASSA-PSS with SHA-256
as SHOULD+. Also added note about what S/MIME v3.1 clients support. added 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 RSAES-OAEP added
SHOULD+. Elaborated requirements for key wrap algorithm. as 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 "sha1WithRSAEncryption" 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.1.1: Removed text about MIME character sets.
Sec 3.2.2: Replaced "encrypted" with "enveloped". Update OID example Sec 3.2.2 and 3.6: Replaced "encrypted" with "enveloped". Update OID
to use AES-128 CBC oid. example to use AES-128 CBC oid.
Sec 3.4.3.2: Replace micalg parameter for SHA-1 with sha-1. 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
skipping to change at page 9, line 9 skipping to change at page 9, line 13
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 - MUST support RSA with SHA-256
- SHOULD+ support DSA with SHA-256 - SHOULD+ support DSA with SHA-256
- SHOULD+ support RSA-PSS with SHA-256 - SHOULD+ support RSASSA-PSS with SHA-256
- SHOULD- support RSA with SHA-1 - SHOULD- support RSA with SHA-1
- SHOULD- support DSA with SHA-1 - SHOULD- support DSA with SHA-1
- SHOULD- support RSA with MD5. - SHOULD- support RSA with MD5.
Sending agents: Sending agents:
- MUST support RSA with SHA-256 - MUST support RSA with SHA-256
- SHOULD+ support DSA with SHA-256 - SHOULD+ support DSA with SHA-256
- SHOULD+ support RSA-PSS with SHA-256 - SHOULD+ support RSASSA-PSS with SHA-256
- SHOULD- support RSA with SHA-1 or DSA with SHA-1 - SHOULD- support RSA with SHA-1 or DSA with SHA-1
- SHOULD- support RSA with MD5. - SHOULD- support RSA with MD5.
See section 4.1 for information on key size and algorithm references. 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
skipping to change at page 9, line 47 skipping to change at page 10, line 4
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
implement id-dsa-with-sha1 or id-dsa at all. implement id-dsa-with-sha1 or id-dsa at all.
2.3. KeyEncryptionAlgorithmIdentifier 2.3. KeyEncryptionAlgorithmIdentifier
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 RSAES-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 When DH ephemeral-static is used, a key wrap algorithm is also
specified in the KeyEncryptionAlgorithmIdentifier [CMS]. The specified in the KeyEncryptionAlgorithmIdentifier [CMS]. The
underlying encryption functions for the key wrap and content underlying encryption functions for the key wrap and content
encryption algorithm ([CMSALG] and [CMSAES]) and the key sizes for encryption algorithm ([CMSALG] and [CMSAES]) and the key sizes for
the two algorithms MUST be the same (e.g., AES 128 key wrap algorithm the two algorithms MUST be the same (e.g., AES-128 key wrap algorithm
with AES 128 content encryption algorithm). As AES 128 CBC is the with AES 128 content encryption algorithm). As AES 128 CBC is the
mandatory to implement content encryption algorithm thus, when DH mandatory to implement content encryption algorithm, the AES-128 key
ephemeral-static is supported, AES-128 key wrap algorithm MUST also wrap algorithm MUST also be supported when DH ephemeral-static is
be supported. used.
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
skipping to change at page 11, line 43 skipping to change at page 11, line 46
- 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 of the signingCertificate and signingCertificatev2 signed instance of the signingCertificate and signingCertificatev2 signed
attributes, as defined in section 5 of RFC 2634 [ESS] and RFC 5035 attributes, as defined in section 5 of RFC 2634 [ESS] and section 3
[ESS]. of RFC 5035 [ESS].
Sending agents SHOULD generate one instance of the signingCertificate Sending agents SHOULD generate one instance of the signingCertificate
or signingCertificatev2 signed attribute in each SignerInfo or signingCertificatev2 signed attribute in each SignerInfo
structure. 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
skipping to change at page 24, line 33 skipping to change at page 24, line 42
signed-data SignedData id-data signed-data SignedData id-data
certs-only SignedData none certs-only SignedData none
compressed-data CompressedData id-data compressed-data CompressedData id-data
In order for consistency to be obtained with future specifications, In order for consistency to be obtained with future specifications,
the following guidelines SHOULD be followed when assigning a new the following guidelines SHOULD be followed when assigning a new
smime-type parameter. smime-type parameter.
1. If both signing and encryption can be applied to the content, 1. If both signing and encryption can be applied to the content,
then two values for smime-type SHOULD be assigned "signed-*" and then two values for smime-type SHOULD be assigned "signed-*" and
"encrypted-*". If one operation can be assigned then this can be "enveloped-*". If one operation can be assigned then this can be
omitted. Thus since "certs-only" can only be signed, "signed-" omitted. Thus since "certs-only" can only be signed, "signed-"
is omitted. is omitted.
2. A common string for a content OID SHOULD be assigned. We use 2. A common string for a content OID SHOULD be assigned. We use
"data" for the id-data content OID when MIME is the inner "data" for the id-data content OID when MIME is the inner
content. content.
3. If no common string is assigned, then the common string of 3. If no common string is assigned, then the common string of
"OID.<oid>" is recommended (for example, "OID.<oid>" is recommended (for example,
"OID.2.16.840.1.101.3.4.1.2" would be AES-128 CBC). "OID.2.16.840.1.101.3.4.1.2" would be AES-128 CBC).
It is explicitly intended that this field be a suitable hint for mail It is explicitly intended that this field be a suitable hint for mail
client applications to indicate whether a message is "signed" or client applications to indicate whether a message is "signed" or
"encrypted" without having to tunnel into the CMS payload. "enveloped" without having to tunnel into the CMS payload.
3.3. Creating an Enveloped-only Message 3.3. Creating an Enveloped-only Message
This section describes the format for enveloping a MIME entity This section describes the format for enveloping a MIME entity
without signing it. It is important to note that sending enveloped without signing it. It is important to note that sending enveloped
but not signed messages does not provide for data integrity. It is but not signed messages does not provide for data integrity. It is
possible to replace ciphertext in such a way that the processed possible to replace ciphertext in such a way that the processed
message will still be valid, but the meaning can be altered. message will still be valid, but the meaning can be altered.
Step 1. The MIME entity to be enveloped is prepared according to Step 1. The MIME entity to be enveloped is prepared according to
skipping to change at page 28, line 40 skipping to change at page 28, line 44
MD5 md5 MD5 md5
SHA-1 sha-1 SHA-1 sha-1
SHA-224 sha-224 SHA-224 sha-224
SHA-256 sha-256 SHA-256 sha-256
SHA-384 sha-384 SHA-384 sha-384
SHA-512 sha-512 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", "rsa-sha1", "and sha1" for the micalg parameter.) expected "rsa-md5", "rsa-sha1", and "sha1" for the micalg parameter.)
Receiving agents SHOULD be able to recover gracefully from a micalg Receiving agents SHOULD be able to recover gracefully from a micalg
parameter value that they do not recognize. Future names for this parameter value that they do not recognize. Future names for this
parameter will be consistent with the IANA "Hash Function Textual parameter will be consistent with the IANA "Hash Function Textual
Names" registry. Names" registry.
3.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
skipping to change at page 30, line 19 skipping to change at page 30, line 25
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7z Content-Disposition: attachment; filename=smime.p7z
rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6 rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
0GhIGfHfQbnj756YT64V 0GhIGfHfQbnj756YT64V
3.6. Multiple Operations 3.6. Multiple Operations
The signed-only, encrypted-only, and compressed-only MIME formats can The signed-only, enveloped-only, and compressed-only MIME formats can
be nested. This works because these formats are all MIME entities be nested. This works because these formats are all MIME entities
that encapsulate other MIME entities. that encapsulate other MIME entities.
An S/MIME implementation MUST be able to receive and process An S/MIME implementation MUST be able to receive and process
arbitrarily nested S/MIME within reasonable resource limits of the arbitrarily nested S/MIME within reasonable resource limits of the
recipient computer. recipient computer.
It is possible to apply any of the signing, encrypting, and It is possible to apply any of the signing, encrypting, and
compressing operations in any order. It is up to the implementer and compressing operations in any order. It is up to the implementer and
the user to choose. When signing first, the signatories are then the user to choose. When signing first, the signatories are then
skipping to change at page 33, line 15 skipping to change at page 33, line 24
definition. definition.
For 512-bit DSA with SHA-1 see [CMSALG] and [FIPS186-2] without 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 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 [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 [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 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 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 RSASSA-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:
key size <= 1023 : SHOULD NOT (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:
key size <= 1023 : SHOULD NOT (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:
key size <= 1023 : MAY (see Security Considerations) key size <= 1023 : MAY (see Security Considerations)
1023 <= key size <= 2048 : MUST (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 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:
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:
key size <= 1023 : SHOULD NOT (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:
key size <= 1023 : SHOULD NOT (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:
key size <= 1023 : MAY (see Security Considerations) key size <= 1023 : MAY (see Security Considerations)
1024 <= key size <= 2048 : MUST (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:
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
S/MIME. S/MIME.
skipping to change at page 36, line 43 skipping to change at page 37, line 4
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 key 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,
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 at least 100 bits of
The standards to offer the same level of security for DSA and DH are security. The standards to offer the same level of security for DSA
not yet available. In particular, [FIPS186-2] without Change Notice and DH are not yet available. In particular, [FIPS186-2] without
allowed DSA key sizes between 512 and 1024 bits and [FIPS186-2] with Change Notice allowed DSA key sizes between 512 and 1024 bits and
Change Notice 1 only allowed DSA key sizes of 1024 bits. A revision [FIPS186-2] with Change Notice 1 only allowed DSA key sizes of 1024
to support larger key sizes is being developed, and once it is bits. A revision to support larger key sizes is being developed, and
available, implementors ought to support DSA key sizes comparable to once it is available, implementors ought to support DSA key sizes
the RSA key sizes recommended in this specification. The key sizes comparable to the RSA key sizes recommended in this specification.
that must be supported to conform to this specification seem The key sizes that must be supported to conform to this specification
appropriate for the Internet based on [STRENGTH]. Of course, there seem appropriate for the Internet based on [STRENGTH]. Of course,
are environments, such as financial and medical system, that may there are environments, such as financial and medical system, that
select different key sizes. For this reason, an implementation MAY may select different key sizes. For this reason, an implementation
support key sizes beyond those recommended in this specification. 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 42 skipping to change at page 38, line 50
indicators on messages may need to have the signature validation code indicators on messages may need to have the signature validation code
check periodically if the indicator is supposed to give information check periodically if the indicator is supposed to give information
on the current status of a message. 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", draft-ietf-smime-3850bis- Certificate Handling", draft-ietf-smime-3850bis-
09.txt, work-in-progress. 10.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.
skipping to change at page 40, line 40 skipping to change at page 40, line 40
"Security Multiparts for MIME: Multipart/Signed and "Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted", RFC 1847, October 1995. Multipart/Encrypted", RFC 1847, October 1995.
[MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate [MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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 RSASSA-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. 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
skipping to change at page 45, line 10 skipping to change at page 45, line 10
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 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 RSASSA-PSS requirements). Therefore, it
recommended that RFC 2311 [SMIMEv2] be moved to Historic status. is recommended that RFC 2311 [SMIMEv2] be moved to Historic status.
Appendix C. Acknowledgments 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
skipping to change at page 45, line 33 skipping to change at page 45, line 33
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.
Authors' 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
 End of changes. 38 change blocks. 
61 lines changed or deleted 62 lines changed or added

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