draft-ietf-smime-3851bis-01.txt   draft-ietf-smime-3851bis-02.txt 
S/MIME WG Blake Ramsdell, SendMail S/MIME WG Blake Ramsdell, SendMail
Internet Draft Sean Turner, IECA Internet Draft Sean Turner, IECA
Intended Status: Standard Track February 21, 2008 Intended Status: Standard Track May 12, 2008
Obsoletes: 3851 (when approved) Obsoletes: 3851 (when approved)
Expires: August 21, 2008 Expires: November 12, 2008
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-01.txt draft-ietf-smime-3851bis-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on August 21, 2008. This Internet-Draft will expire on November 12, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document defines Secure/Multipurpose Internet Mail Extensions This document defines Secure/Multipurpose Internet Mail Extensions
(S/MIME) version 3.2. S/MIME provides a consistent way to send and (S/MIME) version 3.2. S/MIME provides a consistent way to send and
receive secure MIME data. Digital signatures provide authentication, receive secure MIME data. Digital signatures provide authentication,
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.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [MUSTSHOULD].
We define some additional terms here: We define some additional terms here:
SHOULD+ This term means the same as SHOULD. However, it is likely SHOULD+ This term means the same as SHOULD. However, it is likely
that an algorithm marked as SHOULD+ will be promoted at some that an algorithm marked as SHOULD+ will be promoted at some
future time to be a MUST. future time to be a MUST.
SHOULD- This term means the same as SHOULD. However, an algorithm SHOULD- This term means the same as SHOULD. However, an algorithm
marked as SHOULD- may be deprecated to a MAY in a future version marked as SHOULD- may be deprecated to a MAY in a future version
of this document. of this document.
skipping to change at page 3, line 13 skipping to change at page 3, line 15
2.4.1. Data Content Type....................................9 2.4.1. Data Content Type....................................9
2.4.2. SignedData Content Type..............................9 2.4.2. SignedData Content Type..............................9
2.4.3. EnvelopedData Content Type...........................9 2.4.3. EnvelopedData Content Type...........................9
2.4.4. CompressedData Content Type..........................9 2.4.4. CompressedData Content Type..........................9
2.5. Attributes and the SignerInfo Type.......................10 2.5. Attributes and the SignerInfo Type.......................10
2.5.1. Signing-Time Attribute..............................10 2.5.1. Signing-Time Attribute..............................10
2.5.2. SMIMECapabilities Attribute.........................11 2.5.2. SMIMECapabilities Attribute.........................11
2.5.3. Encryption Key Preference Attribute.................12 2.5.3. Encryption Key Preference Attribute.................12
2.5.3.1. Selection of Recipient Key Management 2.5.3.1. Selection of Recipient Key Management
Certificate....................................13 Certificate....................................13
2.6. SignerIdentifier SignerInfo Type.........................13 2.6. SignerIdentifier SignerInfo Type.........................14
2.7. ContentEncryptionAlgorithmIdentifier.....................14 2.7. ContentEncryptionAlgorithmIdentifier.....................14
2.7.1. Deciding Which Encryption Method To Use.............14 2.7.1. Deciding Which Encryption Method To Use.............14
2.7.1.1. Rule 1: Known Capabilities.....................15 2.7.1.1. Rule 1: Known Capabilities.....................15
2.7.1.2. Rule 2: Unknown Capabilities, Unknown Version of 2.7.1.2. Rule 2: Unknown Capabilities, Unknown Version of
S/MIME..................................................15 S/MIME..................................................15
2.7.2. Choosing Weak Encryption............................15 2.7.2. Choosing Weak Encryption............................16
2.7.3. Multiple Recipients.................................16 2.7.3. Multiple Recipients.................................16
3. Creating S/MIME Messages......................................16 3. Creating S/MIME Messages......................................16
3.1. Preparing the MIME Entity for Signing, Enveloping or 3.1. Preparing the MIME Entity for Signing, Enveloping or
Compressing..............................................16 Compressing..............................................17
3.1.1. Canonicalization....................................18 3.1.1. Canonicalization....................................18
3.1.2. Transfer Encoding...................................18 3.1.2. Transfer Encoding...................................19
3.1.3. Transfer Encoding for Signing Using multipart/signed19 3.1.3. Transfer Encoding for Signing Using multipart/signed19
3.1.4. Sample Canonical MIME Entity........................20 3.1.4. Sample Canonical MIME Entity........................20
3.2. The application/pkcs7-mime Type..........................21 3.2. The application/pkcs7-mime Type..........................21
3.2.1. The name and filename Parameters....................22 3.2.1. The name and filename Parameters....................22
3.2.2. The smime-type parameter............................22 3.2.2. The smime-type parameter............................23
3.3. Creating an Enveloped-only Message.......................23 3.3. Creating an Enveloped-only Message.......................23
3.4. Creating a Signed-only Message...........................24 3.4. Creating a Signed-only Message...........................24
3.4.1. Choosing a Format for Signed-only Messages..........24 3.4.1. Choosing a Format for Signed-only Messages..........24
3.4.2. Signing Using application/pkcs7-mime with SignedData25 3.4.2. Signing Using application/pkcs7-mime with SignedData25
3.4.3. Signing Using the multipart/signed Format...........25 3.4.3. Signing Using the multipart/signed Format...........26
3.4.3.1. The application/pkcs7-signature MIME Type......26 3.4.3.1. The application/pkcs7-signature MIME Type......26
3.4.3.2. Creating a multipart/signed Message............26 3.4.3.2. Creating a multipart/signed Message............26
3.4.3.3. Sample multipart/signed Message................27 3.4.3.3. Sample multipart/signed Message................27
3.5. Creating an Compressed-only Message......................28 3.5. Creating an Compressed-only Message......................28
3.6. Multiple Operations......................................28 3.6. Multiple Operations......................................29
3.7. Creating a Certificate Management Message................29 3.7. Creating a Certificate Management Message................29
3.8. Registration Requests....................................30 3.8. Registration Requests....................................30
3.9. Identifying an S/MIME Message............................30 3.9. Identifying an S/MIME Message............................30
4. Certificate Processing........................................31 4. Certificate Processing........................................31
4.1. Key Pair Generation......................................31 4.1. Key Pair Generation......................................31
5. IANA Considerations...........................................31 5. IANA Considerations...........................................32
6. Security Considerations.......................................31 6. Security Considerations.......................................32
Appendix A. ASN.1 Module.........................................33 Appendix A. ASN.1 Module.........................................34
Appendix B. References...........................................35 Appendix B. References...........................................36
B.1. Normative References.....................................35 B.1. Normative References.....................................36
B.2. Informative References...................................36 B.2. Informative References...................................37
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). encryption).
skipping to change at page 5, line 5 skipping to change at page 5, line 8
This document also discusses how to use the multipart/signed MIME This document also discusses how to use the multipart/signed MIME
type defined in [MIME-SECURE] to transport S/MIME signed messages. type defined in [MIME-SECURE] to transport S/MIME signed messages.
multipart/signed is used in conjunction with the application/pkcs7- multipart/signed is used in conjunction with the application/pkcs7-
signature MIME type, which is used to transport a detached S/MIME signature MIME type, which is used to transport a detached S/MIME
signature. signature.
In order to create S/MIME messages, an S/MIME agent MUST follow the In order to create S/MIME messages, an S/MIME agent MUST follow the
specifications in this document, as well as the specifications listed specifications in this document, as well as the specifications listed
in the Cryptographic Message Syntax document [CMS], [CMSALG], in the Cryptographic Message Syntax document [CMS], [CMSALG],
[RSAPSS], [RSAOAEP], [CMSECC], [CMS-SHA2]. [RSAPSS], [RSAOAEP], and [CMS-SHA2].
Throughout this specification, there are requirements and Throughout this specification, there are requirements and
recommendations made for how receiving agents handle incoming recommendations made for how receiving agents handle incoming
messages. There are separate requirements and recommendations for messages. There are separate requirements and recommendations for
how sending agents create outgoing messages. In general, the best how sending agents create outgoing messages. In general, the best
strategy is to "be liberal in what you receive and conservative in strategy is to "be liberal in what you receive and conservative in
what you send". Most of the requirements are placed on the handling what you send". Most of the requirements are placed on the handling
of incoming messages while the recommendations are mostly on the of incoming messages while the recommendations are mostly on the
creation of outgoing messages. creation of outgoing messages.
skipping to change at page 31, line 31 skipping to change at page 31, line 34
4.1. Key Pair Generation 4.1. Key Pair Generation
All generated key pairs MUST be generated from a good source of non- All generated key pairs MUST be generated from a good source of non-
deterministic random input [RANDOM] and the private key MUST be deterministic random input [RANDOM] and the private key MUST be
protected in a secure fashion. protected in a secure fashion.
If an S/MIME agent needs to generate an RSA key pair, then the S/MIME If an S/MIME agent needs to generate an RSA key pair, then the S/MIME
agent or some related administrative utility or function SHOULD agent or some related administrative utility or function SHOULD
generate RSA key pairs using the following guidelines. A user agent generate RSA key pairs using the following guidelines. A user agent
SHOULD generate RSA key pairs at a minimum key size of 1024 bits. A SHOULD generate RSA key pairs at a minimum key size of 1024 bits. A
user agent MUST NOT generate RSA key pairs less than 1024 bits long. user agent MUST NOT generate RSA key pairs less than 512 bits long.
Creating keys longer than 1024 bits can cause some older S/MIME Creating keys longer than 1024 bits can cause some older S/MIME
receiving agents to not be able to verify signatures, but gives receiving agents to not be able to verify signatures, but gives
better security and is therefore valuable. A receiving agent SHOULD better security and is therefore valuable.
be able to verify signatures with keys of any size over 512 bits.
A receiving agent needs to verify signatures whose key length is
chosen by the signer. For interoperability, a receiving agent MUST be
able to verify signatures whose key length is 1024 bits or shorter.
Being able to verify signatures shorter than 1024 bits is mandatory
because earlier versions of this specification required the ability
to generate signatures with shorter key lengths. Note that most
receiving agents are likely to see signatures whose key length is
longer than 1024 bits in the future, and those receiving agents will
want to be able to verify those signatures.
5. IANA Considerations 5. IANA Considerations
None: All identifiers are already registered. Please remove this None: All identifiers are already registered. Please remove this
section prior to publication as an RFC. section prior to publication as an RFC.
6. Security Considerations 6. Security Considerations
40-bit encryption is considered weak by most cryptographers. Using 40-bit encryption is considered weak by most cryptographers. Using
weak cryptography in S/MIME offers little actual security over weak cryptography in S/MIME offers little actual security over
skipping to change at page 32, line 45 skipping to change at page 33, line 13
scheme in a prime order subgroup of a large prime p is vulnerable to scheme in a prime order subgroup of a large prime p is vulnerable to
certain attacks known as "small-subgroup" attacks. Methods exist, certain attacks known as "small-subgroup" attacks. Methods exist,
however, to prevent these attacks. These methods are described in however, to prevent these attacks. These methods are described in
RFC 2785 [DHSUB]. RFC 2785 [DHSUB].
Some S/MIME agents created in the United States have chosen to create Some S/MIME agents created in the United States have chosen to create
512 bit keys in order to get more advantageous export licenses. 512 bit keys in order to get more advantageous export licenses.
However, 512 bit keys are considered by many to be cryptographically However, 512 bit keys are considered by many to be cryptographically
insecure. insecure.
Receiving agents are only required to validate signatures that are
the same length as sending agents are required to produce. Many
people feel that signatures of 1024 bits do not meet their security
requirements today, or even if they meet their requirements today,
they will not meet their requirements in the foreseeable future.
Therefore, sending and receiving agents need to decide what strength
of signature they want to produce and validate, respectively.
Further, those decisions need to be reviewed periodically in light of
decreasing cryptographic strength over time of signatures.
For receiving agents to avoid Denial of Service (DoS) attacks it is
RECOMMENDED that receiving agents not process keys larger than they
support and that the certificate containing the private key be
validated prior to use.
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 authentication. used for authentication.
Appendix A. ASN.1 Module Appendix A. ASN.1 Module
SecureMimeMessageV3dot1 SecureMimeMessageV3dot1
{ iso(1) member-body(2) us(840) rsadsi(113549) { iso(1) member-body(2) us(840) rsadsi(113549)
skipping to change at page 33, line 23 skipping to change at page 34, line 23
BEGIN BEGIN
IMPORTS IMPORTS
-- Cryptographic Message Syntax -- Cryptographic Message Syntax
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 the by 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
skipping to change at page 35, line 32 skipping to change at page 36, line 32
(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.
[CMSECC] Blake-Wilson, S., Brown, D., and P. Lambert, "Use of
Elliptic Curve Cryptography (ECC) Algorithms in
Cryptographic Message Syntax (CMS)", RFC 3278, April
2002.
[CMS-SHA2] Turner. S., "Using SHA2 Algorithms with Cryptographic [CMS-SHA2] Turner. S., "Using SHA2 Algorithms with Cryptographic
Message Syntax", work in progress. Message Syntax", work in 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.
skipping to change at page 38, line 19 skipping to change at page 39, line 19
Lundblade and Lisa Repka. Lundblade and Lisa Repka.
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, Paul Hoffman, Russ Housley, William Ottaway, John Pawling, Gutmann, Paul Hoffman, Russ Housley, William Ottaway, John Pawling,
Jim Schaad and Jim Schaad.
Author's Addresses Author's Addresses
Blake Ramsdell Blake Ramsdell
SendMail SendMail
Email: ramsdell@sendmail.com Email: blake@sendmail.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. 21 change blocks. 
31 lines changed or deleted 49 lines changed or added

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