 1/draftietfsmimecmsalg02.txt 20060205 01:51:20.000000000 +0100
+++ 2/draftietfsmimecmsalg03.txt 20060205 01:51:20.000000000 +0100
@@ 1,18 +1,18 @@
S/MIME Working Group R. Housley
Internet Draft RSA Laboratories
expires in six months August 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
@@ 140,23 +140,24 @@
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. 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 SHOULD
 accept SHA1 AlgorithmIdentifiers with absent parameters as well as
 NULL parameters. Implementations SHOULD generate SHA1
+ the parameters field MUST contain a NULL. Implementations MUST
+ accept SHA1 AlgorithmIdentifiers with absent parameters.
+ Implementations SHOULD 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 }
@@ 242,23 +243,24 @@
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 that support the RSA (PKCS #1 v1.5) signature
 algorithm MUST also support the SHA1 message digest algorithm. Such
 implementations SHOULD also support MD5 message digest algorithm.
+ CMS implementations that include the RSA (PKCS #1 v1.5) signature
+ algorithm MUST also implement the SHA1 message digest algorithm.
+ Such implementations SHOULD also support MD5 message digest
+ algorithm.
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:
@@ 278,30 +280,25 @@
agreement, key transport, previously distributed symmetric key
encryption keys, and passwords.
4.1 Key Agreement Algorithms
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).
 Any symmetric encryption algorithm that a CMS implementation includes
 as a contentencryption algorithm MUST also be included as a key
 encryption algorithm. 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.
+ 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.
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.
@@ 327,36 +324,39 @@
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. 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.
+ ukm may be present or absent. CMS implementations MUST support
+ ukm being absent, and CMS implementations SHOULD support be
+ 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 KeyWrapAlgorihtm, and this parameter MUST be present. The
+ 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:
 idalgESDH OBJECT IDENTIFIER ::= { iso(1) memberbody(2) us(840)
 rsadsi(113549) pkcs(1) pkcs9(9) smime(16) alg(3) 5 }
+ 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
issuerAndSerialNumber identifying the recipient's certificate or
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.
@@ 391,22 +391,23 @@
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:
 idalgSSDH OBJECT IDENTIFIER ::= { iso(1) memberbody(2) us(840)
 rsadsi(113549) pkcs(1) pkcs9(9) smime(16) alg(3) 10 }
+ 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
issuerAndSerialNumber identifying the recipient's certificate or
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.
@@ 487,46 +488,57 @@
algorithms that inherently provide authentication ought to be used
with AuthenticatedData. Wrapped contentencryption keys are located
in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo
RecipientEncryptedKeys encryptedKey field, wrapped message
authentication keys are located in the AuthenticatedData
RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys
encryptedKey field.
4.3.1 TripleDES 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.
+
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.
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.
+ Similarly, a 40bit RC2 contentencryption key MAY be wrapped with
+ 128bit RC2 keyencryption key.
+
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:
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),
because the one octet (A0) encoding represents a negative number.
RC2 128bit keys MUST be used as keyencryption keys, and they MUST
@@ 541,32 +553,29 @@
document.
4.4 Key Derivation Algorithms
This section specifies the conventions employed by CMS
implementations that support passwordbased key management using
PBKDF2.
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].
+ 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

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].
@@ 579,21 +588,25 @@
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 }
+ prf AlgorithmIdentifier
+ DEFAULT { algorithm hMACSHA1, parameters NULL } }
+
+ Within the PBKDF2params, the salt MUST use the specified OCTET
+ STRING.
5 Content Encryption Algorithms
This section specifies the conventions employed by CMS
implementations that support content encryption using ThreeKey
TripleDES in CBC mode, TwoKey TripleDES in CBC mode, or RC2 in CBC
mode.
Content encryption algorithms identifiers are located in the
EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm and the
@@ 659,21 +672,31 @@
MAC values are located in the AuthenticatedData mac field.
6.1 HMAC with SHA1
The HMAC with SHA1 algorithm is described in RFC 2104 [HMAC]. The
algorithm identifier for HMAC with SHA1 is:
hMACSHA1 OBJECT IDENTIFIER ::= { iso(1) identifiedorganization(3)
dod(6) internet(1) security(5) mechanisms(5) 8 1 2 }
 The AlgorithmIdentifier parameters field must be absent.
+ There are two possible encodings for the HMAC with SHA1
+ AlgorithmIdentifier parameters field. The two alternatives arise
+ 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
@@ 840,21 +864,26 @@
pkcs(1) pkcs9(9) smime(16) modules(0) cmsalg2001(16) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
 EXPORTS All
 The types and values defined in this module are exported for use in
 the other ASN.1 modules. Other applications may use them for their
 own purposes.
  IMPORTS None
+ IMPORTS
+  Directory Authentication Framework (X.5092000)
+ AlgorithmIdentifier
+ FROM AuthenticationFramework { jointisoitut ds(5)
+ module(1) authenticationFramework(7) 4 } ;
+
 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 }
@@ 944,21 +972,22 @@
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 }
+ 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}