draft-ietf-smime-3851bis-10.txt   draft-ietf-smime-3851bis-11.txt 
S/MIME WG B. Ramsdell S/MIME WG B. Ramsdell
Internet Draft Brute Squad Labs Internet Draft Brute Squad Labs
Intended Status: Standard Track S. Turner Intended Status: Standard Track S. Turner
Obsoletes: 3851 (when approved) IECA Obsoletes: 3851 (when approved) IECA
Expires: October 27, 2009 April 27, 2009 Expires: November 12, 2009 May 12, 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-10.txt draft-ietf-smime-3851bis-11.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 27, 2009. This Internet-Draft will expire on November 12, 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 34 skipping to change at page 2, line 34
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....................................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..............................9 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......................................18 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...........................26 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............................32 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....................35 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...................................41 7.2. Informative References................................. 40
Appendix A. ASN.1 Module.........................................43 Appendix A. ASN.1 Module....................................... 42
Appendix B. Moving S/MIME v2 Message Specification to Historic Appendix B. Moving S/MIME v2 Message Specification to Historic
Status...............................................45 Status............................................. 46
Appendix C. Acknowledgments......................................45 Appendix C. Acknowledgments.................................... 46
Authors' Addresses...............................................45 Authors' Addresses............................................. 46
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 10, line 7 skipping to change at page 10, line 7
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 RSAES-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] and [SP800-57].
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, the AES-128 key mandatory to implement content encryption algorithm, the AES-128 key
wrap algorithm MUST also be supported when DH ephemeral-static is wrap algorithm MUST also be supported when DH ephemeral-static is
used. used.
skipping to change at page 33, line 19 skipping to change at page 33, line 19
Change Notice 1, for 512-bit RSA with SHA-256 see [CMS-SHA2] and Change Notice 1, for 512-bit RSA with SHA-256 see [CMS-SHA2] and
[FIPS186-2] without Change Notice 1, for 1024-bit through 2048-bit [FIPS186-2] without Change Notice 1, for 1024-bit through 2048-bit
RSA with SHA-256 see [CMS-SHA2] and [FIPS186-2] with Change Notice 1. RSA with SHA-256 see [CMS-SHA2] and [FIPS186-2] with Change Notice 1.
The first reference provides the signature algorithm's object The first reference provides the signature algorithm's object
identifier and the second provides the signature algorithm's identifier and the second provides the signature algorithm's
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 and above
SHA-256 see [CMS-SHA2] and [FIPS186-3]. The first reference provides DSA with SHA-256 see [CMS-SHA2] and [FIPS186-3]. The first reference
the signature algorithm's object identifier and the second provides provides the signature algorithm's object identifier and the second
the signature algorithm's definition. provides the signature algorithm's definition.
For 512-2048-bit RSASSA-PSS with SHA-256 see [RSAPSS]. For RSASSA-PSS with SHA-256 see [RSAPSS]. For DH see [CMSALG]. For
RSAES-OAEP see [RSAOAEP].
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: RSASSA-PSS, and DSA 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
signatures:
key size <= 1023 : SHOULD NOT (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, RSASSA-PSS, and DSA signatures:
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 S/MIME receiving agents during
signature verification of DSA signatures:
key size <= 1023 : MAY (see Security Considerations)
1024 = key size : SHOULD (see Security Considerations)
4.4. Encryption 4.4. Encryption
The following are the requirements for an S/MIME agent when The following are the requirements for an S/MIME agent when
establishing keys for content encryption using the RSA algorithms: establishing keys for content encryption using the RSA, RSA-OAEP, and
DH 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
establishing keys for content encryption using the DH algorithms:
key size <= 1023 : SHOULD NOT (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, RSAES-OAEP,
and DH 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
establishing keys for content decryption using the DH algorithms:
key size <= 1023 : MAY (see Security Considerations)
1024 = key size : SHOULD (see Security Considerations)
5. IANA Considerations 5. IANA Considerations
The following is intended to provide sufficient information to update The following is intended to provide sufficient information to update
the media type registration for application/pkcs7-mime and the media type registration for application/pkcs7-mime and
application/pkcs7-signature to refer to this document as opposed to application/pkcs7-signature to refer to this document as opposed to
RFC 2311. RFC 2311.
Note that other documents can define additional MIME media types for Note that other documents can define additional MIME media types for
S/MIME. S/MIME.
skipping to change at page 37, line 15 skipping to change at page 36, line 44
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 at least 100 bits of specification is based on the desire to provide at least 100 bits of
security. The standards to offer the same level of security for DSA security. The key sizes that must be supported to conform to this
and DH are not yet available. In particular, [FIPS186-2] without specification seem appropriate for the Internet based on [STRENGTH].
Change Notice allowed DSA key sizes between 512 and 1024 bits and Of course, there are environments, such as financial and medical
[FIPS186-2] with Change Notice 1 only allowed DSA key sizes of 1024 system, that may select different key sizes. For this reason, an
bits. A revision to support larger key sizes is being developed, and implementation MAY support key sizes beyond those recommended in this
once it is available, implementors ought to support DSA key sizes specification.
comparable to the RSA key sizes recommended in this specification.
The key sizes that must be supported to conform to this specification
seem appropriate for the Internet based on [STRENGTH]. Of course,
there are environments, such as financial and medical system, that
may select different key sizes. For this reason, an implementation
MAY support key sizes beyond those recommended in this specification.
Receiving agents that validate signatures and sending agents that Receiving agents that validate signatures and sending agents that
encrypt messages, need to be cautious of cryptographic processing encrypt messages, need to be cautious of cryptographic processing
usage when validating signatures and encrypting messages using keys usage when validating signatures and encrypting messages using keys
larger than those mandated in this specification. An attacker could larger than those mandated in this specification. An attacker could
send certificates with keys which would result in excessive send certificates with keys which would result in excessive
cryptographic processing, for example keys larger than those mandated cryptographic processing, for example keys larger than those mandated
in this specification, which could swamp the processing element. in this specification, which could swamp the processing element.
Agents which use such keys without first validating the certificate Agents which use such keys without first validating the certificate
to a trust anchor are advised to have some sort of cryptographic to a trust anchor are advised to have some sort of cryptographic
skipping to change at page 43, line 22 skipping to change at page 42, line 48
{ iso(1) member-body(2) us(840) rsadsi(113549) { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) msg-v3dot1(21) } pkcs(1) pkcs-9(9) smime(16) modules(0) msg-v3dot1(21) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
IMPORTS IMPORTS
--
-- Copyright (c) 2009 IETF Trust and the persons identified as
-- authors of the code. All rights reserved.
--
-- Redistribution and use in source and binary forms, with or
-- without modification, are permitted provided that the following
-- conditions are met:
--
-- - Redistributions of source code must retain the above copyright
-- notice, this list of conditions and the following disclaimer.
--
-- - Redistributions in binary form must reproduce the above
-- copyright notice, this list of conditions and the following
-- disclaimer in the documentation and/or other materials provided
-- with the distribution.
--
-- - Neither the name of Internet Society, IETF or IETF Trust, nor
-- the names of specific contributors, may be used to endorse or
-- promote products derived from this software without specific
-- prior written permission.
--
--
--
-- THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
-- CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES,
-- INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
-- MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
-- DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
-- CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
-- SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
-- LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
-- OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
-- CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
-- STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
-- ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
-- ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
--
-- This version of the ASN.1 module is part of RFC XXXX;
-- see the RFC itself for full legal notices.
--
//RFC EDITOR NOTE: Replace XXXX with this RFC's #.
-- 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 by the 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
 End of changes. 20 change blocks. 
92 lines changed or deleted 108 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/