draft-ietf-smime-3851bis-00.txt   draft-ietf-smime-3851bis-01.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 November 5, 2007 Intended Status: Standard Track February 21, 2008
Expires: May 5, 2008 Obsoletes: 3851 (when approved)
Expires: August 21, 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-00.txt draft-ietf-smime-3851bis-01.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 34 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 April 5, 2008. This Internet-Draft will expire on August 21, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). 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 [RFC2119].
We define some additional terms here:
SHOULD+ This term means the same as SHOULD. However, it is likely
that an algorithm marked as SHOULD+ will be promoted at some
future time to be a MUST.
SHOULD- This term means the same as SHOULD. However, an algorithm
marked as SHOULD- may be deprecated to a MAY in a future version
of this document.
MUST- This term means the same as MUST. However, we expect at some
point that this algorithm will no longer be a MUST in a future
document. Although its status will be determined at a later
time, it is reasonable to expect that if a future revision of a
document alters the status of a MUST- algorithm, it will remain
at least a SHOULD or a SHOULD-.
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...................................................4
1.1. Specification Overview....................................4 1.1. Specification Overview....................................4
1.2. Definitions...............................................5 1.2. Definitions...............................................5
1.3. Compatibility with Prior Practice of S/MIME...............6 1.3. Compatibility with Prior Practice of S/MIME...............6
1.4. Changes Since S/MIME v3...................................6 1.4. Changes Since S/MIME v3...................................6
1.5. Changes Since S/MIME v3.1.................................6 1.5. Changes Since S/MIME v3.1.................................7
2. CMS Options....................................................7 2. CMS Options....................................................7
2.1. DigestAlgorithmIdentifier.................................7 2.1. DigestAlgorithmIdentifier.................................8
2.2. SignatureAlgorithmIdentifier..............................7 2.2. SignatureAlgorithmIdentifier..............................8
2.3. KeyEncryptionAlgorithmIdentifier..........................8 2.3. KeyEncryptionAlgorithmIdentifier..........................8
2.4. General Syntax............................................8 2.4. General Syntax............................................9
2.4.1. Data Content Type....................................8 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........................9 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.........................10 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.........................13
2.7. ContentEncryptionAlgorithmIdentifier.....................13 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............................15
2.7.3. Multiple Recipients.................................15 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..............................................16
3.1.1. Canonicalization....................................17 3.1.1. Canonicalization....................................18
3.1.2. Transfer Encoding...................................18 3.1.2. Transfer Encoding...................................18
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..........................20 3.2. The application/pkcs7-mime Type..........................21
3.2.1. The name and filename Parameters....................21 3.2.1. The name and filename Parameters....................22
3.2.2. The smime-type parameter............................22 3.2.2. The smime-type parameter............................22
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 SignedData24 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...........25
3.4.3.1. The application/pkcs7-signature MIME Type......25 3.4.3.1. The application/pkcs7-signature MIME Type......26
3.4.3.2. Creating a multipart/signed Message............25 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......................27 3.5. Creating an Compressed-only Message......................28
3.6. Multiple Operations......................................28 3.6. Multiple Operations......................................28
3.7. Creating a Certificate Management Message................29 3.7. Creating a Certificate Management Message................29
3.8. Registration Requests....................................29 3.8. Registration Requests....................................30
3.9. Identifying an S/MIME Message............................30 3.9. Identifying an S/MIME Message............................30
4. Certificate Processing........................................30 4. Certificate Processing........................................31
4.1. Key Pair Generation......................................30 4.1. Key Pair Generation......................................31
5. IANA Considerations...........................................31 5. IANA Considerations...........................................31
6. Security Considerations.......................................31 6. Security Considerations.......................................31
Appendix A. ASN.1 Module.........................................33 Appendix A. ASN.1 Module.........................................33
Appendix B. References...........................................35 Appendix B. References...........................................35
B.1. Normative References.....................................35 B.1. Normative References.....................................35
B.2. Informative References...................................36 B.2. Informative References...................................36
1. Introduction 1. Introduction
S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a
skipping to change at page 6, line 42 skipping to change at page 7, line 10
discussed. discussed.
Header protection through the use of the message/rfc822 MIME type has Header protection through the use of the message/rfc822 MIME type has
been added. been added.
Use of the CompressedData CMS type is allowed, along with required Use of the CompressedData CMS type is allowed, along with required
MIME type and file extension additions. MIME type and file extension additions.
1.5. Changes Since S/MIME v3.1 1.5. Changes Since S/MIME v3.1
Added definitions for SHOULD+, SHOULD-, and MUST-.
Sec 1.1 and Appendix A: Added references to RFCs for RSA-PSS, RSA- Sec 1.1 and Appendix A: Added references to RFCs for RSA-PSS, RSA-
OAEP, ECDH, and SHA2 CMS Algorithms. Added CMS Multiple Signers OAEP, and SHA2 CMS Algorithms. Added CMS Multiple Signers
Clarification to CMS reference. Clarification to CMS reference.
Sec 1.3: Added references to S/MIME MSG 3.1 RFCs. Sec 1.3: 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 SHA256 added as the MUST, Sec 2.2 (signature algorithms): RSA with SHA256 added as the MUST,
RSA with SHA-1 changed to MUST-, DSA with SHA-1, and RSA with MD5 RSA with SHA-1 changed to MUST-, DSA with SHA-1, and RSA with MD5
changed to SHOULD-, and RSA-PS with SHA-256, ECDSA with SHA-256 added changed to SHOULD-, and RSA-PSS with SHA-256. Also added note about
as SHOULD+. Also added note about what S/MIME v3.1 clients support. what S/MIME v3.1 clients support.
Sec 2.3 (key encryption): DH changed to SHOULD-, RSA-OAEP added as Sec 2.3 (key encryption): DH changed to SHOULD- and RSA-OAEP added as
SHOULD+, ECDH added as SHOULD+. SHOULD+.
Sec 2.5.2: Replaced reference "sha1WithRSAEncrption" with
"sha256WithRSAEncryption" and "AES-CBC" in parantheticals.
Sec 2.5.2.1, 2.7, 2.7.1, Appendix A: reference to RC2/40 removed. Sec 2.5.2.1, 2.7, 2.7.1, Appendix A: reference 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 4: Updated reference to CERT v3.2. Sec 4: Updated reference to CERT v3.2.
Sec 4.1: Updated RSA key size discussion. Moved last 4 sentences to
security considerations. Updated reference to randomness requirements
for security.
2. CMS Options 2. CMS Options
CMS allows for a wide variety of options in content and algorithm CMS allows for a wide variety of options in content and algorithm
support. This section puts forth a number of support requirements support. This section puts forth a number of support requirements
and recommendations in order to achieve a base level of and recommendations in order to achieve a base level of
interoperability among all S/MIME implementations. [CMSALG] and [CMS- interoperability among all S/MIME implementations. [CMSALG] and [CMS-
SHA2] provides additional details regarding the use of the SHA2] provides additional details regarding the use of the
cryptographic algorithms. cryptographic algorithms.
2.1. DigestAlgorithmIdentifier 2.1. DigestAlgorithmIdentifier
skipping to change at page 7, line 46 skipping to change at page 8, line 22
2.2. SignatureAlgorithmIdentifier 2.2. SignatureAlgorithmIdentifier
Receiving and sending agents: Receiving and sending agents:
- MUST support RSA with SHA-256, as specified in [CMS-SHA2] - MUST support RSA with SHA-256, as specified in [CMS-SHA2]
- MUST- support RSA with SHA-1, as specified in [CMSALG] - MUST- support RSA with SHA-1, as specified in [CMSALG]
- SHOULD+ support RSA-PSS with SHA-256, as specified in [RSAPSS] - SHOULD+ support RSA-PSS with SHA-256, as specified in [RSAPSS]
- SHOULD+ support ECDSA with SHA-256, as specified in [CMS-SHA2]
- SHOULD- support DSA with SHA-1, as specified in [CMSALG] - SHOULD- support DSA with SHA-1, as specified in [CMSALG]
- SHOULD- support RSA with MD5, as specified in [CMSALG]. - SHOULD- support RSA with MD5, as specified in [CMSALG].
Note that S/MIME v3.1 client support verifying id-dsa-with-sha1 and Note that S/MIME v3.1 client support verifying id-dsa-with-sha1 and
rsaEncryption and might not implement sha256withRSAEncryption. Note rsaEncryption and might not implement sha256withRSAEncryption. Note
that S/MIME v3 clients might only implement signing or signature that S/MIME v3 clients might only implement signing or signature
verification using id-dsa-with-sha1, and might also use id-dsa as an verification using id-dsa-with-sha1, and might also use id-dsa as an
AlgorithmIdentifier in this field. Receiving clients SHOULD AlgorithmIdentifier in this field. Receiving clients SHOULD
recognize id-dsa as equivalent to id-dsa-with-sha1, and sending recognize id-dsa as equivalent to id-dsa-with-sha1, and sending
skipping to change at page 8, line 24 skipping to change at page 8, line 45
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 RSA-OAEP, as specified in [RSAOAEP] - SHOULD+ support RSA-OAEP, as specified in [RSAOAEP]
- SHOULD+ support ECDH, as specified in [CMSECC]
- SHOULD- support DH ephemeral-static mode, as specified - SHOULD- support DH ephemeral-static mode, as specified
in [CMSALG]. in [CMSALG].
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 rsaEncryption algorithm. Note that S/MIME v3 clients decryption using rsaEncryption algorithm. Note that S/MIME v3 clients
might only implement key encryption and decryption using the Diffie- might only implement key encryption and decryption using the Diffie-
Hellman algorithm. Also note that S/MIME v2 clients are only capable Hellman algorithm. Also note that S/MIME v2 clients are only capable
of decrypting content-encryption keys using the rsaEncryption of decrypting content-encryption keys using the rsaEncryption
algorithm. algorithm.
skipping to change at page 10, line 39 skipping to change at page 11, line 11
UTCTime; signing times in 2050 or later MUST be encoded as UTCTime; signing times in 2050 or later MUST be encoded as
GeneralizedTime. When the UTCTime CHOICE is used, S/MIME agents MUST GeneralizedTime. When the UTCTime CHOICE is used, S/MIME agents MUST
interpret the year field (YY) as follows: interpret the year field (YY) as follows:
If YY is greater than or equal to 50, the year is interpreted as If YY is greater than or equal to 50, the year is interpreted as
19YY; if YY is less than 50, the year is interpreted as 20YY. 19YY; if YY is less than 50, the year is interpreted as 20YY.
2.5.2. SMIMECapabilities Attribute 2.5.2. SMIMECapabilities Attribute
The SMIMECapabilities attribute includes signature algorithms (such The SMIMECapabilities attribute includes signature algorithms (such
as "sha1WithRSAEncryption"), symmetric algorithms (such as "DES- as "sha256WithRSAEncryption"), symmetric algorithms (such as "AES-
EDE3-CBC"), and key encipherment algorithms (such as CBC"), and key encipherment algorithms (such as "rsaEncryption").
"rsaEncryption"). There are also several identifiers which indicate There are also several identifiers which indicate support for other
support for other optional features such as binary encoding and optional features such as binary encoding and compression. The
compression. The SMIMECapabilities were designed to be flexible and SMIMECapabilities were designed to be flexible and extensible so
extensible so that, in the future, a means of identifying other that, in the future, a means of identifying other capabilities and
capabilities and preferences such as certificates can be added in a preferences such as certificates can be added in a way that will not
way that will not cause current clients to break. cause current clients to break.
If present, the SMIMECapabilities attribute MUST be a If present, the SMIMECapabilities attribute MUST be a
SignedAttribute; it MUST NOT be an UnsignedAttribute. CMS defines SignedAttribute; it MUST NOT be an UnsignedAttribute. CMS defines
SignedAttributes as a SET OF Attribute. The SignedAttributes in a SignedAttributes as a SET OF Attribute. The SignedAttributes in a
signerInfo MUST NOT include multiple instances of the signerInfo MUST NOT include multiple instances of the
SMIMECapabilities attribute. CMS defines the ASN.1 syntax for SMIMECapabilities attribute. CMS defines the ASN.1 syntax for
Attribute to include attrValues SET OF AttributeValue. A Attribute to include attrValues SET OF AttributeValue. A
SMIMECapabilities attribute MUST only include a single instance of SMIMECapabilities attribute MUST only include a single instance of
AttributeValue. There MUST NOT be zero or multiple instances of AttributeValue. There MUST NOT be zero or multiple instances of
AttributeValue present in the attrValues SET OF AttributeValue. AttributeValue present in the attrValues SET OF AttributeValue.
skipping to change at page 26, line 49 skipping to change at page 27, line 22
SHA-512 sha512 SHA-512 sha512
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" and "rsa-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.
The SHA-224 algorithm [SHA224] and SHA-384 and SHA-512 algorithms The SHA-224 algorithm [SHA224] and SHA-384 and SHA-512 algorithms
[FIPS180-2] are not currently recommended in S/MIME, and are included [FIPS180-3] are not currently recommended in S/MIME, and are included
here for completeness. 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
skipping to change at page 31, line 8 skipping to change at page 31, line 30
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 768 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 512 bits long. user agent MUST NOT generate RSA key pairs less than 1024 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. A receiving agent SHOULD
be able to verify signatures with keys of any size over 512 bits. be able to verify signatures with keys of any size over 512 bits.
Some agents created in the United States have chosen to create 512
bit keys in order to get more advantageous export licenses. However,
512 bit keys are considered by many to be cryptographically insecure.
Implementers SHOULD be aware that multiple (active) key pairs can be
associated with a single individual. For example, one key pair can
be used to support confidentiality, while a different key pair can be
used for authentication.
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 33, line 5 skipping to change at page 32, line 40
See RFC 3218 [MMA] for more information about thwarting the adaptive See RFC 3218 [MMA] for more information about thwarting the adaptive
chosen ciphertext vulnerability in PKCS #1 Version 1.5 chosen ciphertext vulnerability in PKCS #1 Version 1.5
implementations. implementations.
In some circumstances the use of the Diffie-Hellman key agreement In some circumstances the use of the Diffie-Hellman key agreement
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
512 bit keys in order to get more advantageous export licenses.
However, 512 bit keys are considered by many to be cryptographically
insecure.
Implementers SHOULD be aware that multiple (active) key pairs can be
associated with a single individual. For example, one key pair can
be used to support confidentiality, while a different key pair can be
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)
pkcs(1) pkcs-9(9) smime(16) modules(0) msg-v3dot1(21) } pkcs(1) pkcs-9(9) smime(16) modules(0) msg-v3dot1(21) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
skipping to change at page 35, line 48 skipping to change at page 35, line 48
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.
[FIPS180-2] "Secure Hash Signature Standard (SHS)", National [FIPS180-3] "Secure Hash Signature Standard (SHS)", National
Institute of Standards and Technology (NIST). FIPS Institute of Standards and Technology (NIST). FIPS
Publication 180-2. Publication 180-3.
[MIME-SPEC] Freed, N. and N. Borenstein, "Multipurpose Internet [MIME-SPEC] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", RFC 2045, November 1996. Message Bodies", RFC 2045, November 1996.
Freed, N. and N. Borenstein, "Multipurpose Internet Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part Two: Media Types", RFC Mail Extensions (MIME) Part Two: Media Types", RFC
2046, November 1996. 2046, November 1996.
Moore, K., "MIME (Multipurpose Internet Mail Moore, K., "MIME (Multipurpose Internet Mail
Extensions) Part Three: Message Header Extensions for Extensions) Part Three: Message Header Extensions for
Non-ASCII Text", RFC 2047, November 1996. Non-ASCII Text", RFC 2047, November 1996.
Freed, N., Klensin, J., and J. Postel, "Multipurpose Freed, N., Klensin, J., and J. Postel, "Multipurpose
Internet Mail Extensions (MIME) Part Four: Registration Internet Mail Extensions (MIME) Part Four:
Procedures", BCP 13, RFC 2048, November 1996. Registration Procedures", BCP 13, RFC 2048, November
1996.
Freed, N. and N. Borenstein, "Multipurpose Internet Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part Five: Conformance Criteria Mail Extensions (MIME) Part Five: Conformance Criteria
and Examples", RFC 2049, November 1996. and Examples", RFC 2049, November 1996.
[MIME-SECURE] Galvin, J., Murphy, S., Crocker, S., and N. Freed, [MIME-SECURE] Galvin, J., Murphy, S., Crocker, S., and N. Freed,
"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.
[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.
[X.208-88] CCITT. Recommendation X.208: Specification of Abstract [X.208-88] CCITT. Recommendation X.208: Specification of
Syntax Notation One (ASN.1). 1988. Abstract Syntax Notation One (ASN.1). 1988.
[X.209-88] CCITT. Recommendation X.209: Specification of Basic [X.209-88] CCITT. Recommendation X.209: Specification of Basic
Encoding Rules for Abstract Syntax Notation One Encoding Rules for Abstract Syntax Notation One
(ASN.1). 1988. (ASN.1). 1988.
[X.509-88] CCITT. Recommendation X.509: The Directory - [X.509-88] CCITT. Recommendation X.509: The Directory -
Authentication Framework. 1988. Authentication Framework. 1988.
B.2. Informative References B.2. Informative References
[DHSUB] Zuccherato, R., "Methods for Avoiding the "Small- [DHSUB] Zuccherato, R., "Methods for Avoiding the "Small-
Subgroup" Attacks on the Diffie-Hellman Key Agreement Subgroup" Attacks on the Diffie-Hellman Key Agreement
Method for S/MIME", RFC 2785, March 2000. Method for S/MIME", RFC 2785, March 2000.
[MMA] Rescorla, E., "Preventing the Million Message Attack on [MMA] Rescorla, E., "Preventing the Million Message Attack
Cryptographic Message Syntax", RFC 3218, January 2002. on Cryptographic Message Syntax", RFC 3218, January
2002.
[PKCS-7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax [PKCS-7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax
Version 1.5", RFC 2315, March 1998. Version 1.5", RFC 2315, March 1998.
[RANDOM] Eastlake 3rd, D., Crocker, S., and J. Schiller, [RANDOM] Eastlake 3rd, D., Crocker, S., and J. Schiller,
"Randomness Recommendations for Security", RFC 1750, "Randomness Requirements for Security", RFC 4086, June
December 1994. 2005.
[SHA224] Housley, R., "A 224-bit One-way Hash Function: SHA- [SHA224] Housley, R., "A 224-bit One-way Hash Function: SHA-
224", RFC 3874, September 2004. 224", RFC 3874, September 2004.
[SMIMEV2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., [SMIMEV2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L.,
and L. Repka, "S/MIME Version 2 Message Specification", and L. Repka, "S/MIME Version 2 Message
RFC 2311, March 1998. Specification", RFC 2311, March 1998.
Appendix C. Acknowledgements Appendix C. Acknowledgements
Many thanks go out to the other authors of the S/MIME Version 2 Many thanks go out to the other authors of the S/MIME Version 2
Message Specification RFC: Steve Dusse, Paul Hoffman, Laurence Message Specification RFC: Steve Dusse, Paul Hoffman, Laurence
Lundblade and Lisa Repka. 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,
skipping to change at page 38, line 26 skipping to change at page 38, line 26
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 Jim Schaad
Author's Addresses Author's Addresses
Blake Ramsdell Blake Ramsdell
SendMail SendMail
Email: ramsdell (at) sendmail (dot) com Email: ramsdell@sendmail.com
Sean Turner Sean Turner
IECA, Inc. IECA, Inc.
3057 Nutley Street, Suite 106
Fairfax, VA 22031
USA
Email: turners (at) ieca (dot) com Email: turners@ieca.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 39, line 42 skipping to change at page 39, line 42
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an 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 attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at
ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is provided by the IETF Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA). Administrative Support Activity (IASA).
 End of changes. 45 change blocks. 
69 lines changed or deleted 101 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/