 1/draftietfsmimecmsalg00.txt 20060205 01:51:18.000000000 +0100
+++ 2/draftietfsmimecmsalg01.txt 20060205 01:51:18.000000000 +0100
@@ 1,17 +1,18 @@
+
S/MIME Working Group R. Housley
Internet Draft RSA Laboratories
expires in six months April 2001
+expires in six months July 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
@@ 31,21 +32,21 @@
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract
This document describes cryptographic algorithms for use with the
Cryptographic Message Syntax (CMS) [CMS]. CMS is used to digitally
sign, digest, authenticate, or encrypt arbitrary messages.
Once approved, this draft will obsolete section 12 of RFC 2630. The
 companion document (draftietfsmimerfc2630bis00.txt) will obsolete
+ companion document (draftietfsmimerfc2630bis02.txt) will obsolete
the rest of RFC 2630. Separation of the protocol and algorithm
specifications allows the IETF to select different mandatory to
implement algorithms in the future without reissuing the protocol
document.
This draft is being discussed on the "ietfsmime" mailing list. To
join the list, send a message to with
the single word "subscribe" in the body of the message. Also, there
is a Web site for the mailing list at .
@@ 63,20 +64,22 @@
3.1 DSA ................................................... 36
3.2 RSA ................................................... 36
4 Key Management Algorithms .................................... 36
4.1 Key Agreement Algorithms .............................. 36
4.1.1 X9.42 EphemeralStatic DiffieHellman ........ 37
4.2 Key Transport Algorithms .............................. 38
4.2.1 RSA .......................................... 39
4.3 Symmetric KeyEncryption Key Algorithms ............... 39
4.3.1 TripleDES Key Wrap .......................... 40
4.3.2 RC2 Key Wrap ................................. 41
+ 4.4 Key Derivation Algorithms ............................. 41
+ 4.4.1 PBKDF2 ....................................... 41
5 Content Encryption Algorithms ................................ 41
5.1 TripleDES CBC ........................................ 42
5.2 RC2 CBC ............................................... 42
6 Message Authentication Code (MAC) Algorithms ................. 42
6.1 HMAC with SHA1 ....................................... 43
7 TripleDES and RC2 Key Wrap Algorithms ....................... 43
7.1 Key Checksum .......................................... 44
7.2 TripleDES Key Wrap ................................... 44
7.3 TripleDES Key Unwrap ................................. 44
7.4 RC2 Key Wrap .......................................... 45
@@ 90,198 +93,235 @@
1 Introduction
The Cryptographic Message Syntax (CMS) [CMS] is used to digitally
sign, digest, authenticate, or encrypt arbitrary messages. This
companion specification lists the algorithms that MUST be supported
by CMS implementations. It also lists algorithms that SHOULD be
supported by CMS implementations. Of course, CMS implementations MAY
support other algorithms as well.
 Table 1 summarizes the algorithms that CMS implantations MUST support
 and SHOULD support.
+ Table 1 summarizes the algorithms that CMS implementations MUST
+ support and SHOULD support.
The CMS values are generated using ASN.1 [X.20888], using BER
 encoding [X.20988]. Algorithm are be identified by algorithm
+ encoding [X.20988]. Algorithm are identified by algorithm
identifiers (ASN.1 object identifiers), and some algorithms require
additional parameters. When needed, parameters are specified with an
 ASN.1 structure. The algorithm identifiers for each algorithm are
+ 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.
 In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD,
 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as
 described by Scott Bradner in [STDWORDS].

 Table 1. CMS Implantation Algorithm Requirements
+ Table 1. CMS Implementation Algorithm Requirements
Algorithm Type MUST implement SHOULD implement

Message Digest SHA1 MD5
 Signature DSA and RSA (*) 
+ Signature DSA and RSA (1,2) 
Key Management
Key Agreement  X9.42 ES DH
Key Transport RSA 
Symmetric KEK Wrap TripleDES Key Wrap RC2 Key Wrap
+ Key Derivation PBKDF2 (3) 
Content Encryption TripleDES CBC RC2 CBC
 Message Authentication HMAC with SHA1 
+ Message Authentication HMAC with SHA1 (4) 
 (*) Note: CMS implementations MUST be able to verify signatures
 with both DSA and RSA, and they MUST be able to
 generate signatures with at least one of them.
+ Note 1: CMS implementations MUST be able to verify signatures
+ with both DSA and RSA (PKCS #1 v1.5), and they MUST be
+ able to generate signatures with at least one of them.
+
+ Note 2: CMS implementations MUST support RSA (PKCS #1 v1.5) with
+ SHA1. CMS implementations SHOULD support RSA
+ (PKCS #1 v1.5) with MD5.
+
+ Note 3: Only those CMS implementations that support password
+ based key management MUST implement the PBKDF2 key
+ derivation algorithm as specified in RFC 2898 [PKCS#5].
+
+ Note 4: Only those CMS implementations that support
+ authenticateddata MUST implement the HMAC with SHA1
+ algorithm as specified in RFC 2104 [HMAC].
+
+ In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD,
+ SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as
+ described by Scott Bradner in [STDWORDS].
2 Message Digest Algorithms
CMS implementations MUST support SHA1. CMS implementations SHOULD
support 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, and
 digest values are located in the Message Digest authenticated
 attribute. In addition, digest values are input to signature
 algorithms.
+ Digest values are located in the DigestedData digest field the
+ Message Digest authenticated attribute. In addition, digest values
+ are input to signature algorithms.
2.1 SHA1
The SHA1 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 }
The AlgorithmIdentifier parameters field is OPTIONAL. If present,
the parameters field MUST contain an ASN.1 NULL. Implementations
SHOULD accept SHA1 AlgorithmIdentifiers with absent parameters as
well as NULL parameters. Implementations SHOULD generate SHA1
 AlgorithmIdentifiers with NULL parameters.
+ 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 }
The AlgorithmIdentifier parameters field MUST be present, and the
parameters field MUST contain NULL. Implementations MAY accept the
MD5 AlgorithmIdentifiers with absent parameters as well as NULL
parameters.
3 Signature Algorithms
 CMS implementations MUST support both DSA and RSA. CMS
 implementations MUST be able to verify signatures with both DSA and
 RSA. CMS implementations MUST be able to generate signatures with
 either DSA or RSA. CMS implementations MAY be able to generate
 signatures with both DSA and RSA.
+ CMS implementations MUST support both DSA and RSA (PKCS #1 v1.5).
+ CMS implementations MUST be able to verify signatures with both DSA
+ and RSA (PKCS #1 v1.5). CMS implementations MUST be able to generate
+ signatures with either DSA or RSA (PKCS #1 v1.5). CMS
+ implementations MAY be able to generate signatures with both DSA and
+ RSA (PKCS #1 v1.5).
Signature algorithm identifiers are located in the SignerInfo
 signatureAlgorithm field. Also, signature algorithm identifiers are
 located in the SignerInfo signatureAlgorithm field of
+ signatureAlgorithm field of SignedData. Also, signature algorithm
+ identifiers are located in the SignerInfo signatureAlgorithm field of
countersignature attributes.
 Signature values are located in the SignerInfo signature field.
 Also, signature values are located in the SignerInfo signature field
 of countersignature attributes.
+ Signature values are located in the SignerInfo signature field of
+ SignedData. Also, signature values are located in the SignerInfo
+ signature field of countersignature attributes.
3.1 DSA
The DSA signature algorithm is defined in FIPS Pub 186 [DSS]. DSA is
 always used with the SHA1 message digest algorithm. The algorithm
 identifier for DSA is:
+ always used with the SHA1 message digest algorithm.
+
+ The algorithm identifier for DSA subject public keys in certificates
+ is:
+
+ iddsa OBJECT IDENTIFIER ::= { iso(1) memberbody(2)
+ us(840) x957 (10040) x9cm(4) 1 }
+
+ DSA signature validation requires three parameters, commonly called
+ p, q, and g. When the iddsa algorithm identifier is used,
+ AlgorithmIdentifier parameters field is optional. If present, the
+ AlgorithmIdentifier parameters field MUST contain the three DSA
+ parameter values encoded using the DssParms type. If absent, the
+ subject DSA public key uses the same DSA parameters as the
+ certificate issuer.
+
+ DssParms ::= SEQUENCE {
+ p INTEGER,
+ q INTEGER,
+ g INTEGER }
+
+ When the iddsa algorithm identifier is used, the DSA public key, commonly called Y, MUST be encoded as an INTEGER. The output of this encoding is carried in the certificate subject public key.
+
+ DssPubKey ::= INTEGER  Y
+
+ The algorithm identifier for DSA with SHA1 signature values is:
iddsawithsha1 OBJECT IDENTIFIER ::= { iso(1) memberbody(2)
us(840) x957 (10040) x9cm(4) 3 }
 The AlgorithmIdentifier parameters field MUST NOT be present.
+ When the iddsawithsha1 algorithm identifier is used,
+ AlgorithmIdentifier parameters field MUST be absent.
+
+ When signing, the DSA algorithm generates two values, commonly called
+ r and s. To transfer these two values as one signature, they MUST be
+ encoded using the DssSigValue type:
+
+ DssSigValue ::= SEQUENCE {
+ r INTEGER,
+ s INTEGER }
3.2 RSA
The RSA signature algorithm is defined in RFC 2437 [NEWPKCS#1]. RFC
2437 specifies the use of the RSA signature algorithm with the SHA1
 and MD5 message digest algorithms. The algorithm identifier for RSA
+ and MD5 message digest algorithms.
+
+ The algorithm identifier for RSA subject public keys in certificates
is:
rsaEncryption OBJECT IDENTIFIER ::= { iso(1) memberbody(2)
us(840) rsadsi(113549) pkcs(1) pkcs1(1) 1 }
 CMS implementations MUST support RSA with SHA1. CMS implementations
 SHOULD support RSA with MD5.
+ When the rsaEncryption algorithm identifier is used,
+ AlgorithmIdentifier parameters field MUST contain NULL.
+
+ When the rsaEncryption algorithm identifier is used, the RSA public
+ key, which is composed of a modulus and a public exponent, MUST be
+ encoded using the RSAPublicKey type. The output of this encoding is
+ carried in the certificate subject public key.
+
+ RSAPublicKey ::= SEQUENCE {
+ modulus INTEGER,  n
+ publicExponent INTEGER }  e
+
+ CMS implementations MUST support RSA (PKCS #1 v1.5) with SHA1. CMS implementations SHOULD support RSA (PKCS #1 v1.5) with MD5.
+
+ The algorithm identifier for RSA (PKCS #1 v1.5) with SHA1 signature values is:
+
+ sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) memberbody(2)
+ us(840) rsadsi(113549) pkcs(1) pkcs1(1) 5 }
+
+ The algorithm identifier for RSA (PKCS #1 v1.5) with MD5 signature values is:
+
+ md5WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) memberbody(2)
+ us(840) rsadsi(113549) pkcs(1) pkcs1(1) 4 }
+
+ When either the sha1WithRSAEncryption algorithm identifier or the md5WithRSAEncryption algorithm identifier is used, AlgorithmIdentifier parameters field MUST be NULL.
+
+ When signing, the RSA algorithm generates a single value, and that value is used directly as the signature value.
4 Key Management Algorithms
 CMS accommodates three general key management techniques: key
 agreement, key transport, and previously distributed symmetric key
 encryption keys.
+ CMS accommodates the following general key management techniques: key agreement, key transport, previously distributed symmetric keyencryption keys, and passwords.
4.1 Key Agreement Algorithms
 CMS implementations SHOULD support key agreement using X9.42
 EphemeralStatic DiffieHellman (X9.42 ES DH).
+ CMS implementations SHOULD support key agreement using X9.42 EphemeralStatic DiffieHellman (X9.42 ES DH).
 Any symmetric encryption algorithm that a CMS implementation includes
 as a contentencryption algorithm MUST also be included as a key
 encryption algorithm. CMS implementations SHOULD include key
 agreement of TripleDES pairwise keyencryption keys. CMS
 implementations SHOULD include key agreement of RC2 pairwise key
 encryption keys. CMS implementations MUST include TripleDES
 wrapping of TripleDES contentencryption keys and RC2 wrapping of
 RC2 contentencryption keys. The key wrap algorithms for TripleDES
 and RC2 are described in section 7.
+ Any symmetric encryption algorithm that a CMS implementation includes as a contentencryption algorithm MUST also be included as a keyencryption algorithm. CMS implementations SHOULD include key agreement of TripleDES pairwise keyencryption keys. CMS implementations SHOULD include key agreement of RC2 pairwise keyencryption keys. CMS implementations MUST include TripleDES wrapping of TripleDES contentencryption keys, and CMS implementations SHOULD include RC2 wrapping of RC2 contentencryption keys. The key wrap algorithms for TripleDES and RC2 are described in section 7.
 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.
 Similarly, a 40bit RC2 contentencryption key MAY be wrapped with
 128bit RC2 keyencryption key.
+ A CMS implementation MAY support mixed keyencryption and contentencryption algorithms. For example, a 128bit RC2 contentencryption key MAY be wrapped with 168bit TripleDES keyencryption key. Similarly, a 40bit RC2 contentencryption key MAY be wrapped with 128bit RC2 keyencryption key.
 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].
+ 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.
+ Key agreement algorithm identifiers are located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and AuthenticatedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm fields.
 Key wrap algorithm identifiers are located in the KeyWrapAlgorithm
 parameters within the EnvelopedData RecipientInfos
 KeyAgreeRecipientInfo keyEncryptionAlgorithm and AuthenticatedData
 RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm fields.
+ Key wrap algorithm identifiers are located in the KeyWrapAlgorithm parameters within the EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and AuthenticatedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm fields.
 Wrapped contentencryption keys are located in the EnvelopedData
 RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys
 encryptedKey field. Wrapped messageauthentication keys are located
 in the AuthenticatedData RecipientInfos KeyAgreeRecipientInfo
 RecipientEncryptedKeys encryptedKey field.
+ Wrapped contentencryption keys are located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey field. Wrapped messageauthentication keys are located in the AuthenticatedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey field.
4.1.1 X9.42 EphemeralStatic DiffieHellman
 EphemeralStatic DiffieHellman key agreement is defined in RFC 2631
 [DHX9.42]. When using EphemeralStatic DiffieHellman, the
 EnvelopedData RecipientInfos KeyAgreeRecipientInfo and
 AuthenticatedData RecipientInfos KeyAgreeRecipientInfo fields are
 used as follows:
+ EphemeralStatic DiffieHellman key agreement is defined in RFC 2631 [DHX9.42]. When using EphemeralStatic DiffieHellman, the EnvelopedData RecipientInfos KeyAgreeRecipientInfo and AuthenticatedData RecipientInfos KeyAgreeRecipientInfo fields are used as follows:
version MUST be 3.
 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:
+ 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 absent. 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
@@ 305,24 +345,24 @@
the RecipientKeyIdentifier containing the subject key identifier
from the recipient's certificate. In both cases, the recipient's
certificate contains the recipient's static public key.
RecipientEncryptedKey EncryptedKey MUST contain the content
encryption key encrypted with the X9.42 EphemeralStatic Diffie
Hellman generated pairwise keyencryption key using the algorithm
specified by the KeyWrapAlgortihm.
4.2 Key Transport Algorithms
 CMS implementations MUST support key transport using RSA. RSA
 implementations MUST support key transport of TripleDES content
 encryption keys. RSA implementations SHOULD support key transport of
 RC2 contentencryption keys.
+ CMS implementations MUST support key transport using RSA (PKCS #1
+ v1.5). RSA implementations MUST support key transport of TripleDES
+ contentencryption keys. RSA implementations SHOULD support key
+ transport of RC2 contentencryption keys.
Key transport algorithm identifiers are located in the EnvelopedData
RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm and
AuthenticatedData RecipientInfos KeyTransRecipientInfo
keyEncryptionAlgorithm fields.
Key transport encrypted contentencryption keys are located in the
EnvelopedData RecipientInfos KeyTransRecipientInfo encryptedKey
field. Key transport encrypted messageauthentication keys are
located in the AuthenticatedData RecipientInfos KeyTransRecipientInfo
@@ 330,27 +370,26 @@
4.2.1 RSA
The RSA key transport algorithm is the RSA encryption scheme defined
in RFC 2313 [PKCS#1], block type is 02, where the message to be
encrypted is the contentencryption key. The algorithm identifier
for RSA is:
rsaEncryption OBJECT IDENTIFIER ::= { iso(1) memberbody(2)
us(840) rsadsi(113549) pkcs(1) pkcs1(1) 1 }

The AlgorithmIdentifier parameters field must be present, and the
parameters field must contain NULL.
When using a TripleDES contentencryption key, CMS implementations
MUST adjust the parity bits for each DES key comprising the Triple
 DES key prior to RSA encryption.
+ DES key prior to RSA (PKCS #1 v1.5) encryption.
The use of RSA encryption, as defined in RFC 2313 [PKCS#1], to
provide confidentiality has a known vulnerability. The vulnerability
is primarily relevant to usage in interactive applications rather
than to storeandforward environments. Further information and
proposed countermeasures are discussed in the Security Considerations
section of this document and RFC [MMA].
Note that the same encryption scheme is also defined in RFC 2437
[NEWPKCS#1]. Within RFC 2437, this scheme is called RSAES
@@ 413,21 +452,21 @@
encrypt the TripleDES contentencryption key is beyond of the scope
of this document.
4.3.2 RC2 Key Wrap
RC2 key encryption has the algorithm identifier:
idalgCMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) memberbody(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) alg(3) 7 }
 The AlgorithmIdentifier parameter field must be RC2wrapParameter:
+ The AlgorithmIdentifier parameter field MUST be RC2wrapParameter:
RC2wrapParameter ::= RC2ParameterVersion
RC2ParameterVersion ::= INTEGER
The RC2 effectivekeybits (key size) greater than 32 and less than
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),
@@ 437,24 +476,68 @@
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.
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
+
+ Key derivation algorithms are used to convert a password into a key
+ encryption key as part of the passwordbased key management
+ technique. CMS implementations that support the passwordbased key
+ management technique MUST implement the PBKDF2 key derivation
+ algorithm specified in RFC 2898 [PKCS#5].
+
+ 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
+
+ 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].
+ The KeyDerivationAlgorithmIdentifer identifies the keyderivation
+ algorithm, and any associated parameters, used to derive the key
+ encryption key from the usersupplied password. The algorithm
+ identifier for the PBKDF2 key derivation algorithm is:
+
+ idPBKDF2 OBJECT IDENTIFIER ::= { iso(1) memberbody(2) us(840)
+ rsadsi(113549) pkcs(1) pkcs5(5) 12 }
+
+ The AlgorithmIdentifier parameter field MUST be PBKDF2params:
+
+ PBKDF2params ::= SEQUENCE {
+ salt CHOICE {
+ specified OCTET STRING,
+ otherSource AlgorithmIdentifier },
+ iterationCount INTEGER (1..MAX),
+ keyLength INTEGER (1..MAX) OPTIONAL,
+ prf AlgorithmIdentifier DEFAULT hMACSHA1 }
+
5 Content Encryption Algorithms
CMS implementations MUST support ThreeKey TripleDES in CBC mode.
 MS implementations SHOULD support TwoKey TripleDES in CBC mode.
+ CMS implementations SHOULD support TwoKey TripleDES in CBC mode.
CMS implementations SHOULD support RC2 in CBC mode.
Content encryption algorithms identifiers are located in the
EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm and the
EncryptedData EncryptedContentInfo contentEncryptionAlgorithm fields.
Content encryption algorithms are used to encipher the content
located in the EnvelopedData EncryptedContentInfo encryptedContent
field and the EncryptedData EncryptedContentInfo encryptedContent
field.
@@ 570,21 +653,21 @@
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 12.6.1, call the result ICV.
+ 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
@@ 611,41 +694,41 @@
(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 12.6.1. If the computed key checksum value does not
+ 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 12.6.1, call the result ICV.
+ 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
@@ 670,22 +753,22 @@
(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 12.6.1. If the computed key checksum value
 does not match the decrypted key checksum value, ICV, then error.
+ 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)
@@ 702,62 +785,113 @@
 IMPORTS None
 Algorithm Identifiers
sha1 OBJECT IDENTIFIER ::= { iso(1) identifiedorganization(3)
oiw(14) secsig(3) algorithm(2) 26 }
md5 OBJECT IDENTIFIER ::= { iso(1) memberbody(2) us(840)
rsadsi(113549) digestAlgorithm(2) 5 }
+ iddsa OBJECT IDENTIFIER ::= { iso(1) memberbody(2) us(840)
+ x957(10040) x9cm(4) 1 }
+
iddsawithsha1 OBJECT IDENTIFIER ::= { iso(1) memberbody(2)
us(840) x957 (10040) x9cm(4) 3 }
rsaEncryption OBJECT IDENTIFIER ::= { iso(1) memberbody(2)
us(840) rsadsi(113549) pkcs(1) pkcs1(1) 1 }
+ md5WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1)
+ memberbody(2) us(840) rsadsi(113549) pkcs(1) pkcs1(1) 4 }
+
+ sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1)
+ memberbody(2) us(840) rsadsi(113549) pkcs(1) pkcs1(1) 5 }
+
dhpublicnumber OBJECT IDENTIFIER ::= { iso(1) memberbody(2)
us(840) ansix942(10046) numbertype(2) 1 }
idalgESDH OBJECT IDENTIFIER ::= { iso(1) memberbody(2) us(840)
rsadsi(113549) pkcs(1) pkcs9(9) smime(16) alg(3) 5 }
idalgCMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) memberbody(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) alg(3) 6 }

idalgCMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) memberbody(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) alg(3) 7 }
desede3cbc OBJECT IDENTIFIER ::= { iso(1) memberbody(2)
us(840) rsadsi(113549) encryptionAlgorithm(3) 7 }
rc2cbc OBJECT IDENTIFIER ::= { iso(1) memberbody(2) us(840)
rsadsi(113549) encryptionAlgorithm(3) 2 }
+
hMACSHA1 OBJECT IDENTIFIER ::= { iso(1) identifiedorganization(3)
dod(6) internet(1) security(5) mechanisms(5) 8 1 2 }
  Algorithm Parameters
+ idPBKDF2 OBJECT IDENTIFIER ::= { iso(1) memberbody(2) us(840)
+ rsadsi(113549) pkcs(1) pkcs5(5) 12 }
+
+  Public Key Types
+
+ DssPubKey ::= INTEGER  Y
+
+ RSAPublicKey ::= SEQUENCE {
+ modulus INTEGER,  n
+ publicExponent INTEGER }  e
+
+ DHPublicKey ::= INTEGER  y = g^x mod p
+
+  Signature Value Types
+
+ DssSigValue ::= SEQUENCE {
+ r INTEGER,
+ s INTEGER }
+
+  Algorithm Identifier Parameter Types
+
+ DssParms ::= SEQUENCE {
+ p INTEGER,
+ q INTEGER,
+ g INTEGER }
+
+ DHDomainParameters ::= SEQUENCE {
+ p INTEGER,  odd prime, p=jq +1
+ g INTEGER,  generator, g
+ q INTEGER,  factor of p1
+ j INTEGER OPTIONAL,  subgroup factor
+ validationParms ValidationParms OPTIONAL }
+ ValidationParms ::= SEQUENCE {
+ seed BIT STRING,
+ pgenCounter INTEGER }
KeyWrapAlgorithm ::= AlgorithmIdentifier
RC2wrapParameter ::= RC2ParameterVersion
RC2ParameterVersion ::= INTEGER
CBCParameter ::= IV
IV ::= OCTET STRING  exactly 8 octets
RC2CBCParameter ::= SEQUENCE {
rc2ParameterVersion INTEGER,
iv OCTET STRING }  exactly 8 octets
+ PBKDF2params ::= SEQUENCE {
+ salt CHOICE {
+ specified OCTET STRING,
+ otherSource AlgorithmIdentifier },
+ iterationCount INTEGER (1..MAX),
+ keyLength INTEGER (1..MAX) OPTIONAL,
+ prf AlgorithmIdentifier DEFAULT hMACSHA1 }
+
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}
@@ 782,20 +916,23 @@
MODES National Institute of Standards and Technology.
FIPS Pub 81: DES Modes of Operation. 2 December 1980.
NEWPKCS#1 Kaliski, B., and J. Staddon. PKCS #1: RSA Encryption,
Version 2.0. RFC 2437. October 1998.
PKCS#1 Kaliski, B. PKCS #1: RSA Encryption, Version 1.5.
RFC 2313. March 1998.
+ PKCS#5 Kaliski, B. PKCS #5: PasswordBased Cryptography
+ Specification, Version 2.0. RFC 2898. September 2000.
+
RANDOM Eastlake, D., S. Crocker, and J. Schiller. Randomness
Recommendations for Security. RFC 1750. December 1994.
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
@@ 882,32 +1019,20 @@
support the additional ciphers.
Implementers should be aware that cryptographic algorithms become
weaker with time. As new cryptoanalysis techniques are developed and
computing performance improves, the work factor to break a particular
cryptographic algorithm will reduce. Therefore, cryptographic
algorithm implementations should be modular allowing new algorithms
to be readily inserted. That is, implementers should be prepared for
the set of mandatory to implement algorithms to change over time.
 The countersignature unauthenticated attribute includes a digital
 signature that is computed on the content signature value, thus the
 countersigning process need not know the original signed content.
 This structure permits implementation efficiency advantages; however,
 this structure may also permit the countersigning of an inappropriate
 signature value. Therefore, implementations that perform
 countersignatures should either verify the original signature value
 prior to countersigning it (this verification requires processing of
 the original content), or implementations should perform
 countersigning in a context that ensures that only appropriate
 signature values are countersigned.

Users of CMS, particularly those employing CMS to support interactive
applications, should be aware that PKCS #1 Version 1.5 as specified
in RFC 2313 [PKCS#1] is vulnerable to adaptive chosen ciphertext
attacks when applied for encryption purposes. Exploitation of this
identified vulnerability, revealing the result of a particular RSA
decryption, requires access to an oracle which will respond to a
large number of ciphertexts (based on currently available results,
hundreds of thousands or more), which are constructed adaptively in
response to previouslyreceived replies providing information on the
successes or failures of attempted decryption operations. As a