draft-ietf-smime-3851bis-04.txt   draft-ietf-smime-3851bis-05.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 June 30, 2008 Intended Status: Standard Track August 20, 2008
Obsoletes: 3851 (when approved) Obsoletes: 3851 (when approved)
Expires: December 30, 2008 Expires: February 20, 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-04.txt draft-ietf-smime-3851bis-05.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 December 30, 2008. This Internet-Draft will expire on February 20, 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,
skipping to change at page 2, line 18 skipping to change at page 2, line 18
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....................................3
1.2. Definitions...............................................4 1.2. Definitions...............................................4
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.................................6
2. CMS Options....................................................8 2. CMS Options....................................................8
2.1. DigestAlgorithmIdentifier.................................8 2.1. DigestAlgorithmIdentifier.................................8
2.2. SignatureAlgorithmIdentifier..............................8 2.2. SignatureAlgorithmIdentifier..............................8
2.3. KeyEncryptionAlgorithmIdentifier..........................9 2.3. KeyEncryptionAlgorithmIdentifier..........................9
2.4. General Syntax............................................9 2.4. General Syntax............................................9
2.5. Attributes and the SignerInfo Type.......................10 2.5. Attributes and the SignerInfo Type.......................10
2.5.1. Signing-Time Attribute..............................11
2.5.2. SMIMECapabilities Attribute.........................12
2.5.3. Encryption Key Preference Attribute.................13
2.6. SignerIdentifier SignerInfo Type.........................14 2.6. SignerIdentifier SignerInfo Type.........................14
2.7. ContentEncryptionAlgorithmIdentifier.....................15 2.7. ContentEncryptionAlgorithmIdentifier.....................15
2.7.1. Deciding Which Encryption Method To Use.............15
2.7.2. Choosing Weak Encryption............................16
2.7.3. Multiple Recipients.................................17
3. Creating S/MIME Messages......................................17 3. Creating S/MIME Messages......................................17
3.1. Preparing the MIME Entity for Signing, Enveloping or 3.1. Preparing the MIME Entity for Signing, Enveloping or
Compressing..............................................17 Compressing..............................................17
3.2. The application/pkcs7-mime Media Type....................22 3.2. The application/pkcs7-mime Media Type....................22
3.3. Creating an Enveloped-only Message.......................24 3.3. Creating an Enveloped-only Message.......................24
3.4. Creating a Signed-only Message...........................25 3.4. Creating a Signed-only Message...........................25
3.4.1. Choosing a Format for Signed-only Messages..........25
3.4.2. Signing Using application/pkcs7-mime with
SignedData..........................................26
3.4.3. Signing Using the multipart/signed Format...........26
3.5. Creating an Compressed-only Message......................29 3.5. Creating an Compressed-only Message......................29
3.6. Multiple Operations......................................29 3.6. Multiple Operations......................................30
3.7. Creating a Certificate Management Message................30 3.7. Creating a Certificate Management Message................30
3.8. Registration Requests....................................31 3.8. Registration Requests....................................31
3.9. Identifying an S/MIME Message............................31 3.9. Identifying an S/MIME Message............................31
4. Certificate Processing........................................31 4. Certificate Processing........................................32
4.1. Key Pair Generation......................................32 4.1. Key Pair Generation......................................32
4.2. Signature Generation.....................................32 4.2. Signature Generation.....................................32
4.3. Signature Verification...................................32 4.3. Signature Verification...................................32
4.4. Encryption...............................................32 4.4. Encryption...............................................33
4.5. Decryption...............................................33 4.5. Decryption...............................................33
5. IANA Considerations...........................................34 5. IANA Considerations...........................................33
5.1. Media Type for application/pkcs7-mime....................34 5.1. Media Type for application/pkcs7-mime....................34
5.2. Media Type for application/pkcs7-signature...............35 5.2. Media Type for application/pkcs7-signature...............35
6. Security Considerations.......................................36 6. Security Considerations.......................................36
7. References....................................................38 7. References....................................................38
7.1. Normative References.....................................38 7.1. Normative References.....................................38
7.2. Informative References...................................40 7.2. Informative References...................................40
Appendix A. ASN.1 Module.........................................42 Appendix A. ASN.1 Module.........................................42
Appendix B. Moving S/MIME v2 Message Specification to Appendix B. Moving S/MIME v2 Message Specification to
Historic Status......................................44 Historic Status......................................44
Appendix C. Acknowledgements.....................................45 Appendix C. Acknowledgements.....................................44
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 5, line 5 skipping to change at page 4, line 39
data. An automated process that sends an encrypted message might not data. An automated process that sends an encrypted message might not
be able to receive an encrypted message at all, for example. Thus, be able to receive an encrypted message at all, for example. Thus,
the requirements and recommendations for the two types of agents are the requirements and recommendations for the two types of agents are
listed separately when appropriate. listed separately when appropriate.
1.2. Definitions 1.2. Definitions
For the purposes of this specification, the following definitions For the purposes of this specification, the following definitions
apply. apply.
ASN.1: Abstract Syntax Notation One, as defined in CCITT X.208 ASN.1: Abstract Syntax Notation One, as defined in ITU-T
[X.208-88]. Recommendation X.680 [X.680].
BER: Basic Encoding Rules for ASN.1, as defined in CCITT X.209 BER: Basic Encoding Rules for ASN.1, as defined in ITU-T
[X.690-02]. Recommendation X.690 [X.690].
Certificate: A type that binds an entity's name to a public key with Certificate: A type that binds an entity's name to a public key with
a digital signature. a digital signature.
DER: Distinguished Encoding Rules for ASN.1, as defined in CCITT DER: Distinguished Encoding Rules for ASN.1, as defined in ITU-T
X.509 [X.690-02]. Recommendation X.690 [X.690].
7-bit data: Text data with lines less than 998 characters long, where 7-bit data: Text data with lines less than 998 characters long, where
none of the characters have the 8th bit set, and there are no NULL none of the characters have the 8th bit set, and there are no NULL
characters. <CR> and <LF> occur only as part of a <CR><LF> end of characters. <CR> and <LF> occur only as part of a <CR><LF> end of
line delimiter. line delimiter.
8-bit data: Text data with lines less than 998 characters, and where 8-bit data: Text data with lines less than 998 characters, and where
none of the characters are NULL characters. <CR> and <LF> occur only none of the characters are NULL characters. <CR> and <LF> occur only
as part of a <CR><LF> end of line delimiter. as part of a <CR><LF> end of line delimiter.
skipping to change at page 7, line 17 skipping to change at page 7, line 5
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.2. Added Moved "Conventions Used in This Document" to Section 1.2. 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 RSA-PSS, RSA-
OAEP, 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.2: Updated references to ASN.1 to X.680 and BER and DER to
X.690.
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 SHA-256 added as the MUST, Sec 2.2 (signature algorithms): RSA with SHA-256 and DSA with SHA-256
RSA with SHA-1, DSA with SHA-1, and RSA with MD5 changed to SHOULD-, added as MUSTs, RSA with SHA-1, DSA with SHA-1, and RSA with MD5
and RSA-PSS with SHA-256 added as SHOULD+. Also added note about what changed to SHOULD-, and RSA-PSS with SHA-256 added as SHOULD+. Also
S/MIME v3.1 clients support. added note about what S/MIME v3.1 clients support.
Sec 2.3 (key encryption): DH changed to SHOULD- and RSA-OAEP added as Sec 2.3 (key encryption): DH changed to SHOULD- and RSA-OAEP added as
SHOULD+. SHOULD+.
Sec 2.5.1: Added requirement that receiving agents MUST support both Sec 2.5.1: Added requirement that receiving agents MUST support both
GeneralizedTime and UTCTime. GeneralizedTime and UTCTime.
Sec 2.5.2: Replaced reference "sha1WithRSAEncrption" with Sec 2.5.2: Replaced reference "sha1WithRSAEncrption" with
"sha256WithRSAEncryption", "DES-3EDE-CBC" and "AES-128 CBC", and "sha256WithRSAEncryption", "DES-3EDE-CBC" and "AES-128 CBC", and
deleted the RC5 example. deleted the RC5 example.
skipping to change at page 8, line 5 skipping to change at page 7, line 41
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.2.2: Replaced "encrypted" with "enveloped." Update OID example Sec 3.2.2: Replaced "encrypted" with "enveloped." Update OID example
to use AES-128 CBC oid. to use AES-128 CBC oid.
Sec 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 four sentences Sec 4.1: Updated RSA and DSA key size discussion. Moved last four
to security considerations. Updated reference to randomness sentences to security considerations. Updated reference to randomness
requirements for security. requirements for security.
Sec 5: Added IANA registration templates to update media type Sec 5: Added IANA registration templates to update media type
registry to point to this document as opposed to RFC 2311. registry to point to this document as opposed to RFC 2311.
Sec 6: Updated Security Considerations. Sec 6: Updated Security Considerations.
Sec 7: Moved references from Appendix B to this section. Update Sec 7: Moved references from Appendix B to this section. Update
references. Added informational references to SMIMEv2, SMIMEv3, and references. Added informational references to SMIMEv2, SMIMEv3, and
SMIMEv3.1. SMIMEv3.1.
skipping to change at page 8, line 43 skipping to change at page 8, line 34
SHOULD- support SHA-1 [CMSALG]. Receiving agents SHOULD- support MD5 SHOULD- support SHA-1 [CMSALG]. Receiving agents SHOULD- support MD5
[CMSALG] for the purpose of providing backward compatibility with [CMSALG] for the purpose of providing backward compatibility with
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, as specified in [CMS-SHA2] - MUST support RSA with SHA-256, as specified in [CMS-SHA2]
- SHOULD+ support DSA with SHA-256, as specified in [CMS-SHA2]
- SHOULD+ support RSA-PSS with SHA-256, as specified in [RSAPSS] - SHOULD+ support RSA-PSS with SHA-256, as specified in [RSAPSS]
- SHOULD- support RSA with SHA-1, as specified in [CMSALG] - SHOULD- support RSA with SHA-1, as specified in [CMSALG]
- 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].
Sending agents: Sending agents:
- MUST support RSA with SHA-256, as specified in [CMS-SHA2] - MUST support RSA with SHA-256, as specified in [CMS-SHA2]
- SHOULD+ support DSA with SHA-256, as specified in [CMS-SHA2]
- SHOULD+ support RSA-PSS with SHA-256, as specified in [RSAPSS] - SHOULD+ support RSA-PSS with SHA-256, as specified in [RSAPSS]
- SHOULD- support RSA with SHA-1 or DSA with SHA-1, as specified in - SHOULD- support RSA with SHA-1 or DSA with SHA-1, as specified in
[CMSALG] [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 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 32, line 26 skipping to change at page 32, line 36
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.
An S/MIME user agent MUST NOT generate asymmetric keys less than 512 An S/MIME user agent MUST NOT generate asymmetric keys less than 512
bits for use with the RSA or DSA signature algorithms. bits for use with the RSA or DSA signature algorithms.
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
or DSA signature: signatures:
512 <= key size < 1024 : MAY (see Security Considerations) 512 <= key size < 1024 : MAY (see Security Considerations)
1024 <= key size <= 2048 : SHOULD (see Security Considerations) 1024 <= key size <= 2048 : SHOULD (see Security Considerations)
2048 < key size <= 4096 : MAY (see Security Considerations) 2048 < key size : MAY (see Security Considerations)
The following are the requirements for an S/MIME agent generated DSA
signatures:
512 <= key size <= 1024 : 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 or DSA signatures: signature verification of RSA signatures:
512 <= key size <= 2048 : MUST (see Security Considerations) 512 <= key size <= 2048 : MUST (see Security Considerations)
2048 < key size <= 4096 : 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:
512 <= key size <= 1024 : 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 or DH establishing keys for content encryption using the RSA algorithms:
algorithms:
512 <= key size < 1024 : MAY (see Security Considerations) 512 <= key size < 1024 : MAY (see Security Considerations)
1024 <= key size <= 2048 : SHOULD (see Security Considerations) 1024 <= key size <= 2048 : SHOULD (see Security Considerations)
2048 < key size <= 4096 : 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:
512 <= key size <= 1024 : 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 or DH establishing keys for content decryption using the RSA algorithms:
algorithms:
512 <= key size <= 2048 : MUST (see Security Considerations) 512 <= key size <= 2048 : MUST (see Security Considerations)
2048 < key size <= 4096 : 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:
512 <= key size <= 1024 : 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
S/MIME.
5.1. Media Type for application/pkcs7-mime 5.1. Media Type for application/pkcs7-mime
Type name: application Type name: application
Subtype Name: pkcs7-mime Subtype Name: pkcs7-mime
Required Parameters: NONE Required Parameters: NONE
Optional Parameters: smime-type/signed-data Optional Parameters: smime-type/signed-data
smime-type/enveloped-data smime-type/enveloped-data
skipping to change at page 36, line 26 skipping to change at page 36, line 26
RFC 2785 [DHSUB]. RFC 2785 [DHSUB].
- The attacks against hash algorithms described in - The attacks against hash algorithms described in
RFC 4270 [HASH-ATTACK] RFC 4270 [HASH-ATTACK]
This specification uses Public-Key Cryptography technologies. It is This specification uses Public-Key Cryptography technologies. It is
assumed that the private is protected to ensure that it is not assumed that the private 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 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 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 1024 bits as the RSA, DSA, and DH asymmetric key size The choice of 1024 bits as the RSA, DSA, and DH asymmetric key size
in this specification is based on the desire to provide 80 bits of in this specification is based on the desire to provide 80 bits of
security. This key size seems prudent for the Internet based on security. This key size seems prudent for the Internet based on
Section 4.3 of [STRENGTH]. There are other environments (e.g., Section 4.3 of [STRENGTH]. There are other environments (e.g.,
government, financial, and medical) that may consider this key size government, financial, and medical) that may consider this key size
to be inadequate. Likewise, there are other environments that may to be inadequate. Likewise, there are other environments that may
consider this key size to be excessive. consider this key size to be excessive.
Larger keys are not necessarily better keys. Larger keys take more Receiving agents that validate signatures and sending agents that
computational resources, and this can quickly become impractical. In encrypt messages, need to be cautious of cryptographic processing
fact, support for an excessively large key offers a denial of service usage when validating signatures and encrypting messages using keys
opportunity if the attacker can cause excessive cryptographic larger than those mandated in this specification. An attacker could
processing by providing such a public key. One mitigation approach send certificates with keys which would result in excessive
would require that the corresponding public key certificate be cryptographic processing, for example keys larger than those mandated
validated to a trust anchor prior to use, thus ensuring that only in this specification, which could swamp the processing element.
trusted public keys are used. However, some implementations may
choose to perform signature verification (or key establishment for Agents which use such keys without first validating the certificate
encryption) in parallel with certificate validation, even if to a trust anchor are advised to have some sort of cryptographic
certificate validation fails. In such cases, measures should be resource management system to prevent such attacks.
included to limit the impact, for example by limiting cryptographic
processing time or requiring certificate validation prior to the use
of large keys.
Today, 512-bit RSA, DSA, and DH keys are considered by many experts Today, 512-bit RSA, DSA, and DH keys are considered by many experts
to be cryptographically insecure. to be cryptographically insecure.
Using weak cryptography in S/MIME offers little actual security over Using weak cryptography in S/MIME offers little actual security over
sending plaintext. However, other features of S/MIME, such as the sending plaintext. However, other features of S/MIME, such as the
specification of AES and the ability to announce stronger specification of AES and the ability to announce stronger
cryptographic capabilities to parties with whom you communicate, cryptographic capabilities to parties with whom you communicate,
allow senders to create messages that use strong encryption. Using allow senders to create messages that use strong encryption. Using
weak cryptography is never recommended unless the only alternative is weak cryptography is never recommended unless the only alternative is
skipping to change at page 39, line 46 skipping to change at page 39, line 46
[RANDOM] Eastlake 3rd, D., Crocker, S., and J. Schiller, [RANDOM] Eastlake 3rd, D., Crocker, S., and J. Schiller,
"Randomness Requirements for Security", BCP 106, RFC "Randomness Requirements for Security", BCP 106, RFC
4086, June 2005. 4086, June 2005.
[RSAPSS] Schaad, J., "Use of RSASA-PSS Signature Algorithm in [RSAPSS] Schaad, J., "Use of RSASA-PSS Signature Algorithm in
Cryptographic Message Syntax (CMS)", RFC 4056, June Cryptographic Message Syntax (CMS)", RFC 4056, June
2005. 2005.
[RSAOAEP] Housley, R. "Use of the RSAES-OAEP Key Transport [RSAOAEP] Housley, R. "Use of the RSAES-OAEP Key Transport
Algorithm in the Cryptographic Message Syntax (CMS)", Algorithm in the Cryptographic Message Syntax (CMS)",
[X.208-88] ITU-T Recommandation X.208 (1988) | ISO/IEC 8824- [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-
1:1988. Specification of Abstract Syntax Notation One 1:2002. Information Technology - Abstract Syntax
(ASN.1). Notation One (ASN.1): Specification of basic
notation.
[X.690-02] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825- [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-
1:2002. Information Technology - ASN.1 encoding 1:2002. Information Technology - ASN.1 encoding
rules: Specification of Basic Encoding Rules (BER), rules: Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and Distinguished Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER). Encoding Rules (DER).
7.2. Informative References 7.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.
skipping to change at page 42, line 8 skipping to change at page 42, line 8
Hoffman, P., "Enhanced Security Services for S/MIME", Hoffman, P., "Enhanced Security Services for S/MIME",
RFC 2634, June 1999. RFC 2634, June 1999.
[STRENGTH] Orman, H., and P. Hoffman, "Determining Strengths For [STRENGTH] Orman, H., and P. Hoffman, "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys", BCP Public Keys Used For Exchanging Symmetric Keys", BCP
86, RFC 3766, April 2004. 86, RFC 3766, April 2004.
Appendix A. ASN.1 Module Appendix A. ASN.1 Module
NOTE: The ASN.1 module contained herein is unchanged from RFC 3851 NOTE: The ASN.1 module contained herein is unchanged from RFC 3851
[SMIMEv3], with the exception of a minor change to the [SMIMEv3.1] with the exception of a minor change to the
prefersBinaryInside ASN.1 comment. prefersBinaryInside ASN.1 comment. This modules use the 1988 version
of ASN.1.
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
IMPORTS IMPORTS
-- Cryptographic Message Syntax -- Cryptographic Message Syntax [CMS]
SubjectKeyIdentifier, IssuerAndSerialNumber, SubjectKeyIdentifier, IssuerAndSerialNumber,
RecipientKeyIdentifier RecipientKeyIdentifier
FROM CryptographicMessageSyntax FROM CryptographicMessageSyntax
{ iso(1) member-body(2) us(840) rsadsi(113549) { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2001(14) }; pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2001(14) };
-- id-aa is the arc with all new authenticated and unauthenticated -- id-aa is the arc with all new authenticated and unauthenticated
-- attributes produced the by S/MIME Working Group -- attributes produced 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)
skipping to change at page 45, line 19 skipping to change at page 44, line 27
Lundblade and Lisa Repka. Without v2, there wouldn't be a v3, v3.1 or Lundblade and Lisa Repka. Without v2, there wouldn't be a v3, v3.1 or
v3.2. v3.2.
A number of the members of the S/MIME Working Group have also worked A number of the members of the S/MIME Working Group have also worked
very hard and contributed to this document. Any list of people is very hard and contributed to this document. Any list of people is
doomed to omission, and for that I apologize. In alphabetical order, doomed to omission, and for that I apologize. In alphabetical order,
the following people stand out in my mind due to the fact that they the following people stand out in my mind due to the fact that they
made direct contributions to this document. made direct contributions to this document.
Tony Capel, Piers Chivers, Dave Crocker, Bill Flanigan, Peter Tony Capel, Piers Chivers, Dave Crocker, Bill Flanigan, Peter
Gutmann, Paul Hoffman, Russ Housley, William Ottaway, John Pawling, Gutmann, Alfred Hoenes, Paul Hoffman, Russ Housley, William Ottaway,
Jim Schaad, and Alfred Hoenes. John Pawling, and Jim Schaad.
Author's Addresses Author's Addresses
Blake Ramsdell Blake Ramsdell
SendMail SendMail
Email: blake@sendmail.com Email: blake@sendmail.com
Sean Turner Sean Turner
 End of changes. 39 change blocks. 
68 lines changed or deleted 85 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/