 1/draftietfsmimecmsalg01.txt 20060205 01:51:19.000000000 +0100
+++ 2/draftietfsmimecmsalg02.txt 20060205 01:51:19.000000000 +0100
@@ 1,18 +1,18 @@
S/MIME Working Group R. Housley
Internet Draft RSA Laboratories
expires in six months July 2001
+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
@@ 27,215 +27,192 @@
http://www.ietf.org/shadow.html.
To view the entire list of current InternetDrafts, please check the
"1idabstracts.txt" listing contained in the InternetDrafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
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.
+ This document describes several 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 (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 document obsoletes section 12 of RFC 2630. [CMS] obsoletes the
+ rest of RFC 2630. Separation of the protocol and algorithm
+ specifications allows each one to be updated without impacting the
+ other. However, the conventions for using additional algorithms with
+ the CMS are likely to be specified in separate documents.
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 .
Table of Contents
Status of this Memo .............................................. 1
Abstract ......................................................... 1
 Table of Contents ................................................ 3
 1 Introduction ................................................. 5
 2 Message Digest Algorithms .................................... 35
 2.1 SHA1 ................................................. 35
 2.2 MD5 ................................................... 35
 3 Signature Algorithms ......................................... 36
 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
 7.5 RC2 Key Unwrap ........................................ 46
 Appendix A: ASN.1 Module ........................................ 47
 References ....................................................... 55
 Security Considerations .......................................... 56
 Acknowledgments .................................................. 58
 Author's Address ................................................. 59
 Full Copyright Statement ......................................... 60
+ Table of Contents ................................................ 2
+ 1 Introduction ................................................. 3
+ 2 Message Digest Algorithms .................................... 3
+ 2.1 SHA1 ................................................. 3
+ 2.2 MD5 ................................................... 4
+ 3 Signature Algorithms ......................................... 4
+ 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.4 Key Derivation Algorithms ............................. 12
+ 4.4.1 PBKDF2 ....................................... 13
+ 5 Content Encryption Algorithms ................................ 13
+ 5.1 TripleDES CBC ........................................ 13
+ 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
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 implementations MUST
 support and SHOULD support.
+ companion specification lists the common cryptographic algorithms.
+ CMS implementations MAY support these algorithms; CMS implementations
+ MAY support other algorithms as well.
The CMS values are generated using ASN.1 [X.20888], using BER
 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 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.

 Table 1. CMS Implementation Algorithm Requirements

 Algorithm Type MUST implement SHOULD implement
 
 Message Digest SHA1 MD5
 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 (4) 

 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].
+ 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.
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].
+ SHOULD NOT, RECOMMENDED, and MAY 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.
+ 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
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:
+ 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 }
+ There are two possible encodings for the 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. 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 an ASN.1 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 SHOULD
+ accept SHA1 AlgorithmIdentifiers with absent parameters as well as
+ NULL 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 }
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 (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).
+ This section specifies the conventions employed by CMS
+ implementations that support DSA or RSA (PKCS #1 v1.5).
Signature algorithm identifiers are located in the SignerInfo
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 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 DSA signature algorithm is defined in FIPS Pub 186 [DSS]. DSA
+ MUST be 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.
+ 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 }
When the iddsawithsha1 algorithm identifier is used,
AlgorithmIdentifier parameters field MUST be absent.
@@ 265,70 +242,108 @@
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.
+ 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.
 The algorithm identifier for RSA (PKCS #1 v1.5) with SHA1 signature values is:
+ 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:
+ 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 either the sha1WithRSAEncryption algorithm identifier or the
+ md5WithRSAEncryption algorithm identifier is used, the
+ 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.
+ 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 the following general key management techniques: key agreement, key transport, previously distributed symmetric keyencryption keys, and passwords.
+ CMS accommodates the following general key management techniques: key
+ agreement, key transport, previously distributed symmetric key
+ encryption keys, and passwords.
4.1 Key Agreement Algorithms
 CMS implementations SHOULD support key agreement using X9.42 EphemeralStatic DiffieHellman (X9.42 ES DH).
+ 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 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.
+ 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 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.
+ 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.
 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 field is 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.
+ 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.
keyEncryptionAlgorithm MUST be the idalgESDH algorithm
identifier. The algorithm identifier parameter field for idalg
ESDH 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 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:
@@ 343,99 +358,142 @@
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.
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.1.2 X9.42 StaticStatic DiffieHellman
+
+ 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:
+
+ 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:
+
+ 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.
+ RecipientEncryptedKey EncryptedKey MUST contain the content
+ encryption key encrypted with the X9.42 StaticStatic 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 (PKCS #1
 v1.5). RSA implementations MUST support key transport of TripleDES
 contentencryption keys. RSA implementations SHOULD support key
 transport of RC2 contentencryption keys.
+ This section specifies the conventions employed by CMS
+ implementations that support key transport using RSA (PKCS #1 v1.5).
Key transport algorithm identifiers are located in the EnvelopedData
 RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm and
 AuthenticatedData RecipientInfos KeyTransRecipientInfo
 keyEncryptionAlgorithm fields.
+ RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm field.
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
 encryptedKey field.
+ field.
4.2.1 RSA
+4.2.1 RSA (PKCS #1 v1.5)
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:
+ for RSA (PKCS #1 v1.5) 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.
+
+ 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 (PKCS #1 v1.5) encryption.
+ DES key prior to RSA 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].
+ The use of RSA (PKCS #1 v1.5) 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
 PKCS1v1_5.
+ 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
 CMS implementations MUST support symmetric keyencryption key
 management. CMS implementations MUST include TripleDES key
 encryption keys wrapping TripleDES contentencryption keys. CMS
 implementations SHOULD include RC2 keyencryption keys wrapping RC2
 contentencryption keys. RC2 128bit keys MUST be used as key
 encryption keys, and they MUST be used with the RC2ParameterVersion
 parameter set to 58. A CMS implementation MAY support mixed key
 encryption and contentencryption algorithms. For example, a 40bit
 RC2 contentencryption key MAY be wrapped with 168bit TripleDES
 keyencryption key or with a 128bit RC2 keyencryption key.
+ 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
+ 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.
Wrapped contentencryption keys are located in the EnvelopedData
RecipientInfos KEKRecipientInfo encryptedKey field. Wrapped message
authentication keys are located in the AuthenticatedData
RecipientInfos KEKRecipientInfo encryptedKey field.
The output of a key agreement algorithm is a keyencryption key, and
this keyencryption key is used to encrypt the contentencryption
 key. In conjunction with key agreement algorithms, CMS
 implementations MUST include encryption of contentencryption keys
 with the pairwise keyencryption key generated using a key agreement
 algorithm. To support key agreement, key wrap algorithm identifiers
 are located in the KeyWrapAlgorithm parameter of the EnvelopedData
+ key. To support key agreement, key wrap algorithm identifiers are
+ located in the KeyWrapAlgorithm parameter of the EnvelopedData
RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and
AuthenticatedData RecipientInfos KeyAgreeRecipientInfo
 keyEncryptionAlgorithm fields. Wrapped contentencryption keys are
 located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo
+ keyEncryptionAlgorithm fields. However, only key agreement
+ 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
TripleDES key encryption has the algorithm identifier:
idalgCMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) memberbody(2)
@@ 478,20 +535,24 @@
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
+ 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].
Key derivation algorithm identifiers are located in the EnvelopedData
RecipientInfos PasswordRecipientInfo keyDerivationAlgorithm and
AuthenticatedData RecipientInfos PasswordRecipientInfo
keyDerivationAlgorithm fields.
@@ 522,23 +583,24 @@
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.
 CMS implementations SHOULD support TwoKey TripleDES in CBC mode.
 CMS implementations SHOULD support RC2 in CBC mode.
+ 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
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.
@@ 580,46 +642,49 @@
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), since
the one octet (A0) encoding represents a negative number.
6 Message Authentication Code Algorithms
 CMS implementations that support authenticatedData MUST support HMAC
 with SHA1.
+ This section specifies the conventions employed by CMS
+ implementations that support the HMAC with SHA1 message
+ authentication code (MAC).
MAC algorithm identifiers are located in the AuthenticatedData
macAlgorithm field.
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.
7 TripleDES and RC2 Key Wrap Algorithms
 CMS implementations MUST include encryption of a TripleDES content
 encryption key with a TripleDES keyencryption key using the
 algorithm specified in Sections 7.2 and 7.3. CMS implementations
 SHOULD include encryption of a RC2 contentencryption key with a RC2
 keyencryption key using the algorithm specified in Sections 7.4 and
 7.5. TripleDES and RC2 contentencryption keys are encrypted in
+ 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
@@ 636,22 +701,22 @@
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 Checksum Algorithm is used to provide a contentencryption
 key integrity check value. The algorithm is:
+ 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
@@ 806,22 +870,26 @@
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 }
+ idalgSSDH OBJECT IDENTIFIER ::= { iso(1) memberbody(2) us(840)
+ rsadsi(113549) pkcs(1) pkcs9(9) smime(16) alg(3) 10 }
+
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)
@@ 919,20 +987,25 @@
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.
+ PROFILE Housley, R., W. Ford, W. Polk, and D. Solo. Internet
+ X.509 Public Key Infrastructure: Certificate and CRL
+ Profile. RFC . .
+ {draftietfpkixnewpart1*.txt}
+
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
@@ 941,59 +1014,61 @@
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
 the cryptographic algorithms for use with CMS.
+ the conventions for using several cryptographic algorithms for use
+ with the CMS.
Implementations must protect the signer's private key. Compromise of
the signer's private key permits masquerade.
Implementations must protect the key management private key, the key
encryption key, and the contentencryption key. Compromise of the
key management private key or the keyencryption key may result in
the disclosure of all messages protected with that key. Similarly,
compromise of the contentencryption key may result in disclosure of
the associated encrypted content.
Implementations must protect the key management private key and the
messageauthentication key. Compromise of the key management private
key permits masquerade of authenticated data. Similarly, compromise
of the messageauthentication key may result in undetectable
modification of the authenticated content.
The key management technique employed to distribute message
 authentication keys must itself provide data origin authentication,
 otherwise the message content is delivered with integrity from an
 unknown source. Neither RSA [PKCS#1, NEWPKCS#1] nor EphemeralStatic
 DiffieHellman [DHX9.42] provide the necessary data origin
 authentication. StaticStatic DiffieHellman [DHX9.42] does provide
 the necessary data origin authentication when both the originator and
 recipient public keys are bound to appropriate identities in X.509
 certificates.
+ authentication keys must itself provide authentication, otherwise the
+ message content is delivered with integrity from an unknown source.
+ Neither RSA [PKCS#1, NEWPKCS#1] nor EphemeralStatic DiffieHellman
+ [DHX9.42] provide the necessary data origin authentication. Static
+ Static DiffieHellman [DHX9.42] does provide the necessary data
+ origin authentication when both the originator and recipient public
+ keys are bound to appropriate identities in X.509 certificates
+ [PROFILE].
When more than two parties share the same messageauthentication key,
data origin authentication is not provided. Any party that knows the
messageauthentication key can compute a valid MAC, therefore the
message could originate from any one of the parties.
Implementations must randomly generate contentencryption keys,
 messageauthentication keys, initialization vectors (IVs), and
+ messageauthentication keys, initialization vectors (IVs), onetime
+ values (such as the k value when generating a DSA signature), and
padding. Also, the generation of public/private key pairs relies on
a random numbers. The use of inadequate pseudorandom number
 generators (PRNGs) to generate cryptographic keys can result in
 little or no security. An attacker may find it much easier to
+ generators (PRNGs) to generate cryptographic such values can result
+ in little or no security. An attacker may find it much easier to
reproduce the PRNG environment that produced the keys, searching the
resulting small set of possibilities, rather than brute force
searching the whole key space. The generation of quality random
numbers is difficult. RFC 1750 [RANDOM] offers important guidance in
this area, and Appendix 3 of FIPS Pub 186 [DSS] provides one quality
PRNG technique.
When using key agreement algorithms or previously distributed
symmetric keyencryption keys, a keyencryption key is used to
encrypt the contentencryption key. If the keyencryption and
@@ 1012,56 +1087,57 @@
to encrypt a RC2 [RC2] contentencryption key with a RC2 key
encryption key. The key wrap algorithms make 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 cryptoanalysis techniques are developed and
+ weaker with time. As new cryptanalysis 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.
+ to be readily inserted. That is, implementers should be prepared to
+ regularly update the set of algorithms in their implementations.
 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
 result, the attack appears significantly less feasible to perpetrate
 for storeandforward S/MIME environments than for directly
 interactive protocols. Where CMS constructs are applied as an
 intermediate encryption layer within an interactive requestresponse
 communications environment, exploitation could be more feasible.
+ Users of the CMS, particularly those employing the CMS to support
+ interactive applications, should be aware that RSA (PKCS #1 v1.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 result, the attack appears significantly
+ less feasible to perpetrate for storeandforward S/MIME environments
+ than for directly interactive protocols. Where the CMS constructs
+ are applied as an intermediate encryption layer within an interactive
+ requestresponse communications environment, exploitation could be
+ more feasible.
An updated version of PKCS #1 has been published, PKCS #1 Version 2.0
 [NEWPKCS#1]. This new document supersedes RFC 2313. PKCS #1 Version
 2.0 preserves support for the encryption padding format defined in
 PKCS #1 Version 1.5 [PKCS#1], and it also defines a new alternative.
 To resolve the adaptive chosen ciphertext vulnerability, the PKCS #1
 Version 2.0 specifies and recommends use of Optimal Asymmetric
 Encryption Padding (OAEP) when RSA encryption is used to provide
 confidentiality. Designers of protocols and systems employing CMS
 for interactive environments should either consider usage of OAEP, or
 should ensure that information which could reveal the success or
 failure of attempted PKCS #1 Version 1.5 decryption operations is not
 provided. Support for OAEP will likely be added to a future version
 of the CMS algorithm specification.
+ [NEWPKCS#1]. This updated document supersedes RFC 2313. PKCS #1
+ Version 2.0 preserves support for the encryption padding format
+ defined in PKCS #1 Version 1.5 [PKCS#1], and it also defines a new
+ alternative. To resolve the adaptive chosen ciphertext
+ vulnerability, the PKCS #1 Version 2.0 specifies and recommends use
+ of Optimal Asymmetric Encryption Padding (OAEP) when RSA encryption
+ is used to provide confidentiality. Designers of protocols and
+ systems employing CMS for interactive environments should either
+ consider usage of OAEP, or should ensure that information which could
+ reveal the success or failure of attempted PKCS #1 Version 1.5
+ decryption operations is not provided. Support for OAEP will likely
+ be added to a future version of the CMS algorithm specification.
See RFC [MMA] for more information about thwarting the adaptive
chosen ciphertext vulnerability in PKCS #1 Version 1.5
implementations.
Acknowledgments
This document is the result of contributions from many professionals.
I appreciate the hard work of all members of the IETF S/MIME Working
Group. I extend a special thanks to Rich Ankney, Simon BlakeWilson,