 1/draftietfsmimecmsalg03.txt 20060205 01:51:20.000000000 +0100
+++ 2/draftietfsmimecmsalg04.txt 20060205 01:51:21.000000000 +0100
@@ 1,18 +1,18 @@
S/MIME Working Group R. Housley
Internet Draft RSA Laboratories
expires in six months August 2001
+expires in six months September 2001
Cryptographic Message Syntax (CMS) Algorithms

+
Status of this Memo
This document is an InternetDraft and is in full conformance with
all provisions of Section 10 of RFC2026. InternetDrafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as InternetDrafts.
InternetDrafts are draft documents valid for a maximum of six months
@@ 63,48 +63,42 @@
3.1 DSA ................................................... 4
3.2 RSA ................................................... 5
4 Key Management Algorithms .................................... 6
4.1 Key Agreement Algorithms .............................. 7
4.1.1 X9.42 EphemeralStatic DiffieHellman ........ 7
4.1.2 X9.42 StaticStatic DiffieHellman ........... 8
4.2 Key Transport Algorithms .............................. 9
4.2.1 RSA (PKCS #1 v1.5) ........................... 10
4.3 Symmetric KeyEncryption Key Algorithms ............... 10
4.3.1 TripleDES Key Wrap .......................... 11
 4.3.2 RC2 Key Wrap ................................. 11
+ 4.3.2 RC2 Key Wrap ................................. 12
4.4 Key Derivation Algorithms ............................. 12
4.4.1 PBKDF2 ....................................... 13
5 Content Encryption Algorithms ................................ 13
 5.1 TripleDES CBC ........................................ 13
+ 5.1 TripleDES CBC ........................................ 14
5.2 RC2 CBC ............................................... 14
 6 Message Authentication Code (MAC) Algorithms ................. 14
 6.1 HMAC with SHA1 ....................................... 14
 7 TripleDES and RC2 Key Wrap Algorithms ....................... 15
 7.1 Key Checksum .......................................... 15
 7.2 TripleDES Key Wrap ................................... 16
 7.3 TripleDES Key Unwrap ................................. 16
 7.4 RC2 Key Wrap .......................................... 17
 7.5 RC2 Key Unwrap ........................................ 17
 Appendix A: ASN.1 Module ........................................ 18
 References ....................................................... 21
 Security Considerations .......................................... 22
 Acknowledgments .................................................. 25
 Author's Address ................................................. 25
 Full Copyright Statement ......................................... 26
+ 6 Message Authentication Code (MAC) Algorithms ................. 15
+ 6.1 HMAC with SHA1 ....................................... 15
+ Appendix A: ASN.1 Module ........................................ 16
+ References ....................................................... 19
+ Security Considerations .......................................... 20
+ Acknowledgments .................................................. 23
+ Author's Address ................................................. 23
+ Full Copyright Statement ......................................... 23
1 Introduction
The Cryptographic Message Syntax (CMS) [CMS] is used to digitally
sign, digest, authenticate, or encrypt arbitrary messages. This
companion specification lists the common cryptographic algorithms.
 CMS implementations MAY support these algorithms; CMS implementations
 MAY support other algorithms as well.
+ Implementations of the CMS MAY support these algorithms;
+ implementations of the CMS MAY support other algorithms as well.
The CMS values are generated using ASN.1 [X.20888], using BER
encoding [X.20988]. Algorithm identifiers (which include ASN.1
object identifiers) identify cryptographic algorithms, and some
algorithms require additional parameters. When needed, parameters
are specified with an ASN.1 structure. The algorithm identifier for
each algorithm is specified, and, when needed, the parameter
structure is specified. The fields in the CMS employed by each
algorithm are identified.
@@ 115,21 +109,21 @@
2 Message Digest Algorithms
This section specifies the conventions employed by CMS
implementations that support SHA1 or MD5.
Digest algorithm identifiers are located in the SignedData
digestAlgorithms field, the SignerInfo digestAlgorithm field, the
DigestedData digestAlgorithm field, and the AuthenticatedData
digestAlgorithm field.
 Digest values are located in the DigestedData digest field the
+ Digest values are located in the DigestedData digest field and the
Message Digest authenticated attribute. In addition, digest values
are input to signature algorithms.
2.1 SHA1
The SHA1 message digest algorithm is defined in FIPS Pub 1801
[SHA1]. The algorithm identifier for SHA1 is:
sha1 OBJECT IDENTIFIER ::= { iso(1) identifiedorganization(3)
oiw(14) secsig(3) algorithm(2) 26 }
@@ 142,21 +136,21 @@
report, but by then many people thought that algorithm parameters
were mandatory. Because of this history some implementations encode
parameters as a NULL element and others omit them entirely. The
correct encoding is to omit the parameters field; however,
implementations MUST also handle a SHA1 AlgorithmIdentifier
parameters field which contains a NULL.
The AlgorithmIdentifier parameters field is OPTIONAL. If present,
the parameters field MUST contain a NULL. Implementations MUST
accept SHA1 AlgorithmIdentifiers with absent parameters.
 Implementations SHOULD accept SHA1 AlgorithmIdentifiers with absent
+ Implementations MUST accept SHA1 AlgorithmIdentifiers with absent
parameters. Implementations SHOULD generate SHA1
AlgorithmIdentifiers with absent parameters.
2.2 MD5
The MD5 digest algorithm is defined in RFC 1321 [MD5]. The algorithm
identifier for MD5 is:
md5 OBJECT IDENTIFIER ::= { iso(1) memberbody(2) us(840)
rsadsi(113549) digestAlgorithm(2) 5 }
@@ 284,21 +278,21 @@
This section specifies the conventions employed by CMS
implementations that support key agreement using X9.42 Ephemeral
Static DiffieHellman (X9.42 ES DH) and X9.42 StaticStatic Diffie
Hellman (X9.42 SS DH).
When a key agreement algorithm is used, a keyencryption algorithm is
also needed. Therefore, when key agreement is supported, a key
encryption algorithm MUST be provided for each contentencryption
algorithm. The key wrap algorithms for TripleDES and RC2 are
 described in section 7.
+ described in RFC [WRAP].
For key agreement of RC2 keyencryption keys, 128 bits MUST be
generated as input to the key expansion process used to compute the
RC2 effective key [RC2].
Key agreement algorithm identifiers are located in the EnvelopedData
RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and
AuthenticatedData RecipientInfos KeyAgreeRecipientInfo
keyEncryptionAlgorithm fields.
@@ 325,34 +319,34 @@
originator MUST be the originatorKey alternative. The
originatorKey algorithm field MUST contain the dhpublicnumber
object identifier with absent parameters. The originatorKey
publicKey field MUST contain the sender's ephemeral public key.
The dhpublicnumber object identifier is:
dhpublicnumber OBJECT IDENTIFIER ::= { iso(1) memberbody(2)
us(840) ansix942(10046) numbertype(2) 1 }
ukm may be present or absent. CMS implementations MUST support
 ukm being absent, and CMS implementations SHOULD support be
+ ukm being absent, and CMS implementations SHOULD support ukm being
present. When present, the ukm is used to ensure that a different
keyencryption key is generated when the ephemeral private key
might be used more than once.
keyEncryptionAlgorithm MUST be the idalgESDH algorithm
identifier. The algorithm identifier parameter field for idalg
ESDH is KeyWrapAlgorithm, and this parameter MUST be present. The
KeyWrapAlgorithm denotes the symmetric encryption algorithm used
to encrypt the contentencryption key with the pairwise key
encryption key generated using the X9.42 EphemeralStatic Diffie
Hellman key agreement algorithm. TripleDES and RC2 key wrap
 algorithms are discussed in section 7. The idalgESDH algorithm
 identifier and parameter syntax is:
+ algorithms are described in RFC [WRAP]. The idalgESDH
+ algorithm identifier and parameter syntax is:
idalgESDH OBJECT IDENTIFIER ::= { iso(1) memberbody(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16)
alg(3) 5 }
KeyWrapAlgorithm ::= AlgorithmIdentifier
recipientEncryptedKeys contains an identifier and an encrypted key
for each recipient. The RecipientEncryptedKey
KeyAgreeRecipientIdentifier MUST contain either the
@@ 369,41 +363,43 @@
StaticStatic DiffieHellman key agreement is defined in RFC 2631
[DHX9.42]. When using StaticStatic DiffieHellman, the
EnvelopedData RecipientInfos KeyAgreeRecipientInfo and
AuthenticatedData RecipientInfos KeyAgreeRecipientInfo fields are
used as follows:
version MUST be 3.
originator MUST be either the issuerAndSerialNumber or
 subjectKeyIdentifier alternative. In both cases, the recipient's
 certificate contains the sender's static public key, and the
 certificate subject public key information field MUST contain the
 dhpublicnumber object identifier is:
+ subjectKeyIdentifier alternative. In both cases, the originator's
+ certificate contains the sender's static public key. RFC
+ [CERTALGS] specifies the AlgorithmIdentifier parameters syntax and
+ values that are included in the originator's certificate. The
+ originator's certificate subject public key information field MUST
+ contain the dhpublicnumber object identifier:
dhpublicnumber OBJECT IDENTIFIER ::= { iso(1) memberbody(2)
us(840) ansix942(10046) numbertype(2) 1 }
ukm MUST be present. The ukm ensures that a different key
encryption key is generated for each message between the same
sender and recipient.
keyEncryptionAlgorithm MUST be the idalgSSDH algorithm
identifier. The algorithm identifier parameter field for idalg
SSDH is KeyWrapAlgorihtm, and this parameter MUST be present. The
KeyWrapAlgorithm denotes the symmetric encryption algorithm used
to encrypt the contentencryption key with the pairwise key
encryption key generated using the X9.42 StaticStatic Diffie
Hellman key agreement algorithm. TripleDES and RC2 key wrap
 algorithms are discussed in section 7. The idalgSSDH algorithm
 identifier and parameter syntax is:
+ algorithms are described in RFC [WRAP]. The idalgSSDH
+ algorithm identifier and parameter syntax is:
idalgSSDH OBJECT IDENTIFIER ::= { iso(1) memberbody(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16)
alg(3) 10 }
KeyWrapAlgorithm ::= AlgorithmIdentifier
recipientEncryptedKeys contains an identifier and an encrypted key
for each recipient. The RecipientEncryptedKey
KeyAgreeRecipientIdentifier MUST contain either the
@@ 452,24 +448,24 @@
information and proposed countermeasures are discussed in the
Security Considerations section of this document and RFC [MMA].
Note that the same RSA encryption scheme is also defined in RFC 2437
[NEWPKCS#1]. Within RFC 2437, this RSA encryption scheme is called
RSAESPKCS1v1_5.
4.3 Symmetric KeyEncryption Key Algorithms
This section specifies the conventions employed by CMS
 implementations support symmetric keyencryption key management using
 TripleDES or RC2 keyencryption keys. When RC2 is supported, RC2
 128bit keys MUST be used as keyencryption keys, and they MUST be
 used with the RC2ParameterVersion parameter set to 58. A CMS
+ implementations that support symmetric keyencryption key management
+ using TripleDES or RC2 keyencryption keys. When RC2 is supported,
+ RC2 128bit keys MUST be used as keyencryption keys, and they MUST
+ be used with the RC2ParameterVersion parameter set to 58. A CMS
implementation MAY support mixed keyencryption and content
encryption algorithms. For example, a 40bit RC2 contentencryption
key MAY be wrapped with 168bit TripleDES keyencryption key or with
a 128bit RC2 keyencryption key.
Key wrap algorithm identifiers are located in the EnvelopedData
RecipientInfos KEKRecipientInfo keyEncryptionAlgorithm and
AuthenticatedData RecipientInfos KEKRecipientInfo
keyEncryptionAlgorithm fields.
@@ 501,22 +497,22 @@
TripleDES key encryption has the algorithm identifier:
idalgCMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) memberbody(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) alg(3) 6 }
The AlgorithmIdentifier parameter field MUST be NULL.
The key wrap algorithm used to encrypt a TripleDES content
encryption key with a TripleDES keyencryption key is specified in
 section 7.2. The corresponding key unwrap algorithm is specified in
 section 7.3.
+ section 3.1 of RFC [WRAP]. The corresponding key unwrap
+ algorithm is specified in section 3.2 of RFC [WRAP].
Outofband distribution of the TripleDES keyencryption key used to
encrypt the TripleDES contentencryption key is beyond of the scope
of this document.
4.3.2 RC2 Key Wrap
A CMS implementation MAY support mixed keyencryption and content
encryption algorithms. For example, a 128bit RC2 contentencryption
key MAY be wrapped with 168bit TripleDES keyencryption key.
@@ 538,22 +534,23 @@
256 is encoded in the RC2ParameterVersion. For the effectivekey
bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120,
and 58 respectively. These values are not simply the RC2 key length.
Note that the value 160 must be encoded as two octets (00 A0),
because the one octet (A0) encoding represents a negative number.
RC2 128bit keys MUST be used as keyencryption keys, and they MUST
be used with the RC2ParameterVersion parameter set to 58.
The key wrap algorithm used to encrypt a RC2 contentencryption key
 with a RC2 keyencryption key is specified in section 7.4. The
 corresponding key unwrap algorithm is specified in section 7.5.
+ with a RC2 keyencryption key is specified in section 4.1 of RFC
+ [WRAP]. The corresponding key unwrap algorithm is specified
+ 4.2 of RFC [WRAP].
Outofband distribution of the RC2 keyencryption key used to
encrypt the RC2 contentencryption key is beyond of the scope of this
document.
4.4 Key Derivation Algorithms
This section specifies the conventions employed by CMS
implementations that support passwordbased key management using
PBKDF2.
@@ 561,21 +558,22 @@
Key derivation algorithms are used to convert a password into a key
encryption key as part of the passwordbased key management
technique.
Key derivation algorithm identifiers are located in the EnvelopedData
RecipientInfos PasswordRecipientInfo keyDerivationAlgorithm and
AuthenticatedData RecipientInfos PasswordRecipientInfo
keyDerivationAlgorithm fields.
The keyencryption key that is derived from the password is used to
 encrypt the contentencryption key
+ encrypt the contentencryption key.
+
The contentencryption keys encrypted with passwordderived key
encryption keys are located in the EnvelopedData RecipientInfos
PasswordRecipientInfo encryptedKey field. The messageauthentication
keys encrypted with passwordderived keyencryption keys are located
in the AuthenticatedData RecipientInfos PasswordRecipientInfo
encryptedKey field.
4.4.1 PBKDF2
The PBKDF2 key derivation algorithm specified in RFC 2898 [PKCS#5].
@@ 684,186 +683,20 @@
from the fact that when the 1988 syntax for AlgorithmIdentifier was
translated into the 1997 syntax the OPTIONAL associated with the
AlgorithmIdentifier parameters got lost. Later the OPTIONAL was
recovered via a defect report, but by then many people thought that
algorithm parameters were mandatory. Because of this history some
implementations encode parameters as a NULL element and others omit
them entirely. CMS implementations that support HMAC with SHA1 MUST
handle both an AlgorithmIdentifier parameters field which contains a
NULL and an AlgorithmIdentifier with an absent parameters.
7 TripleDES and RC2 Key Wrap Algorithms

 This section specifies algorithms for wrapping contentencryption
 keys with TripleDES and RC2 keyencryption keys. Encryption of a
 TripleDES contentencryption key with a TripleDES keyencryption
 key uses the algorithm specified in sections 7.2 and 7.3. Encryption
 of a RC2 contentencryption key with a RC2 keyencryption key uses
 the algorithm specified in sections 7.4 and 7.5. Both of these
 algorithms rely on the key checksum algorithm specified in section
 7.1. TripleDES and RC2 contentencryption keys are encrypted in
 Cipher Block Chaining (CBC) mode [MODES].

 Key Transport algorithms allow for the contentencryption key to be
 directly encrypted; however, key agreement and symmetric key
 encryption key algorithms encrypt the contentencryption key with a
 second symmetric encryption algorithm. This section describes how
 the TripleDES or RC2 contentencryption key is formatted and
 encrypted.

 Key agreement algorithms generate a pairwise keyencryption key, and
 a key wrap algorithm is used to encrypt the contentencryption key
 with the pairwise keyencryption key. Similarly, a key wrap
 algorithm is used to encrypt the contentencryption key in a
 previously distributed keyencryption key.

 The keyencryption key is generated by the key agreement algorithm or
 distributed out of band. For key agreement of RC2 keyencryption
 keys, 128 bits MUST be generated as input to the key expansion
 process used to compute the RC2 effective key [RC2].

 The same algorithm identifier is used for both Twokey TripleDES and
 Threekey TripleDES. When the length of the contentencryption key
 to be wrapped is a Twokey TripleDES key, a third key with the same
 value as the first key is created. Thus, all TripleDES content
 encryption keys are wrapped like Threekey TripleDES keys. However,
 a Twokey TripleDES key MUST NOT be used to wrap a Threekey Triple
 DES key.

7.1 Key Checksum

 The CMS Key Checksum Algorithm is used to provide a content
 encryption key integrity check value. The algorithm is:

 1. Compute a 20 octet SHA1 [SHA1] message digest on the
 contentencryption key.
 2. Use the most significant (first) eight octets of the message
 digest value as the checksum value.

7.2 TripleDES Key Wrap

 The TripleDES key wrap algorithm encrypts a TripleDES content
 encryption key with a TripleDES keyencryption key. The TripleDES
 key wrap algorithm is:

 1. Set odd parity for each of the DES key octets comprising
 the contentencryption key, call the result CEK.
 2. Compute an 8 octet key checksum value on CEK as described above
 in Section 7.1, call the result ICV.
 3. Let CEKICV = CEK  ICV.
 4. Generate 8 octets at random, call the result IV.
 5. Encrypt CEKICV in CBC mode using the keyencryption key. Use
 the random value generated in the previous step as the
 initialization vector (IV). Call the ciphertext TEMP1.
 6. Let TEMP2 = IV  TEMP1.
 7. Reverse the order of the octets in TEMP2. That is, the most
 significant (first) octet is swapped with the least significant
 (last) octet, and so on. Call the result TEMP3.
 8. Encrypt TEMP3 in CBC mode using the keyencryption key. Use
 an initialization vector (IV) of 0x4adda22c79e82105.
 The ciphertext is 40 octets long.

 Note: When the same contentencryption key is wrapped in different
 keyencryption keys, a fresh initialization vector (IV) must be
 generated for each invocation of the key wrap algorithm.

7.3 TripleDES Key Unwrap

 The TripleDES key unwrap algorithm decrypts a TripleDES content
 encryption key using a TripleDES keyencryption key. The TripleDES
 key unwrap algorithm is:

 1. If the wrapped contentencryption key is not 40 octets, then
 error.
 2. Decrypt the wrapped contentencryption key in CBC mode using
 the keyencryption key. Use an initialization vector (IV)
 of 0x4adda22c79e82105. Call the output TEMP3.
 3. Reverse the order of the octets in TEMP3. That is, the most
 significant (first) octet is swapped with the least significant
 (last) octet, and so on. Call the result TEMP2.
 4. Decompose the TEMP2 into IV and TEMP1. IV is the most
 significant (first) 8 octets, and TEMP1 is the least significant
 (last) 32 octets.
 5. Decrypt TEMP1 in CBC mode using the keyencryption key. Use
 the IV value from the previous step as the initialization vector.
 Call the ciphertext CEKICV.
 6. Decompose the CEKICV into CEK and ICV. CEK is the most significant
 (first) 24 octets, and ICV is the least significant (last) 8 octets.
 7. Compute an 8 octet key checksum value on CEK as described above
 in Section 7.1. If the computed key checksum value does not
 match the decrypted key checksum value, ICV, then error.
 8. Check for odd parity each of the DES key octets comprising CEK.
 If parity is incorrect, then there is an error.
 9. Use CEK as the contentencryption key.

7.4 RC2 Key Wrap

 The RC2 key wrap algorithm encrypts a RC2 contentencryption key with
 a RC2 keyencryption key. The RC2 key wrap algorithm is:

 1. Let the contentencryption key be called CEK, and let the length
 of the contentencryption key in octets be called LENGTH. LENGTH
 is a single octet.
 2. Let LCEK = LENGTH  CEK.
 3. Let LCEKPAD = LCEK  PAD. If the length of LCEK is a multiple
 of 8, the PAD has a length of zero. If the length of LCEK is
 not a multiple of 8, then PAD contains the fewest number of
 random octets to make the length of LCEKPAD a multiple of 8.
 4. Compute an 8 octet key checksum value on LCEKPAD as described
 above in Section 7.1, call the result ICV.

 5. Let LCEKPADICV = LCEKPAD  ICV.
 6. Generate 8 octets at random, call the result IV.
 7. Encrypt LCEKPADICV in CBC mode using the keyencryption key.
 Use the random value generated in the previous step as the
 initialization vector (IV). Call the ciphertext TEMP1.
 8. Let TEMP2 = IV  TEMP1.
 9. Reverse the order of the octets in TEMP2. That is, the most
 significant (first) octet is swapped with the least significant
 (last) octet, and so on. Call the result TEMP3.
 10. Encrypt TEMP3 in CBC mode using the keyencryption key. Use
 an initialization vector (IV) of 0x4adda22c79e82105.

 Note: When the same contentencryption key is wrapped in different
 keyencryption keys, a fresh initialization vector (IV) must be
 generated for each invocation of the key wrap algorithm.

7.5 RC2 Key Unwrap

 The RC2 key unwrap algorithm decrypts a RC2 contentencryption key
 using a RC2 keyencryption key. The RC2 key unwrap algorithm is:

 1. If the wrapped contentencryption key is not a multiple of 8
 octets, then error.
 2. Decrypt the wrapped contentencryption key in CBC mode using
 the keyencryption key. Use an initialization vector (IV)
 of 0x4adda22c79e82105. Call the output TEMP3.
 3. Reverse the order of the octets in TEMP3. That is, the most
 significant (first) octet is swapped with the least significant
 (last) octet, and so on. Call the result TEMP2.
 4. Decompose the TEMP2 into IV and TEMP1. IV is the most
 significant (first) 8 octets, and TEMP1 is the remaining octets.
 5. Decrypt TEMP1 in CBC mode using the keyencryption key. Use
 the IV value from the previous step as the initialization vector.
 Call the plaintext LCEKPADICV.
 6. Decompose the LCEKPADICV into LCEKPAD, and ICV. ICV is the
 least significant (last) octet 8 octets. LCEKPAD is the
 remaining octets.
 7. Compute an 8 octet key checksum value on LCEKPAD as described
 above in Section 7.1. If the computed key checksum value does
 not match the decrypted key checksum value, ICV, then error.
 8. Decompose the LCEKPAD into LENGTH, CEK, and PAD. LENGTH is the
 most significant (first) octet. CEK is the following LENGTH
 octets. PAD is the remaining octets, if any.
 9. If the length of PAD is more than 7 octets, then error.
 10. Use CEK as the contentencryption key.

Appendix A: ASN.1 Module
CryptographicMessageSyntaxAlgorithms
{ iso(1) memberbody(2) us(840) rsadsi(113549)
pkcs(1) pkcs9(9) smime(16) modules(0) cmsalg2001(16) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
 EXPORTS All
@@ 982,22 +815,27 @@
prf AlgorithmIdentifier
DEFAULT { algorithm hMACSHA1, parameters NULL } }
END  of CryptographicMessageSyntaxAlgorithms
References
3DES American National Standards Institute. ANSI X9.521998,
Triple Data Encryption Algorithm Modes of Operation. 1998.
 CMS Housley, R. Cryptographic Message Syntax. RFC . .
 {draftietfsmimerfc2630bis*.txt}
+ CERTALGS Bassham, L., R. Housley, and W. Polk. Algorithms and
+ Identifiers for the Internet X.509 Public Key
+ Infrastructure Certificate and CRL Profile. RFC .
+ . {draftietfpkixipkipkalgs03.txt}
+
+ CMS Housley, R. Cryptographic Message Syntax. RFC .
+ . {draftietfsmimerfc2630bis*.txt}
DES American National Standards Institute. ANSI X3.106,
"American National Standard for Information Systems  Data
Link Encryption". 1983.
DHX9.42 Rescorla, E. DiffieHellman Key Agreement Method.
RFC 2631. June 1999.
DSS National Institute of Standards and Technology.
FIPS Pub 186: Digital Signature Standard. 19 May 1994.
@@ 1033,20 +870,23 @@
RC2 Rivest, R. A Description of the RC2 (r) Encryption Algorithm.
RFC 2268. March 1998.
SHA1 National Institute of Standards and Technology.
FIPS Pub 1801: Secure Hash Standard. 17 April 1995.
STDWORDS Bradner, S. Key Words for Use in RFCs to Indicate
Requirement Levels. RFC2119. March 1997.
+ WRAP Housley, R. TripleDES and RC2 Key Wrapping. RFC .
+ . {draftietfsmimekeywrap*.txt}
+
X.20888 CCITT. Recommendation X.208: Specification of Abstract
Syntax Notation One (ASN.1). 1988.
X.20988 CCITT. Recommendation X.209: Specification of Basic Encoding
Rules for Abstract Syntax Notation One (ASN.1). 1988.
Security Considerations
The CMS provides a method for digitally signing data, digesting data,
encrypting data, and authenticating data. This document identifies
@@ 1104,24 +944,24 @@
contentencryption algorithms are different, the effective security
is determined by the weaker of the two algorithms. If, for example,
a message content is encrypted with 168bit TripleDES and the
TripleDES contentencryption key is wrapped with a 40bit RC2 key,
then at most 40 bits of protection is provided. A trivial search to
determine the value of the 40bit RC2 key can recover TripleDES key,
and then the TripleDES key can be used to decrypt the content.
Therefore, implementers must ensure that keyencryption algorithms
are as strong or stronger than contentencryption algorithms.
 Section 7 specifies key wrap algorithms used to encrypt a TripleDES
 [3DES] contentencryption key with a TripleDES keyencryption key or
 to encrypt a RC2 [RC2] contentencryption key with a RC2 key
 encryption key. The key wrap algorithms make use of CBC mode
+ RFC [WRAP] specifies key wrap algorithms used to encrypt a
+ TripleDES contentencryption key with a TripleDES keyencryption
+ key [3DES] or to encrypt a RC2 contentencryption key with a RC2 key
+ encryption key [RC2]. The key wrap algorithms makes use of CBC mode
[MODES]. These key wrap algorithms have been reviewed for use with
TripleDES and RC2. They have not been reviewed for use with other
cryptographic modes or other encryption algorithms. Therefore, if a
CMS implementation wishes to support ciphers in addition to Triple
DES or RC2, then additional key wrap algorithms need to be defined to
support the additional ciphers.
Implementers should be aware that cryptographic algorithms become
weaker with time. As new cryptanalysis techniques are developed and
computing performance improves, the work factor to break a particular