 1/draftietfsmimecmsrsakem08.txt 20091208 22:12:36.000000000 +0100
+++ 2/draftietfsmimecmsrsakem09.txt 20091208 22:12:36.000000000 +0100
@@ 1,20 +1,18 @@

 S/MIME Working Group James Randall, Randall Consulting
+S/MIME WG James Randall, Randall Consulting
Internet Draft Burt Kaliski, EMC
 John Brainard, RSA
+Intended Status: Standards Track John Brainard, RSA
Sean Turner, IECA
 Expires: June 6, 2010 Category: Standards
 December 7, 2009
+Expires: June 8, 2010 December 8, 2009
Use of the RSAKEM Key Transport Algorithm in CMS

+
Status of this Memo
This InternetDraft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
@@ 33,55 +31,74 @@
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use InternetDrafts as reference
material or to cite them other than as "work in progress."
The list of current InternetDrafts can be accessed at
http://www.ietf.org/ietf/1idabstracts.txt
The list of InternetDraft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
 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.

 This InternetDraft will expire on January 6, 2010.
+ This InternetDraft will expire on June 8, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/licenseinfo).
 Please review these documents carefully, as they describe your
 rights and restrictions with respect to this document.

 Comments or suggestions for improvement may be made on the "ietf
 smime" mailing list, or directly to the authors.
+ Please review these documents carefully, as they describe your rights
+ and restrictions with respect to this document.
Abstract
The RSAKEM Key Transport Algorithm is a onepass (storeandforward)
mechanism for transporting keying data to a recipient using the
recipient's RSA public key. This document specifies the conventions
for using the RSAKEM Key Transport Algorithm with the Cryptographic
Message Syntax (CMS). The ASN.1 syntax is aligned with ANS X9.44 and
ISO/IEC 180332.
Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [STDWORDS].
+Table of Contents
+
+ 1. Introduction...................................................3
+ 2. Use in CMS.....................................................4
+ 2.1. Underlying Components.....................................4
+ 2.2. RecipientInfo Conventions.................................5
+ 2.3. Certificate Conventions...................................5
+ 2.4. SMIMECapabilities Attribute Conventions...................6
+ 3. Security Considerations........................................7
+ 4. References.....................................................9
+ 4.1. Normative References......................................9
+ 4.2. Informative References....................................9
+ Appendix A. RSAKEM Key Transport Algorithm......................11
+ A.1. Underlying Components....................................11
+ A.2. Sender's Operation.......................................11
+ A.3. Recipient's Operations...................................12
+ Appendix B. ASN.1 Syntax.........................................14
+ B.2 Selected Underlying Components............................16
+ B.2.1. Key Derivation Functions............................16
+ B.2.2 Symmetric KeyWrapping Schemes.......................18
+ B.3 ASN.1 module..............................................19
+ B.4 Examples..................................................24
+ IANA Considerations..............................................25
+ Acknowledgements.................................................25
+ Authors' Addresses...............................................26
+
1. Introduction
The RSAKEM Key Transport Algorithm is a onepass (storeandforward)
mechanism for transporting keying data to a recipient using the
recipient's RSA public key.
Most previous key transport algorithms based on the RSA publickey
cryptosystem (e.g., the popular PKCS #1 v1.5 algorithm [PKCS1]) have
the following general form:
@@ 139,37 +156,37 @@
mechanisms is described further in research by Victor Shoup leading
to the development of the ISO/IEC 180332 standard [SHOUP].
2. Use in CMS
The RSAKEM Key Transport Algorithm MAY be employed for one or more
recipients in the CMS envelopeddata content type (Section 6 of
[CMS]), where the keying data processed by the algorithm is the CMS
contentencryption key.
 The RSAKEM Key Transport Algorithm SHOULD be considered for new
 CMSbased applications as a replacement for the widely implemented
 RSA encryption algorithm specified originally in PKCS #1 v1.5 (see
+ The RSAKEM Key Transport Algorithm SHOULD be considered for new CMS
+ based applications as a replacement for the widely implemented RSA
+ encryption algorithm specified originally in PKCS #1 v1.5 (see
[PKCS1] and Section 4.2.1 of [CMSALGS]), which is vulnerable to
chosenciphertext attacks. The RSAESOAEP Key Transport Algorithm has
also been proposed as a replacement (see [PKCS1] and [CMSOAEP]).
RSAKEM has the advantage over RSAESOAEP of a tighter security
proof, but the disadvantage of slightly longer encrypted keying data.
2.1. Underlying Components
A CMS implementation that supports the RSAKEM Key Transport
Algorithm MUST support at least the following underlying components:
o For the key derivation function, KDF3 (see [IEEEP1363a]) based on
SHA256 (see [FIPS1802]). KDF3 is an instantiation of the
 Concatenation Key Derivation Function defined in [SP80056A].
+ Concatenation Key Derivation Function defined in [NISTSP80056A].
o For the keywrapping scheme, AESWrap128, i.e., the AES Key Wrap
with a 128bit key encrypting key (see [AESWRAP])
An implementation SHOULD also support KDF2 (see [ANSX9.44]) based on
SHA1 (this function is also specified as the key derivation function
in [ANSX9.63]). The Camellia key wrap algorithm (see [CAMELLIA])
SHOULD be supported, and, if 3DES is supported as a content
encryption cipher, then the TripleDES Key Wrap (see [3DESWRAP])
SHOULD also be supported.
@@ 179,30 +196,30 @@
192, or 256 bits while Triple DES requires a data block size of 64
bits and a key size of 112 or 168 bits.
2.2. RecipientInfo Conventions
When the RSAKEM Key Transport Algorithm is employed for a recipient,
the RecipientInfo alternative for that recipient MUST be
KeyTransRecipientInfo. The algorithmspecific fields of the
KeyTransRecipientInfo value MUST have the following values:
 o keyEncryptionAlgorithm.algorithm MUST be idrsakem see Appendix
+ o keyEncryptionAlgorithm.algorithm MUST be idrsakem (see Appendix
B)
o keyEncryptionAlgorithm.parameters MUST be a value of type
GenericHybridParameters, identifying the RSAKEM key encapsulation
mechanism (see Appendix B)
o encryptedKey MUST be the encrypted keying data output by the
 algorithm, where the keying data is the contentencryption
 key.(see Appendix A)
+ algorithm, where the keying data is the contentencryption key. (see
+ Appendix A)
2.3. Certificate Conventions
The conventions specified in this section augment RFC 5280 [PROFILE].
A recipient who employs the RSAKEM Key Transport Algorithm MAY
identify the public key in a certificate by the same
AlgorithmIdentifier as for the PKCS #1 v1.5 algorithm, i.e., using
the rsaEncryption object identifier [PKCS1]. The fact that the user
will accept RSAKEM with this public key is not indicated by the use
@@ 274,38 +291,38 @@
wrapping scheme satisfies the properties of a data encapsulation
mechanism [SHOUP]. While in practice a randomoracle result does not
provide an actual security proof for any particular key derivation
function, the result does provide assurance that the general
construction is reasonable; a key derivation function would need to
be particularly weak to lead to an attack that is not possible in the
random oracle model.
The RSA key size and the underlying components should be selected
consistent with the desired symmetric security level for an
 application. Several security levels have been identified in [NIST
 FIPS PUB 80057]. For brevity, the first three levels are mentioned
 here:
+ application. Several security levels have been identified in NIST
+ FIPS PUB 80057 [NISTGUIDELINE]. For brevity, the first threelevels
+ are mentioned here:
o 80bit security. The RSA key size SHOULD be at least 1024 bits,
the hash function underlying the KDF SHOULD be SHA1 or above, and
 the symmetric keywrapping scheme SHOULD be AES Key Wrap, Triple
 DES Key Wrap, or Camellia Key Wrap.
+ the symmetric keywrapping scheme SHOULD be AES Key Wrap, TripleDES
+ Key Wrap, or Camellia Key Wrap.
o 112bit security. The RSA key size SHOULD be at least 2048 bits,
 the hash function underlying the KDF SHOULD be SHA224 or above,
 and the symmetric keywrapping scheme SHOULD be AES Key Wrap,
 TripleDES Key Wrap, or Camellia Key Wrap.
+ the hash function underlying the KDF SHOULD be SHA224 or above, and
+ the symmetric keywrapping scheme SHOULD be AES Key Wrap, TripleDES
+ Key Wrap, or Camellia Key Wrap.
o 128bit security. The RSA key size SHOULD be at least 3072 bits,
 the hash function underlying the KDF SHOULD be SHA256 or above,
 and the symmetric keywrapping scheme SHOULD be AES Key Wrap or
 Camellia Key Wrap.
+ the hash function underlying the KDF SHOULD be SHA256 or above, and
+ the symmetric keywrapping scheme SHOULD be AES Key Wrap or Camellia
+ Key Wrap.
Note that the AES Key Wrap or Camellia Key Wrap MAY be used at all
three of these levels; the use of AES or Camellia does not require a
128bit security level for other components.
Implementations MUST protect the RSA private key and the content
encryption key. Compromise of the RSA private key may result in the
disclosure of all messages protected with that key. Compromise of the
contentencryption key may result in disclosure of the associated
encrypted content.
@@ 364,47 +381,47 @@
[ANSX9.63] American National Standard X9.632002: Public Key
Cryptography for the Financial Services Industry:
Key Agreement and Key Transport Using Elliptic
Curve Cryptography.
[CAMELLIA] Kato, A., Moriai, S., and Kanda, M.: Use of the
Camellia Encryption Algorithm in Cryptographic
Message Syntax. RFC 3657. December 2005.
[CMS] Housley, R. Cryptographic Message Syntax. RFC
 3852. July 2004.
+ 5652. September 20009.
[CMSALGS] Housley, R. Cryptographic Message Syntax (CMS)
Algorithms. RFC 3370. August 2002.
[FIPS1802] National Institute of Standards and Technology
(NIST). FIPS 1802: Secure Hash Standard. August
2002.
[MSG] Ramsdell, B. S/MIME Version 3 Message
Specification. RFC 3851. July 2004.
 [PROFILE] Cooper, D., Santesson, S., Farrell, S.,
 Boeyen, S., Housley, R., and W. Polk. Internet
 X.509 Public Key Infrastructure Certificate
 and Certificate Revocation List (CRL) Profile.
 RFC 5280. May 2008.
+ [PROFILE] Cooper, D., Santesson, S., Farrell, S., Boeyen,
+ S., Housley, R., and W. Polk. Internet X.509
+ Public Key Infrastructure Certificate and
+ Certificate Revocation List (CRL) Profile. RFC
+ 5280. May 2008.
[STDWORDS] Bradner, S. Key Words for Use in RFCs to Indicate
Requirement Levels. RFC 2119. March 1997.
4.2. Informative References
 [ANSX9.44] ASC X9F1 Working Group. American National
 Standard X9.44: Public Key Cryptography for the
 Financial Services Industry  Key Establishment
 Using Integer Factorization Cryptography. 2007
+ [ANSX9.44] ASC X9F1 Working Group. American National Standard
+ X9.44: Public Key Cryptography for the Financial
+ Services Industry  Key Establishment Using
+ Integer Factorization Cryptography. 2007
[CMSOAEP] Housley, R. Use of the RSAESOAEP Key Transport
Algorithm in the Cryptographic Message Syntax
(CMS). RFC 3560. July 2003.
[IEEEP1363a] IEEE Std 1363a2004: Standard Specifications for
Public Key Cryptography: Additional Techniques.
IEEE, 2004.
[ISOIEC180332] ISO/IEC 180332:2005 Information technology 
@@ 416,38 +433,37 @@
Available via http://www.cryptonessie.org/.
[NISTGUIDELINE] National Institute of Standards and Technology.
Special Publication 80057: Recommendation for
Pairwise Key Establishment Schemes Using Discrete
Logarithm Cryptography March 2007. Available via:
http://csrc.nist.gov/publications/index.html.
[NISTSP80056A] National Institute of Standards and Technology.
Special Publication 80056A: Recommendation for
 Key Management. Part 1: General Guideline.
 August 2005. Available via:
+ Key Management. Part 1: General Guideline. August
+ 2005. Available via:
http://csrc.nist.gov/publications/index.html.
[PKCS1] Jonsson, J. and B. Kaliski. PKCS #1: RSA
 Cryptography Specifications Version 2.1. RFC
 3447. February 2003.
+ Cryptography Specifications Version 2.1. RFC 3447.
+ February 2003.
[RANDOM] Eastlake, D., S. Crocker, and J. Schiller.
 Randomness Recommendations for Security. RFC
 4086. June 2005.
+ Randomness Recommendations for Security. RFC 4086.
+ June 2005.
[SHOUP] Shoup, V. A Proposal for an ISO Standard for
Public Key Encryption. Version 2.1, December 20,
2001. Available via http://www.shoup.net/papers/.
 Appendix A.
 RSAKEM Key Transport Algorithm
+Appendix A. RSAKEM Key Transport Algorithm
The RSAKEM Key Transport Algorithm is a onepass (storeandforward)
mechanism for transporting keying data to a recipient using the
recipient's RSA public key.
With this type of algorithm, a sender encrypts the keying data using
the recipient's public key to obtain encrypted keying data. The
recipient decrypts the encrypted keying data using the recipient's
private key to recover the keying data.
@@ 470,24 +486,24 @@
require the length of the keying data to be a multiple of 8 bytes,
and at least 16 bytes.) Usage and formatting of the keying data
(e.g., parity adjustment for TripleDES keys) is outside the scope of
this algorithm. With some key derivation functions, it is possible to
include other information besides the shared secret value in the
input to the function. Also, with some symmetric keywrapping
schemes, it is possible to associate a label with the keying data.
Such uses are outside the scope of this document, as they are not
directly supported by CMS.
 A.2. Sender's Operations
+A.2. Sender's Operation
 Let (n,e) be the recipient's RSA public key (see [PKCS1] for
 details) and let K be the keying data to be transported.
+ Let (n,e) be the recipient's RSA public key (see [PKCS1] for details)
+ and let K be the keying data to be transported.
Let nLen denote the length in bytes of the modulus n, i.e., the least
integer such that 2^{8*nLen} > n.
The sender performs the following operations:
1. Generate a random integer z between 0 and n1 (see Note), and
convert z to a byte string Z of length nLen, most significant byte
first:
@@ 485,27 +501,29 @@
Let nLen denote the length in bytes of the modulus n, i.e., the least
integer such that 2^{8*nLen} > n.
The sender performs the following operations:
1. Generate a random integer z between 0 and n1 (see Note), and
convert z to a byte string Z of length nLen, most significant byte
first:
z = RandomInteger (0, n1)
+
Z = IntegerToString (z, nLen)
2. Encrypt the random integer z using the recipient's public key n,e)
 and convert the resulting integer c to a ciphertext C, a byte
 string of length nLen:
+ and convert the resulting integer c to a ciphertext C, a byte string
+ of length nLen:
c = z^e mod n
+
C = IntegerToString (c, nLen)
3. Derive a keyencrypting key KEK of length kekLen bytes from the
byte string Z using the underlying key derivation function:
KEK = KDF (Z, kekLen)
4. Wrap the keying data K with the keyencrypting key KEK using the
underlying keywrapping scheme to obtain wrapped keying data WK:
@@ 548,50 +567,49 @@
z = c^d mod n
If the integer c is not between 0 and n1, output "decryption
error" and stop.
3. Convert the integer z to a byte string Z of length nLen, most
significant byte first (see Note):
Z = IntegerToString (z, nLen)
 4. Derive a keyencrypting key KEK of length kekLen bytes from
 the byte string Z using the underlying key derivation function
 (see Note):
+ 4. Derive a keyencrypting key KEK of length kekLen bytes from the
+ byte string Z using the underlying key derivation function (see
+ Note):
KEK = KDF (Z, kekLen)
 5. Unwrap the wrapped keying data WK with the keyencrypting key
 KEK using the underlying keywrapping scheme to recover the
 keying data K:
+ 5. Unwrap the wrapped keying data WK with the keyencrypting key KEK
+ using the underlying keywrapping scheme to recover the keying
+ data K:
K = Unwrap (KEK, WK)
If the unwrapping operation outputs an error, output "decryption
error" and stop.
6. Output the keying data K.
NOTE: Implementations SHOULD NOT reveal information about the integer
z and the string Z, nor about the calculation of the exponentiation
in Step 2, the conversion in Step 3, or the key derivation in Step 4,
whether by timing or other "side channels". The observable behavior
of the implementation SHOULD be the same at these steps for all
ciphertexts C that are in range. (For example, IntegerToString
conversion should take the same amount of time regardless of the
actual value of the integer z.) The integer z, the string Z and other
intermediate results MUST be securely deleted when they are no longer
needed.
 Appendix B.
 ASN.1 Syntax
+Appendix B. ASN.1 Syntax
The ASN.1 syntax for identifying the RSAKEM Key Transport Algorithm
is an extension of the syntax for the "generic hybrid cipher" in
ISO/IEC 180332 [ISOIEC180332], and is the same as employed in ANS
X9.44 [ANSX9.44]. The syntax for the scheme is given in Section B.1.
The syntax for selected underlying components including those
mentioned above is given in B.2.
The following object identifier prefixes are used in the definitions
below:
@@ 607,21 +625,21 @@
iso(1) memberbody(2) us(840) rsadsi(113549) pkcs(1) pkcs1(1)
}
NullParms is a more descriptive synonym for NULL when an algorithm
identifier has null parameters:
NullParms ::= NULL
The material in this Appendix is based on ANS X9.44.
 B.1 RSAKEM Key Transport Algorithm
+ B.1. RSAKEM Key Transport Algorithm
The object identifier for the RSAKEM Key Transport Algorithm is id
rsakem, which is defined in the draft as:
idrsakem OID ::= {
iso(1) memberbody(2) us(840) rsadsi(113549) pkcs(1)
pkcs9(9) smime(16) alg(3) TBA
}
When idrsakem is used in an AlgorithmIdentifier, the parameters
@@ 635,61 +653,58 @@
}
The fields of type GenericHybridParameters have the following
meanings:
o kem identifies the underlying key encapsulation mechanism. For the
RSAKEM Key Transport Algorithm, the scheme is RSAKEM from
ISO/IEC 180332.
The object identifier for RSAKEM (as a key encapsulation
 mechanism) is idkemrsa, which is defined in ISO/IEC 180332 as
+ mechanism) is idkemrsa, which is defined in ISO/IEC 180332 as:
idkemrsa OID ::= {
is180332 keyencapsulationmechanism(2) rsa(4)
}
The associated parameters for idkemrsa have type
RsaKemParameters:
RsaKemParameters ::= {
keyDerivationFunction KeyDerivationFunction,
keyLength KeyLength
}
The fields of type RsaKemParameters have the following meanings:
 * keyDerivationFunction identifies the underlying key
 derivation function. For alignment with ANS X9.44, it
 MUST be KDF2 or KDF3. However, other key derivation
 functions MAY be used with CMS. Please see B.2.1 for
 the syntax for KDF2 and KDF3.
+ * keyDerivationFunction identifies the underlying key derivation
+ function. For alignment with ANS X9.44, it MUST be KDF2 or KDF3.
+ However, other key derivation functions MAY be used with CMS.
+ Please see B.2.1 for the syntax for KDF2 and KDF3.
 KeyDerivationFunction ::=
 AlgorithmIdentifier {{KDFAlgorithms}}
+ KeyDerivationFunction ::= AlgorithmIdentifier {{KDFAlgorithms}}
KDFAlgorithms ALGORITHM ::= {
kdf2  kdf3,
...  implementations may define other methods
}
 * keyLength is the length in bytes of the keyencrypting
 key, which depends on the underlying symmetric key
 wrapping scheme.
+ * keyLength is the length in bytes of the keyencrypting key,
+ which depends on the underlying symmetric keywrapping scheme.
KeyLength ::= INTEGER (1..MAX)
o dem identifies the underlying data encapsulation mechanism. For
 alignment with ANS X9.44, it MUST be an X9approved symmetric key
 wrapping scheme. (See Note.) However, other symmetric keywrapping
 schemes MAY be used with CMS. Please see B.2.2 for the syntax for
 the AES, TripleDES, and Camellia Key Wraps.
+ alignment with ANS X9.44, it MUST be an X9approved symmetric
+ keywrapping scheme. (See Note.) However, other symmetric key
+ wrapping schemes MAY be used with CMS. Please see B.2.2 for the
+ syntax for the AES, TripleDES, and Camellia Key Wraps.
DataEncapsulationMechanism ::=
AlgorithmIdentifier {{DEMAlgorithms}}
DEMAlgorithms ALGORITHM ::= {
X9SymmetricKeyWrappingSchemes,
CamelliaKeyWrappingSchemes,
...  implementations may define other methods
}
@@ 704,48 +719,48 @@
NOTE: The generic hybrid cipher in ISO/IEC 180332 can encrypt
arbitrary data, hence the term "data encapsulation mechanism". The
symmetric keywrapping schemes take the role of data encapsulation
mechanisms in the RSAKEM Key Transport Algorithm. ISO/IEC 180332
allows only three specific data encapsulation mechanisms, not
including any of these symmetric keywrapping schemes. However, the
ASN.1 syntax in that document expects that additional algorithms will
be allowed.
 B.2
+B.2 Selected Underlying Components
 B.2.1 Key Derivation Functions
+B.2.1. Key Derivation Functions
The object identifier for KDF2 (see [ANS X9.44]) is:
idkdfkdf2 OID ::= { x944components kdf2(1) }
The associated parameters identify the underlying hash function. For
alignment with ANS X9.44, the hash function MUST be an ASC X9
approved hash function. However, other hash functions MAY be used
with CMS.
kdf2 ALGORITHM ::= { OID idkdfkdf2 PARMS KDF2HashFunction }
 KDF2HashFunction ::= AlgorithmIdentifier {{KDF2
 HashFunctions}}
+
+ KDF2HashFunction ::= AlgorithmIdentifier {{KDF2HashFunctions}}
KDF2HashFunctions ALGORITHM ::= {
X9HashFunctions,
...  implementations may define other methods
}
X9HashFunctions ALGORITHM ::= {
sha1  sha224  sha256  sha384  sha512,
...  allows for future expansion
}
 The object identifier for SHA1 is
+ The object identifier for SHA1 is:
idsha1 OID ::= {
iso(1) identifiedorganization(3) oiw(14) secsig(3)
algorithms(2) sha1(26)
}
The object identifiers for SHA224, SHA256, SHA384 and SHA512 are
idsha224 OID ::= { nistAlgorithm hashAlgs(2) sha224(4) }
idsha256 OID ::= { nistAlgorithm hashAlgs(2) sha256(1) }
@@ 778,35 +793,35 @@
KDF3HashFunction ::= AlgorithmIdentifier { KDF3HashFunctions }
KDF3HashFunctions ALGORITHM ::= {
X9HashFunctions,
...  implementations may define other methods
}
B.2.2 Symmetric KeyWrapping Schemes
The object identifiers for the AES Key Wrap depends on the size of
 the key encrypting key. There are three object identifiers (see
 [AESWRAP]):
+ the key encrypting key. There are three object identifiers (see [AES
+ WRAP]):
idaes128Wrap OID ::= { nistAlgorithm aes(1) aes128Wrap(5) }
idaes192Wrap OID ::= { nistAlgorithm aes(1) aes192Wrap(25) }
idaes256Wrap OID ::= { nistAlgorithm aes(1) aes256Wrap(45) }
These object identifiers have no associated parameters.
aes128Wrap ALGORITHM ::= { OID idaes128Wrap }
aes192Wrap ALGORITHM ::= { OID idaes192Wrap }
aes256Wrap ALGORITHM ::= { OID idaes256Wrap }
The object identifier for the TripleDES Key Wrap (see [3DESWRAP])
 is
+ is:
idalgCMS3DESwrap OBJECT IDENTIFIER ::= {
iso(1) memberbody(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) alg(3) 6
}
This object identifier has a NULL parameter.
tdesWrap ALGORITHM ::=
{ OID idalgCMS3DESwrap PARMS NullParms }
@@ 900,40 +914,43 @@
iso(1) memberbody(2) us(840) rsadsi(113549) pkcs(1)
pkcs9(9) smime(16) alg(3) TBA
}
GenericHybridParameters ::= SEQUENCE {
kem KeyEncapsulationMechanism,
dem DataEncapsulationMechanism
}
KeyEncapsulationMechanism ::= AlgorithmIdentifier {{KEMAlgorithms}}
+
+ KEMAlgorithms ALGORITHM ::= { kemrsa, ... }
+
+ kemrsa ALGORITHM ::= { OID idkemrsa PARMS RsaKemParameters }
idkemrsa OID ::= {
is180332 keyencapsulationmechanism(2) rsa(4)
}
RsaKemParameters ::= SEQUENCE {
keyDerivationFunction KeyDerivationFunction,
keyLength KeyLength
}
KeyDerivationFunction ::= AlgorithmIdentifier {{KDFAlgorithms}}
KDFAlgorithms ALGORITHM ::= {
kdf2  kdf3,
...  implementations may define other methods
}
KeyLength ::= INTEGER (1..MAX)
 DataEncapsulationMechanism ::=
 AlgorithmIdentifier {{DEMAlgorithms}}
+ DataEncapsulationMechanism ::= AlgorithmIdentifier {{DEMAlgorithms}}
DEMAlgorithms ALGORITHM ::= {
X9SymmetricKeyWrappingSchemes 
CamelliaKeyWrappingSchemes,
...  implementations may define other methods
}
X9SymmetricKeyWrappingSchemes ALGORITHM ::= {
aes128Wrap  aes192Wrap  aes256Wrap  tdesWrap,
...  allows for future expansion
@@ 946,41 +963,43 @@
camellia128Wrap  camellia192Wrap  camellia256Wrap,
...  allows for future expansion
}
CamelliaKeyWrappingScheme ::=
AlgorithmIdentifier {{ CamelliaKeyWrappingSchemes }}
 Key Derivation Functions
idkdfkdf2 OID ::= { x944components kdf2(1) }
  Base arc
+  Base arc
x944 OID ::= {
iso(1) identifiedorganization(3) tc68(133) country(16) x9(840)
x9Standards(9) x944(44)
}
x944components OID ::= { x944 components(1) }
kdf2 ALGORITHM ::= { OID idkdfkdf2 PARMS KDF2HashFunction }
KDF2HashFunction ::= AlgorithmIdentifier {{ KDF2HashFunctions }}
KDF2HashFunctions ALGORITHM ::= {
X9HashFunctions,
...  implementations may define other methods
}
  idkdfkdf3 OID ::= { x944components kdf3(2) } kdf3 ALGORITHM
 ::= { OID idkdfkdf2 PARMS KDF3HashFunction } KDF3HashFunction
 ::= AlgorithmIdentifier {{ KDF3HashFunctions }}
+ idkdfkdf3 OID ::= { x944components kdf3(2) }
+
+ kdf3 ALGORITHM ::= { OID idkdfkdf2 PARMS KDF3HashFunction }
+
+ KDF3HashFunction ::= AlgorithmIdentifier {{ KDF3HashFunctions }}
KDF3HashFunctions ALGORITHM ::= {
X9HashFunctions,
...  implementations may define other methods
}
 Hash Functions
X9HashFunctions ALGORITHM ::= {
sha1  sha224  sha256  sha384  sha512,
@@ 1048,21 +1079,21 @@
Algorithm will have the following value:
SEQUENCE {
idrsakem,  RSAKEM cipher
SEQUENCE {  GenericHybridParameters
SEQUENCE {  key encapsulation mechanism
idkemrsa,  RSAKEM
SEQUENCE {  RsaKemParameters
SEQUENCE {  key derivation function
idkdfkdf3,  KDF3
 SEQUENCE {  KDF2HashFunction
+ SEQUENCE {  KDF3HashFunction
idsha256  SHA256; no parameters (preferred)
},
16  KEK length in bytes
},
SEQUENCE {  data encapsulation mechanism
idaes128Wrap  AES128 Wrap; no parameters
}
}
}
@@ 1115,60 +1147,57 @@
Within the CMS, algorithms are identified by object identifiers
(OIDs). With one exception, all of the OIDs used in this document
were assigned in other IETF documents, in ISO/IEC standards
documents, by the National Institute of Standards and Technology
(NIST), and in PublicKey Cryptography Standards (PKCS) documents.
The one exception is that the ASN.1 module's identifier (see Appendix
B.3) is assigned in this document. No further action by the IANA is
necessary for this document or any anticipated updates.
 Acknowledgments
+Acknowledgements
This document is one part of a strategy to align algorithm standards
produced by ASC X9, ISO/IEC JTC1 SC27, NIST, and the IETF. We would
like to thank the members of the ASC X9F1 working group for their
contributions to drafts of ANS X9.44 which led to this specification.
Our thanks to Russ Housley as well for his guidance and
encouragement. We also appreciate the helpful direction we've
received from Blake Ramsdell and Jim Schaad in bringing this document
to fruition. A special thanks to Magnus Nystrom for his assistance on
Appendix B. Thanks also to Bob Griffin and John Linn for both
editorial direction and procedural guidance.
 Author Information
+Authors' Addresses
James Randall

Randall Consulting
55 Sandpiper Drive
Dover, NH 03820
USA
Email: jdrandall@comcast.net
Burt Kaliski

EMC
176 South Street
Hopkinton, MA 01748
USA
Email: kaliski_burt@emc.com
John Brainard

RSA, The Security Division of EMC
174 Middlesex Turnpike
Bedford, MA 01730
USA
+
Email: jbrainard@rsa.com
Sean Turner

IECA, Inc.
3057 Nutley Street, Suite 106
Fairfax, VA 22031
USA
Email: turners@ieca.com