 1/draftietfsmimecmsrsakem10.txt 20100220 01:10:37.000000000 +0100
+++ 2/draftietfsmimecmsrsakem11.txt 20100220 01:10:37.000000000 +0100
@@ 1,18 +1,27 @@
S/MIME WG James Randall, Randall Consulting
Internet Draft Burt Kaliski, EMC
Intended Status: Standards Track John Brainard, RSA
Sean Turner, IECA
Expires: June 8, 2010 December 8, 2009
+Expires: August 19, 2010 February 19, 2010
Use of the RSAKEM Key Transport Algorithm in CMS

+
+
+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.
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
@@ 27,77 +36,72 @@
other groups may also distribute working documents as Internet
Drafts.
InternetDrafts are draft documents valid for a maximum of six months
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
 This InternetDraft will expire on June 8, 2010.
+ This InternetDraft will expire on August 19, 2010.
Copyright Notice
 Copyright (c) 2009 IETF Trust and the persons identified as the
+ Copyright (c) 2010 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.

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.
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/licenseinfo) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
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
+ 4. IANA Considerations............................................9
+ 5. Acknowledgements...............................................9
+ 6. References.....................................................9
+ 6.1. Normative References......................................9
+ 6.2. Informative References...................................10
Appendix A. RSAKEM Key Transport Algorithm......................11
A.1. Underlying Components....................................11
 A.2. Sender's Operations......................................11
 A.3. Recipient's Operations...................................12
+ A.2. Sender's Operations......................................12
+ A.3. Recipient's Operations...................................13
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
+ B.1. RSAKEM Key Transport Algorithm..........................15
+ B.2 Selected Underlying Components............................17
+ B.2.1. Key Derivation Functions............................17
+ B.2.2 Symmetric KeyWrapping Schemes.......................19
+ B.3 ASN.1 module..............................................20
+ B.4 Examples..................................................25
+ Authors' Addresses...............................................27
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:
@@ 131,21 +135,21 @@
(a) the input to the underlying RSA operation is effectively a random
integer between 0 and n1, where n is the RSA modulus, so it does not
have any structure that could be exploited by an adversary, and (b)
the input is independent of the keying data so the result of the RSA
decryption operation is not directly available to an adversary. As a
result, the algorithm enjoys a "tight" security proof in the random
oracle model. (In other padding schemes, such as PKCS #1 v1.5, the
input has structure and/or depends on the keying data, and the
provable security assurances are not as strong.) The approach is also
architecturally convenient because the publickey operations are
 separate from the symmetric operations on the keying data. One
+ separate from the symmetric operations on the keying data. Another
benefit is that the length of the keying data is bounded only by the
symmetric keywrapping scheme, not the size of the RSA modulus.
The RSAKEM Key Transport Algorithm in various forms is being adopted
in several draft standards as well as in ANSX9.44 and ISO/IEC 18033
2. It has also been recommended by the NESSIE project [NESSIE].
For completeness, a specification of the algorithm is given in
Appendix A of this document; ASN.1 syntax is given in Appendix B.
@@ 171,72 +175,77 @@
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
+ SHA256 (see [FIPS1803]). KDF3 is an instantiation of the
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])
+ 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.
It MAY support other underlying components. When AES or Camellia are
 used the data block size is 128 bits while the key size can be 128,
 192, or 256 bits while Triple DES requires a data block size of 64
+ used, the data block size is 128 bits and the key size can be 128,
+ 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
 B)
+ B);
o keyEncryptionAlgorithm.parameters MUST be a value of type
GenericHybridParameters, identifying the RSAKEM key encapsulation
 mechanism (see Appendix B)
+ 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
 of this identifier. This may be signed by the use of the appropriate
 SMIME Capabilities either in a message or in the certificate.
+ of this identifier. This may be signalled by the use of the
+ appropriate SMIME Capabilities either in a message or in the
+ certificate.
If the recipient wishes only to employ the RSAKEM Key Transport
Algorithm with a given public key, the recipient MUST identify the
public key in the certificate using the idrsakem object identifier
 (see Appendix B). The parameters are absent.
+ (see Appendix B). When the idktarsakem algorithm identifier
+ appears in the SubjectPublicKeyInfo algorithm field, the encoding
+ SHALL omit the parameters field from AlgorithmIdentifier. That is,
+ the AlgorithmIdentifier SHALL be a SEQUENCE of one component, the
+ object identifier idrsakem.
Regardless of the AlgorithmIdentifier used, the RSA public key is
encoded in the same manner in the subject public key information. The
RSA public key MUST be encoded using the type RSAPublicKey type:
RSAPublicKey ::= SEQUENCE {
modulus INTEGER,  n
publicExponent INTEGER  e
}
@@ 360,23 +369,48 @@
and digital signature key pairs.) Continuing this principle of key
separation, a key pair used for the RSAKEM Key Transport Algorithm
SHOULD NOT be used with other key establishment schemes, or for data
encryption, or with more than one set of underlying algorithm
components.
Parties MAY formalize the assurance that one another's
implementations are correct through implementation validation, e.g.
NIST's Cryptographic Module Validation Program (CMVP).
4. References
+4. IANA Considerations
4.1. Normative References
+ 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.
+
+5. 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.
+
+6. References
+
+6.1. Normative References
[3DESWRAP] Housley, R. TripleDES and RC2 Key Wrapping. RFC
3217. December 2001.
[AESWRAP] Schaad, J. and R. Housley. Advanced Encryption
Standard (AES) Key Wrap Algorithm. RFC 3394.
September 2002.
[ANSX9.63] American National Standard X9.632002: Public Key
Cryptography for the Financial Services Industry:
@@ 386,63 +421,67 @@
[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
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.
+ [FIPS1803] National Institute of Standards and Technology
+ (NIST). FIPS 1803: Secure Hash Standard. October
+ 2008.
 [MSG] Ramsdell, B. S/MIME Version 3 Message
 Specification. RFC 3851. July 2004.
+ [MSG] Ramsdell, B., and S. Turner. S/MIME Version 3.2
+ Message Specification. RFC 5751. January 2010.
[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
+6.2. Informative References
+
+ [AESWRAPPAD] Housley, R., and M. Dworkin. Advanced Encryption
+ Standard (AES) Key Wrap with Padding Algorithm.
+ RFC 5649. August 2009.
[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
+ 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 
Security techniques  Encryption algorithms 
Part 2: Asymmetric Ciphers. ISO/IEC, 2005.
[NESSIE] NESSIE Consortium. Portfolio of Recommended
Cryptographic Primitives. February 27, 2003.
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:
+ 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:
http://csrc.nist.gov/publications/index.html.
[PKCS1] Jonsson, J. and B. Kaliski. PKCS #1: RSA
Cryptography Specifications Version 2.1. RFC 3447.
@@ 465,24 +504,24 @@
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.
A.1. Underlying Components
The algorithm has the following underlying components:
o KDF, a key derivation function, which derives keying data of a
 specified length from a shared secret value
+ specified length from a shared secret value;
o Wrap, a symmetric keywrapping scheme, which encrypts keying Data
 using a keyencrypting key
+ using a keyencrypting key.
In the following, kekLen denotes the length in bytes of the key
encrypting key for the underlying symmetric keywrapping scheme.
In this scheme, the length of the keying data to be transported MUST
be among the lengths supported by the underlying symmetric key
wrapping scheme. (Both the AES and Camellia Key Wraps, for instance,
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
@@ 618,53 +657,57 @@
nistAlgorithm OID ::= {
jointisoitut(2) country(16) us(840) organization(1)
gov(101) csor(3) nistAlgorithm(4)
}
pkcs1 OID ::= {
iso(1) memberbody(2) us(840) rsadsi(113549) pkcs(1) pkcs1(1)
}
+ x944 OID ::= { iso(1) identifiedorganization(3) tc68(133)
+ country(16) x9(840) x9Standards(9) x944(44) }
+
+ x944components OID ::= { x944 components(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
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
+ pkcs9(9) smime(16) alg(3) 14
}
When idrsakem is used in an AlgorithmIdentifier, the parameters
MUST employ the GenericHybridParameters syntax. The parameters MUST
 be absent when used in the subjectPublicKeyInfo field The syntax for
+ be absent when used in the subjectPublicKeyInfo field. The syntax for
GenericHybridParameters is as follows:
GenericHybridParameters ::= {
kem KeyEncapsulationMechanism,
dem DataEncapsulationMechanism
}
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.
+ o kem identifies the underlying key encapsulation mechanism, which
+ in this case is also denoted as RSAKEM, per ISO/IEC 180332.
The object identifier for RSAKEM (as a key encapsulation
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:
@@ 778,22 +820,22 @@
sha256 ALGORITHM ::= { OID idsha256 }  OIDs
sha384 ALGORITHM ::= { OID idsha384 }  ""
sha512 ALGORITHM ::= { OID idsha512 }  ""
The object identifier for KDF3 (see [ANS X9.44]) is:
idkdfkdf3 OID ::= { x944components kdf3(2) }
The associated parameters identify the underlying hash function. For
alignment with the draft ANS X9.44, the hash function MUST be an ASC
 X9approved hash function. (See Note.) However, other hash functions
 MAY be used with CMS.
+ X9approved hash function. However, other hash functions MAY be used
+ with CMS.
kdf3 ALGORITHM ::= { OID idkdfkdf3 PARMS KDF3HashFunction }
KDF3HashFunction ::= AlgorithmIdentifier { KDF3HashFunctions }
KDF3HashFunctions ALGORITHM ::= {
X9HashFunctions,
...  implementations may define other methods
}
@@ 819,22 +861,23 @@
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 }
 NOTE: As of this writing, the AES Key Wrap and the TripleDES Key
 Wrap are in the process of being approved by ASC X9.
+ NOTE: ASC X9 has not yet incorporated AES Key Wrap with Padding [AES
+ WRAPPAD] in to ANS X9.44. When ASC X9.44 adds AES Key Wrap with
+ Padding, this document will also be updated.
The object identifiers for the Camellia Key Wrap depend on the size
of the key encrypting key. There are three object identifiers:
idcamellia128Wrap OBJECT IDENTIFIER ::=
{ iso(1) memberbody(2) 392 200011 61 security(1)
algorithm(1) keywrapalgorithm(3)
camellia128wrap(2) }
idcamellia192Wrap OBJECT IDENTIFIER ::=
@@ 905,37 +947,37 @@
 PKCS #1 arc
pkcs1 OID ::= {
iso(1) memberbody(2) us(840) rsadsi(113549) pkcs(1) pkcs1(1)
}
 RSAKEM Key Transport Algorithm
idrsakem OID ::= {
iso(1) memberbody(2) us(840) rsadsi(113549) pkcs(1)
 pkcs9(9) smime(16) alg(3) TBA
+ pkcs9(9) smime(16) alg(3) 14
}
GenericHybridParameters ::= SEQUENCE {
kem KeyEncapsulationMechanism,
dem DataEncapsulationMechanism
}
KeyEncapsulationMechanism ::= AlgorithmIdentifier {{KEMAlgorithms}}
KEMAlgorithms ALGORITHM ::= { kemrsa, ... }
 kemrsa ALGORITHM ::= { OID idkemrsa PARAMS RsaKemParameters }
+ 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
@@ 983,21 +1025,21 @@
KDF2HashFunction ::= AlgorithmIdentifier {{ KDF2HashFunctions }}
KDF2HashFunctions ALGORITHM ::= {
X9HashFunctions,
...  implementations may define other methods
}
idkdfkdf3 OID ::= { x944components kdf3(2) }
 kdf3 ALGORITHM ::= { OID idkdfkdf2 PARMS KDF3HashFunction }
+ kdf3 ALGORITHM ::= { OID idkdfkdf3 PARMS KDF3HashFunction }
KDF3HashFunction ::= AlgorithmIdentifier {{ KDF3HashFunctions }}
KDF3HashFunctions ALGORITHM ::= {
X9HashFunctions,
...  implementations may define other methods
}
 Hash Functions
@@ 1089,91 +1131,64 @@
SEQUENCE {  KDF3HashFunction
idsha256  SHA256; no parameters (preferred)
},
16  KEK length in bytes
},
SEQUENCE {  data encapsulation mechanism
idaes128Wrap  AES128 Wrap; no parameters
}
}
}

This AlgorithmIdentifier value has the following DER encoding (??
indicates the algorithm number which is to be assigned):
 30 53
 06 0b 2a 86 48 86 f7 0d 01 09 10 03 ??  idrsakem
 30 44
 30 25
+ 30 47
+ 06 0b 2a 86 48 86 f7 0d 01 09 10 03 0e  idrsakem
+ 30 38
+ 30 29
06 07 28 81 8c 71 02 02 04  idkemrsa
 30 1a
 30 16
 06 07 28 81 8c 71 02 05 02  idkdfkdf3
+ 30 1e
+ 30 19
+ 06 0a 2b 81 05 10 86 48 09 2c 01 02  idkdfkdf3
30 0b
06 09 60 86 48 01 65 03 04 02 01  idsha256
 02 10  16 bytes

+ 02 01 10  16 bytes
30 0b
06 09 60 86 48 01 65 03 04 01 05  idaes128Wrap
The DER encodings for other typical sets of underlying components are
as follows:
o KDF3 based on SHA384, AES Key Wrap with a 192bit KEK
 30 46 06 0b 2a 86 48 86 f7 0d 01 09 10 03 ?? 02
 01 02 30 44 30 25 06 07 28 81 8c 71 02 02 04 30
 1a 30 16 06 07 28 81 8c 71 02 05 02 30 0b 06 09
 60 86 48 01 65 03 04 02 02 02 18 30 0b 06 09 60
 86 48 01 65 03 04 01 19
+ 30 47 06 0b 2a 86 48 86 f7 0d 01 09 10 03 0e 30
+ 38 30 29 06 07 28 81 8c 71 02 02 04 30 1e 30 19
+ 06 0a 2b 81 05 10 86 48 09 2c 01 02 30 0b 06 09
+ 60 86 48 01 65 03 04 02 02 02 01 18 30 0b 06 09
+ 60 86 48 01 65 03 04 01 19
o KDF3 based on SHA512, AES Key Wrap with a 256bit KEK
 30 46 06 0b 2a 86 48 86 f7 0d 01 09 10 03 ?? 02
 01 02 30 44 30 25 06 07 28 81 8c 71 02 02 04 30
 1a 30 16 06 07 28 81 8c 71 02 05 02 30 0b 06 09
 60 86 48 01 65 03 04 02 03 02 20 30 0b 06 09 60
 86 48 01 65 03 04 01 2d
+ 30 47 06 0b 2a 86 48 86 f7 0d 01 09 10 03 0e 30
+ 38 30 29 06 07 28 81 8c 71 02 02 04 30 1e 30 19
+ 06 0a 2b 81 05 10 86 48 09 2c 01 02 30 0b 06 09
+ 60 86 48 01 65 03 04 02 03 02 01 20 30 0b 06 09
+ 60 86 48 01 65 03 04 01 2d
o KDF2 based on SHA1, TripleDES Key Wrap with a 128bit KEK (two
key tripleDES)
 30 46 06 0b 2a 86 48 86 f7 0d 01 09 10 03 ?? 02
 01 02 30 44 30 21 06 07 28 81 8c 71 02 01 04 30
 16 30 12 06 07 28 81 8c 71 02 05 02 30 07 06 05
 2b 0e 03 02 1a 02 10 30 0f 06 0b 2a 86 48 86 f7
 0d 01 09 10 03 06 05 00

IANA Considerations

 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.

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.
+ 30 45 06 0b 2a 86 48 86 f7 0d 01 09 10 03 0e 30
+ 36 30 25 06 07 28 81 8c 71 02 02 04 30 1a 30 15
+ 06 0a 2b 81 05 10 86 48 09 2c 01 01 30 07 06 05
+ 2b 0e 03 02 1a 02 01 10 30 0d 06 0b 2a 86 48 86
+ f7 0d 01 09 10 03 06
Authors' Addresses
James Randall
Randall Consulting
55 Sandpiper Drive
Dover, NH 03820
USA
Email: jdrandall@comcast.net