draft-ietf-smime-rfc2633bis-04.txt   draft-ietf-smime-rfc2633bis-05.txt 
Internet Draft Editor: Blake Ramsdell, Internet Draft Editor: Blake Ramsdell,
draft-ietf-smime-rfc2633bis-04.txt Brute Squad Labs draft-ietf-smime-rfc2633bis-05.txt Brute Squad Labs
June 2, 2003 June 30, 2003
Expires December 2, 2003 Expires December 30, 2003
S/MIME Version 3.1 Message Specification S/MIME Version 3.1 Message Specification
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other Force (IETF), its areas, and its working groups. Note that other
skipping to change at line 151 skipping to change at line 151
interoperability possible with S/MIME version 2 agents. S/MIME version interoperability possible with S/MIME version 2 agents. S/MIME version
2 is described in RFC 2311 through RFC 2315, inclusive. RFC 2311 also 2 is described in RFC 2311 through RFC 2315, inclusive. RFC 2311 also
has historical information about the development of S/MIME. has historical information about the development of S/MIME.
1.5 Changes Since S/MIME v3.0 1.5 Changes Since S/MIME v3.0
The RSA public key algorithm was changed to a MUST implement key The RSA public key algorithm was changed to a MUST implement key
wrapping algorithm, and the Diffie-Hellman algorithm changed to a wrapping algorithm, and the Diffie-Hellman algorithm changed to a
SHOULD implement. SHOULD implement.
The AES symmetric encryption algorithm has been included as a SHOULD
implement.
The RSA public key algorithm was changed to a MUST implement signature The RSA public key algorithm was changed to a MUST implement signature
algorithm. algorithm.
Ambiguous language about the use of "empty" SignedData messages to Ambiguous language about the use of "empty" SignedData messages to
transmit certificates was clarified to reflect that transmission of transmit certificates was clarified to reflect that transmission of
certificate revocation lists is also allowed. certificate revocation lists is also allowed.
The use of binary encoding for some MIME entities is now explicitly The use of binary encoding for some MIME entities is now explicitly
discussed. discussed.
skipping to change at line 197 skipping to change at line 200
regarding the use of the cryptographic algorithms. regarding the use of the cryptographic algorithms.
2.1 DigestAlgorithmIdentifier 2.1 DigestAlgorithmIdentifier
Sending and receiving agents MUST support SHA-1 [CMSALG]. Receiving Sending and receiving agents MUST support SHA-1 [CMSALG]. Receiving
agents SHOULD support MD5 [CMSALG] for the purpose of providing agents SHOULD support MD5 [CMSALG] for the purpose of providing
backward compatibility with MD5-digested S/MIME v2 SignedData objects. backward compatibility with MD5-digested S/MIME v2 SignedData objects.
2.2 SignatureAlgorithmIdentifier 2.2 SignatureAlgorithmIdentifier
Receiving agents MUST support id-dsa defined in [CMSALG]. The Receiving agents MUST support id-dsa-with-sha1 defined in [CMSALG].
algorithm parameters MUST be absent (not encoded as NULL). Receiving The algorithm parameters MUST be absent (not encoded as NULL).
agents MUST support rsaEncryption, defined in [CMSALG]. Receiving agents MUST support rsaEncryption, defined in [CMSALG].
Sending agents MUST support either id-dsa or rsaEncryption. Sending agents MUST support either id-dsa-with-sha1 or rsaEncryption.
Note that S/MIME v3 clients might only implement signing or signature Note that S/MIME v3 clients might only implement signing or signature
verification using id-dsa. Also note that S/MIME v2 clients are only verification using id-dsa-with-sha1, and might also use id-dsa as an
capable of verifying digital signatures using the rsaEncryption AlgorithmIdentifier in this field. Receiving clients SHOULD recognize
algorithm. id-dsa as equivalent to id-dsa-with-sha1, and sending clients MUST use
id-dsa-with-sha1 if using that algorithm. Also note that S/MIME v2
clients are only capable of verifying digital signatures using the
rsaEncryption algorithm.
2.3 KeyEncryptionAlgorithmIdentifier 2.3 KeyEncryptionAlgorithmIdentifier
Sending and receiving agents MUST support rsaEncryption, defined in Sending and receiving agents MUST support rsaEncryption, defined in
[CMSALG]. [CMSALG].
Sending and receiving agents SHOULD support Diffie-Hellman defined in Sending and receiving agents SHOULD support Diffie-Hellman defined in
[CMSALG]. [CMSALG].
Note that S/MIME v3 clients might only implement key encryption and Note that S/MIME v3 clients might only implement key encryption and
skipping to change at line 448 skipping to change at line 454
S/MIME v3.1 and S/MIME v3 requires the use of SignerInfo version 1, S/MIME v3.1 and S/MIME v3 requires the use of SignerInfo version 1,
that is the issuerAndSerialNumber CHOICE MUST be used for that is the issuerAndSerialNumber CHOICE MUST be used for
SignerIdentifier. SignerIdentifier.
2.7 ContentEncryptionAlgorithmIdentifier 2.7 ContentEncryptionAlgorithmIdentifier
Sending and receiving agents MUST support encryption and decryption Sending and receiving agents MUST support encryption and decryption
with DES EDE3 CBC, hereinafter called "tripleDES" [CMSALG]. Receiving with DES EDE3 CBC, hereinafter called "tripleDES" [CMSALG]. Receiving
agents SHOULD support encryption and decryption using the RC2 [CMSALG] agents SHOULD support encryption and decryption using the RC2 [CMSALG]
or a compatible algorithm at a key size of 40 bits, hereinafter called or a compatible algorithm at a key size of 40 bits, hereinafter called
"RC2/40". "RC2/40". Sending and receiving agents SHOULD support encryption and
decryption with AES [CMSAES] at a key size of 128, 192 and 256 bits.
2.7.1 Deciding Which Encryption Method To Use 2.7.1 Deciding Which Encryption Method To Use
When a sending agent creates an encrypted message, it has to decide When a sending agent creates an encrypted message, it has to decide
which type of encryption to use. The decision process involves using which type of encryption to use. The decision process involves using
information garnered from the capabilities lists included in messages information garnered from the capabilities lists included in messages
received from the recipient, as well as out-of-band information such received from the recipient, as well as out-of-band information such
as private agreements, user preferences, legal restrictions, and so as private agreements, user preferences, legal restrictions, and so
on. on.
skipping to change at line 1372 skipping to change at line 1379
B. References B. References
[CERT31] "S/MIME Version 3.1 Certificate Handling", Internet Draft [CERT31] "S/MIME Version 3.1 Certificate Handling", Internet Draft
draft-ietf-smime-rfc2632bis draft-ietf-smime-rfc2632bis
[CHARSETS] Character sets assigned by IANA. See <ftp://ftp.isi.edu/in- [CHARSETS] Character sets assigned by IANA. See <ftp://ftp.isi.edu/in-
notes/iana/assignments/character-sets>. notes/iana/assignments/character-sets>.
[CMS] "Cryptographic Message Syntax", RFC 3369 [CMS] "Cryptographic Message Syntax", RFC 3369
[CMSAES] "Use of the AES Encryption Algorithm in CMS",
draft-ietf-smime-aes-alg-07
[CMSALG] "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370 [CMSALG] "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370
[CMSCOMPR] "Compressed Data Content Type for Cryptographic Message [CMSCOMPR] "Compressed Data Content Type for Cryptographic Message
Syntax (CMS)", RFC 3274 Syntax (CMS)", RFC 3274
[CONTDISP] "Communicating Presentation Information in Internet [CONTDISP] "Communicating Presentation Information in Internet
Messages: The Content-Disposition Header Field", RFC 2183 Messages: The Content-Disposition Header Field", RFC 2183
[DHSUB] "Methods for Avoiding the "Small-Subgroup" Attacks on the [DHSUB] "Methods for Avoiding the "Small-Subgroup" Attacks on the
Diffie-Hellman Key Agreement Method for S/MIME", RFC 2785 Diffie-Hellman Key Agreement Method for S/MIME", RFC 2785
skipping to change at line 1451 skipping to change at line 1461
Blake Ramsdell Blake Ramsdell
Brute Squad Labs Brute Squad Labs
Suite 217-C Suite 217-C
16451 Redmond Way 16451 Redmond Way
Redmond, WA 98052-4482 Redmond, WA 98052-4482
blake@brutesquadlabs.com blake@brutesquadlabs.com
E. Changes from last draft E. Changes from last draft
Several fixes from Russ Housley id-dsa change to id-dsa-with-sha1 (Blake Ramsdell)
http://www.imc.org/ietf-smime/mail-archive/msg01461.html
(Russ Housley) Added AES as a SHOULD (Paul Hoffman)
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/