draft-ietf-smime-cms-rsa-kem-02.txt   draft-ietf-smime-cms-rsa-kem-03.txt 
S/MIME Working Group B.Kaliski/J.Randall S/MIME Working Group J. Randall
Internet Draft RSA Laboratories Internet Draft RSA Security
Document: draft-ietf-smime-cms-rsa-kem-03.txt B.Kaliski
Category: Standards Category: Standards EMC Corp.
Use of the RSA-KEM Key Transport Algorithm in CMS Use of the RSA-KEM Key Transport Algorithm in CMS
<draft-ietf-smime-cms-rsa-kem-02.txt> <draft-ietf-smime-cms-rsa-kem-03.txt>
Status of this Memo Status of this Memo
Internet-Drafts 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 Internet-
Drafts.
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an Internet-Drafts are working documents of the Internet Engineering
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS Task Force (IETF), its areas, and its working groups. Note that other
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Internet-Drafts 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 Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material time. It is inappropriate to use Internet-Drafts as reference
or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at: The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at: The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Comments or suggestions for improvement may be made on the "ietf- Comments or suggestions for improvement may be made on the "ietf-
smime" mailing list, or directly to the author. smime" mailing list, or directly to the author.
Abstract Abstract
The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward)
mechanism for transporting keying data to a recipient using the mechanism for transporting keying data to a recipient using the
recipient's RSA public key. This document specifies the conventions recipient's RSA public key. This document specifies the conventions
for using the RSA-KEM Key Transport Algorithm with the Cryptographic for using the RSA-KEM Key Transport Algorithm with the Cryptographic
Message Syntax (CMS). This version (-02) updates the ASN.1 syntax to Message Syntax (CMS). This version (-03) updates the ASN.1 syntax to
align with the latest draft of ANS X9.44 and ISO/IEC 18033-2, and align with ANS X9.44 and ISO/IEC 18033-2.
adds material on Camillia algorirthm.
Conventions Used in This Document Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119 this document are to be interpreted as described in RFC 2119
[STDWORDS]. [STDWORDS].
1. Introduction 1. Introduction
skipping to change at page 3, line 21 skipping to change at page 3, line 6
the input to the underlying RSA operation is random and independent the input to the underlying RSA operation is random and independent
of the message, and the key-encrypting key KEK is derived from it in of the message, and the key-encrypting key KEK is derived from it in
a strong way. As a result, the algorithm enjoys a "tight" security a strong way. As a result, the algorithm enjoys a "tight" security
proof in the random oracle model. It is also architecturally proof in the random oracle model. It is also architecturally
convenient because the public-key operations are separate from the convenient because the public-key operations are separate from the
symmetric operations on the keying data. One benefit is that the symmetric operations on the keying data. One benefit is that the
length of the keying data is bounded only by the symmetric key- length of the keying data is bounded only by the symmetric key-
wrapping scheme, not the size of the RSA modulus. wrapping scheme, not the size of the RSA modulus.
The RSA-KEM Key Transport Algorithm in various forms is being adopted The RSA-KEM Key Transport Algorithm in various forms is being adopted
in several draft standards including the draft ANS X9.44 [ANS-X9.44] in several draft standards as well as in ANS-X9.44 and ISO/IEC 18033-2.
and ISO/IEC 18033-2. It has also been recommended by the NESSIE It has also been recommended by the NESSIE project [NESSIE]. For
project [NESSIE]. For completeness, a specification of the algorithm completeness, a specification of the algorithm is given in Appendix A
of this document; ASN.1 syntax is given in Appendix B.
is given in Appendix A of this document; ASN.1 syntax is given in
Appendix B.
NOTE: The term KEM stands for "key encapsulation mechanism" and NOTE: The term KEM stands for "key encapsulation mechanism" and
refers to the first three steps of the process above. The refers to the first three steps of the process above. The
formalization of key transport algorithms (or more generally, formalization of key transport algorithms (or more generally,
asymmetric encryption schemes) in terms of key encapsulation asymmetric encryption schemes) in terms of key encapsulation
mechanisms is described further in research by Victor Shoup leading mechanisms is described further in research by Victor Shoup leading
to the development of the ISO/IEC 18033-2 standard [SHOUP]. to the development of the ISO/IEC 18033-2 standard [SHOUP].
2. Use in CMS 2. Use in CMS
skipping to change at page 8, line 27 skipping to change at page 8, line 15
PROFILE Housley, R., Polk, W., Ford, W. and D. Solo. PROFILE Housley, R., Polk, W., Ford, W. and D. Solo.
Internet X.509 Public Key Infrastructure: Internet X.509 Public Key Infrastructure:
Certificate and Certificate Revocation List (CRL) Certificate and Certificate Revocation List (CRL)
Profile. RFC 3280. April 2002. Profile. RFC 3280. April 2002.
STDWORDS Bradner, S. Key Words for Use in RFCs to Indicate STDWORDS Bradner, S. Key Words for Use in RFCs to Indicate
Requirement Levels. RFC 2119. March 1997. Requirement Levels. RFC 2119. March 1997.
4.2 Informative References 4.2 Informative References
ANS-X9.44 ASC X9F1 Working Group. Draft American National ANS-X9.44 ASC X9F1 Working Group. American National
Standard X9.44: Public Key Cryptography for the Standard X9.44: Public Key Cryptography for the
Financial Services Industry -- Key Establishment Financial Services Industry -- Key Establishment
Using Integer Factorization Cryptography. Draft Using Integer Factorization Cryptography. 2007
D11, January 2006.
CMS-OAEP Housley, R. Use of the RSAES-OAEP Key Transport CMS-OAEP Housley, R. Use of the RSAES-OAEP Key Transport
Algorithm in the Cryptographic Message Syntax Algorithm in the Cryptographic Message Syntax
(CMS). RFC 3560. July 2003. (CMS). RFC 3560. July 2003.
IEEE-P1363a IEEE Std 1363a-2004: Standard Specifications for IEEE-P1363a IEEE Std 1363a-2004: Standard Specifications for
Public Key Cryptography: Additional Techniques. Public Key Cryptography: Additional Techniques.
IEEE, 2004. IEEE, 2004.
ISO-IEC-18033-2 ISO/IEC 18033-2:2005 Information technology -- ISO-IEC-18033-2 ISO/IEC 18033-2:2005 Information technology --
Security techniques -- Encryption algorithms Security techniques -- Encryption algorithms
Part 2: Asymmetric Ciphers. ISO/IEC, 2005. Part 2: Asymmetric Ciphers. ISO/IEC, 2005.
NESSIE NESSIE Consortium. Portfolio of Recommended NESSIE NESSIE Consortium. Portfolio of Recommended
Cryptographic Primitives. February 27, 2003. Cryptographic Primitives. February 27, 2003.
Available via http://www.cryptonessie.org/. Available via http://www.cryptonessie.org/.
NIST-GUIDELINE National Institute of Standards and Technology. NIST-GUIDELINE National Institute of Standards and Technology.
Special Publication 800-57: Recommendation for Key Special Publication 800-57: Recommendation for Key
Management. Part 1: General Guideline. August 2005. Management. Part 1: General Guideline. August 2005.
Available via http://csrc.nist.gov/publications/index.html. Available via:
http://csrc.nist.gov/publications/index.html.
PKCS1 Jonsson, J. and B. Kaliski. PKCS #1: RSA PKCS1 Jonsson, J. and B. Kaliski. PKCS #1: RSA
Cryptography Specifications Version 2.1. RFC 3447. Cryptography Specifications Version 2.1. RFC 3447.
February 2003. February 2003.
RANDOM Eastlake, D., S. Crocker, and J. Schiller. RANDOM Eastlake, D., S. Crocker, and J. Schiller.
Randomness Recommendations for Security. RFC 1750. Randomness Recommendations for Security. RFC 1750.
December 1994. December 1994.
SHOUP Shoup, V. A Proposal for an ISO Standard for SHOUP Shoup, V. A Proposal for an ISO Standard for
skipping to change at page 9, line 38 skipping to change at page 9, line 24
like to thank the members of the ASC X9F1 working group for their 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. contributions to drafts of ANS X9.44 which led to this specification.
Our thanks to Russ Housley as well for his guidance and Our thanks to Russ Housley as well for his guidance and
encouragement. We also appreciate the helpful direction we've encouragement. We also appreciate the helpful direction we've
received from Blake Ramsdell and Jim Schaad in bringing this document received from Blake Ramsdell and Jim Schaad in bringing this document
to fruition. to fruition.
7. Authors' Addresses 7. Authors' Addresses
James Randall James Randall
Burt Kaliski
RSA Laboratories RSA Laboratories
174 Middlesex Turnpike 174 Middlesex Turnpike
Bedford, MA 01730 Bedford, MA 01730
USA USA
{jrandall, bkaliski}@rsasecurity.com e-mail: jrandall@rsasecurity.com
Burt Kaliski
EMC
176 South Street
Hopkinton, MA 01748
USA
e-mail: kaliski_burt@emc.com
Appendix A. RSA-KEM Key Transport Algorithm Appendix A. RSA-KEM Key Transport Algorithm
The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward)
mechanism for transporting keying data to a recipient using the mechanism for transporting keying data to a recipient using the
recipient's RSA public key. recipient's RSA public key.
With this type of algorithm, a sender encrypts the keying data using With this type of algorithm, a sender encrypts the keying data using
the recipient's public key to obtain encrypted keying data. The the recipient's public key to obtain encrypted keying data. The
recipient decrypts the encrypted keying data using the recipient's recipient decrypts the encrypted keying data using the recipient's
skipping to change at page 10, line 14 skipping to change at page 10, line 4
A.1 Underlying Components A.1 Underlying Components
The algorithm has the following underlying components: The algorithm has the following underlying components:
* KDF, a key derivation function, which derives keying data of a * 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
* Wrap, a symmetric key-wrapping scheme, which encrypts keying * Wrap, a symmetric key-wrapping scheme, which encrypts keying
data using a key-encrypting key data using a key-encrypting key
In the following, kekLen denotes the length in bytes of the key- In the following, kekLen denotes the length in bytes of the key-
encrypting key for the underlying symmetric key-wrapping scheme. encrypting key for the underlying symmetric key-wrapping scheme.
In this scheme, the length of the keying data to be transported MUST In this scheme, the length of the keying data to be transported MUST
be among the lengths supported by the underlying symmetric key- be among the lengths supported by the underlying symmetric key-
wrapping scheme. (Bothe the AES and Camillia Key Wraps, for instance, wrapping scheme. (Both the AES and Camillia Key Wraps, for instance,
require the length of the keying data to be a multiple of 8 bytes, 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 and at least 16 bytes.) Usage and formatting of the keying data
(e.g., parity adjustment for Triple-DES keys) is outside the scope of (e.g., parity adjustment for Triple-DES keys) is outside the scope of
this algorithm. With some key derivation functions, it is possible to this algorithm. With some key derivation functions, it is possible to
include other information besides the shared secret value in the include other information besides the shared secret value in the
input to the function. Also, with some symmetric key-wrapping input to the function. Also, with some symmetric key-wrapping
schemes, it is possible to associate a label with the keying data. 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 Such uses are outside the scope of this document, as they are not
directly supported by CMS. directly supported by CMS.
skipping to change at page 12, line 37 skipping to change at page 12, line 25
ciphertexts C that are in range. (For example, IntegerToString ciphertexts C that are in range. (For example, IntegerToString
conversion should take the same amount of time regardless of the 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 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 intermediate results MUST be securely deleted when they are no longer
needed. needed.
Appendix B. ASN.1 Syntax Appendix B. ASN.1 Syntax
The ASN.1 syntax for identifying the RSA-KEM Key Transport Algorithm The ASN.1 syntax for identifying the RSA-KEM Key Transport Algorithm
is an extension of the syntax for the "generic hybrid cipher" in is an extension of the syntax for the "generic hybrid cipher" in
ISO/IEC 18033-2 [ISO-IEC-18033-2], and is the same as employed in the ISO/IEC 18033-2 [ISO-IEC-18033-2], and is the same as employed in
draft ANS X9.44 [ANS-X9.44]. The syntax for the scheme is given in ANS X9.44 [ANS-X9.44]. The syntax for the scheme is given in Section
Section B.1. The syntax for selected underlying components including B.1. The syntax for selected underlying components including those
those mentioned above is given in B.2. mentioned above is given in B.2.
The following object identifier prefixes are used in the definitions The following object identifier prefixes are used in the definitions
below: below:
is18033-2 OID ::= { iso(1) standard(0) is18033(18033) part2(2) } is18033-2 OID ::= { iso(1) standard(0) is18033(18033) part2(2) }
nistAlgorithm OID ::= { nistAlgorithm OID ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) joint-iso-itu-t(2) country(16) us(840) organization(1)
gov(101) csor(3) nistAlgorithm(4) gov(101) csor(3) nistAlgorithm(4)
} }
skipping to change at page 13, line 4 skipping to change at page 12, line 39
The following object identifier prefixes are used in the definitions The following object identifier prefixes are used in the definitions
below: below:
is18033-2 OID ::= { iso(1) standard(0) is18033(18033) part2(2) } is18033-2 OID ::= { iso(1) standard(0) is18033(18033) part2(2) }
nistAlgorithm OID ::= { nistAlgorithm OID ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) joint-iso-itu-t(2) country(16) us(840) organization(1)
gov(101) csor(3) nistAlgorithm(4) gov(101) csor(3) nistAlgorithm(4)
} }
pkcs-1 OID ::= { pkcs-1 OID ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1)
} }
NullParms is a more descriptive synonym for NULL when an algorithm NullParms is a more descriptive synonym for NULL when an algorithm
identifier has null parameters: identifier has null parameters:
NullParms ::= NULL NullParms ::= NULL
The material in this Appendix is based on a draft standard, ANS The material in this Appendix is based on ANS X9.44.
X9.44, and is SUBJECT TO CHANGE as that standard is developed.
B.1 RSA-KEM Key Transport Algorithm B.1 RSA-KEM Key Transport Algorithm
The object identifier for the RSA-KEM Key Transport Algorithm is the The object identifier for the RSA-KEM Key Transport Algorithm is the
same as for the "generic hybrid cipher" in the draft ANS ISO/IEC same as for the "generic hybrid cipher" in ISO/IEC 18033-2,
18033-2, id-ac-generic-hybrid, which is defined in the draft as id-ac-generic-hybrid, which is defined in the draft as:
id-ac-generic-hybrid OID ::= { id-ac-generic-hybrid OID ::= {
is18033-2 asymmetric-cipher(1) generic-hybrid(2) is18033-2 asymmetric-cipher(1) generic-hybrid(2)
} }
The associated parameters for id-ac-generic-hybrid have type The associated parameters for id-ac-generic-hybrid have type
GenericHybridParameters: GenericHybridParameters:
GenericHybridParameters ::= { GenericHybridParameters ::= {
kem KeyEncapsulationMechanism, kem KeyEncapsulationMechanism,
skipping to change at page 14, line 14 skipping to change at page 13, line 44
RsaKemParameters ::= { RsaKemParameters ::= {
keyDerivationFunction KeyDerivationFunction, keyDerivationFunction KeyDerivationFunction,
keyLength KeyLength keyLength KeyLength
} }
The fields of type RsaKemParameters have the following The fields of type RsaKemParameters have the following
meanings: meanings:
* keyDerivationFunction identifies the underlying key * keyDerivationFunction identifies the underlying key
derivation function. For alignment with the draft ANS derivation function. For alignment with ANS X9.44, it
X9.44, it MUST be KDF2 or KDF3. However, other key MUST be KDF2 or KDF3. However, other key derivation
derivation functions MAY be used with CMS. Please see functions MAY be used with CMS. Please see B.2.1 for the
B.2.1 for the syntax for KDF2 and KDF3. syntax for KDF2 and KDF3.
KeyDerivationFunction ::= KeyDerivationFunction ::=
AlgorithmIdentifier {{KDFAlgorithms}} AlgorithmIdentifier {{KDFAlgorithms}}
KDFAlgorithms ALGORITHM ::= { KDFAlgorithms ALGORITHM ::= {
kdf2 | kdf3, kdf2 | kdf3,
... -- implementations may define other methods ... -- implementations may define other methods
} }
* keyLength is the length in bytes of the key-encrypting * keyLength is the length in bytes of the key-encrypting
key, which depends on the underlying symmetric key- key, which depends on the underlying symmetric key-
wrapping scheme. wrapping scheme.
KeyLength ::= INTEGER (1..MAX) KeyLength ::= INTEGER (1..MAX)
* dem identifies the underlying data encapsulation mechanism. * dem identifies the underlying data encapsulation mechanism.
For alignment with the draft ANS X9.44, it MUST be an X9- For alignment with ANS X9.44, it MUST be an X9-approved
approved symmetric key-wrapping scheme. (See Note.) However, symmetric key-wrapping scheme. (See Note.) However, other
other symmetric key-wrapping schemes MAY be used with CMS. symmetric key-wrapping schemes MAY be used with CMS. Please see
Please see B.2.2 for the syntax for the AES, Triple-DES, and B.2.2 for the syntax for the AES, Triple-DES, and Camillia Key
Camillia Key Wraps. Wraps.
DataEncapsulationMechanism ::= DataEncapsulationMechanism ::=
AlgorithmIdentifier {{DEMAlgorithms}} AlgorithmIdentifier {{DEMAlgorithms}}
DEMAlgorithms ALGORITHM ::= { DEMAlgorithms ALGORITHM ::= {
X9-SymmetricKeyWrappingSchemes, X9-SymmetricKeyWrappingSchemes,
Camillia-KeyWrappingSchemes, Camillia-KeyWrappingSchemes,
... -- implementations may define other methods ... -- implementations may define other methods
} }
skipping to change at page 15, line 21 skipping to change at page 14, line 47
mechanisms in the RSA-KEM Key Transport Algorithm. ISO/IEC 18033-2 mechanisms in the RSA-KEM Key Transport Algorithm. ISO/IEC 18033-2
allows only three specific data encapsulation mechanisms, not allows only three specific data encapsulation mechanisms, not
including any of these symmetric key-wrapping schemes. However, the including any of these symmetric key-wrapping schemes. However, the
ASN.1 syntax in that document expects that additional algorithms will ASN.1 syntax in that document expects that additional algorithms will
be allowed. be allowed.
B.2 Selected Underlying Components B.2 Selected Underlying Components
B.2.1 Key Derivation Functions B.2.1 Key Derivation Functions
The object identifier for KDF2 (see [ISO-IEC-18033-2]) is The object identifier for KDF2 (see [ANS X9.44]) is:
id-kdf-kdf2 OID ::= { x9-44-components kdf2(1) }
The associated parameters identify the underlying hash function. For The associated parameters identify the underlying hash function. For
alignment with the draft ANS X9.44, the hash function MUST be an ASC alignment with ANS X9.44, the hash function MUST be an ASC
X9-approved hash function. However, other hash functions MAY be used X9-approved hash function. However, other hash functions MAY be used
with CMS. with CMS.
kdf2 ALGORITHM ::= {{ OID id-kdf-kdf2 PARMS KDF2-HashFunction }} kdf2 ALGORITHM ::= {{ OID id-kdf-kdf2 PARMS KDF2-HashFunction }}
KDF2-HashFunction ::= AlgorithmIdentifier {{KDF2-HashFunctions}} KDF2-HashFunction ::= AlgorithmIdentifier {{KDF2-HashFunctions}}
KDF2-HashFunctions ALGORITHM ::= { KDF2-HashFunctions ALGORITHM ::= {
X9-HashFunctions, X9-HashFunctions,
... -- implementations may define other methods ... -- implementations may define other methods
} }
X9-HashFunctions ALGORITHM ::= { X9-HashFunctions ALGORITHM ::= {
sha1 | sha224 | sha256 | sha384 | sha512, sha1 | sha224 | sha256 | sha384 | sha512,
... -- allows for future expansion ... -- allows for future expansion
skipping to change at page 16, line 23 skipping to change at page 15, line 42
also discussed in [PKCS1], implementations SHOULD generate algorithm also discussed in [PKCS1], implementations SHOULD generate algorithm
identifiers without parameters, and MUST accept algorithm identifiers identifiers without parameters, and MUST accept algorithm identifiers
either without parameters, or with NULL parameters. either without parameters, or with NULL parameters.
sha1 ALGORITHM ::= {{ OID id-sha1 }} -- NULLParms MUST be sha1 ALGORITHM ::= {{ OID id-sha1 }} -- NULLParms MUST be
sha224 ALGORITHM ::= {{ OID id-sha224 }} -- accepted for these sha224 ALGORITHM ::= {{ OID id-sha224 }} -- accepted for these
sha256 ALGORITHM ::= {{ OID id-sha256 }} -- OIDs sha256 ALGORITHM ::= {{ OID id-sha256 }} -- OIDs
sha384 ALGORITHM ::= {{ OID id-sha384 }} - "" sha384 ALGORITHM ::= {{ OID id-sha384 }} - ""
sha512 ALGORITHM ::= {{ OID id-sha512 }} - "" sha512 ALGORITHM ::= {{ OID id-sha512 }} - ""
The object identifier for KDF3 is: The object identifier for KDF3 (see [ANS X9.44]) is:
id-kdf-kdf3 OID ::= { id-kdf-kdf3 OID ::= { x9-44-components kdf3(2) }
to be assigned
}
The associated parameters identify the underlying hash function. For The associated parameters identify the underlying hash function. For
alignment with the draft ANS X9.44, the hash function MUST be an ASC alignment with the draft ANS X9.44, the hash function MUST be an ASC
X9-approved hash function. (See Note.) However, other hash functions X9-approved hash function. (See Note.) However, other hash functions
MAY be used with CMS. MAY be used with CMS.
kdf3 ALGORITHM ::= {{ OID id-kdf-kdf3 PARMS KDF3-HashFunction }} kdf3 ALGORITHM ::= {{ OID id-kdf-kdf3 PARMS KDF3-HashFunction }}
KDF3-HashFunction ::= AlgorithmIdentifier {{KDF3-HashFunctions}} KDF3-HashFunction ::= AlgorithmIdentifier {{KDF3-HashFunctions}}
KDF3-HashFunctions ALGORITHM ::= { KDF3-HashFunctions ALGORITHM ::= {
X9-HashFunctions, X9-HashFunctions,
... -- implementations may define other methods ... -- implementations may define other methods
} }
B.2.2 Symmetric Key-Wrapping Schemes B.2.2 Symmetric Key-Wrapping Schemes
The object identifiers for the AES Key Wrap depends on the size of The object identifiers for the AES Key Wrap depends on the size of
the key encrypting key. There are three object identifiers (see the key encrypting key. There are three object identifiers (see
[AES-WRAP]): [AES-WRAP]):
skipping to change at page 20, line 6 skipping to change at page 19, line 6
X9-SymmetricKeyWrappingSchemes ALGORITHM ::= { X9-SymmetricKeyWrappingSchemes ALGORITHM ::= {
aes128-Wrap | aes192-Wrap | aes256-Wrap | tdes-Wrap, aes128-Wrap | aes192-Wrap | aes256-Wrap | tdes-Wrap,
... -- allows for future expansion ... -- allows for future expansion
} }
Camillia-KeyWrappingSchemes ALGORITHM ::= { Camillia-KeyWrappingSchemes ALGORITHM ::= {
camillia128-Wrap | camillia192-Wrap | camillia128-Wrap camillia128-Wrap | camillia192-Wrap | camillia128-Wrap
} }
-- Key Derivation Functions -- Key Derivation Functions
id-kdf-kdf2 OID ::= { is18033-2 key-derivation-functions(5) kdf2(2) } id-kdf-kdf2 OID ::= { x9-44-components kdf2(1) }
kdf2 ALGORITHM ::= {{ OID id-kdf-kdf2 PARMS KDF2-HashFunction }} kdf2 ALGORITHM ::= {{ OID id-kdf-kdf2 PARMS KDF2-HashFunction }}
KDF2-HashFunction ::= AlgorithmIdentifier {{KDF2-HashFunctions}} KDF2-HashFunction ::= AlgorithmIdentifier {{KDF2-HashFunctions}}
KDF2-HashFunctions ALGORITHM ::= { KDF2-HashFunctions ALGORITHM ::= {
X9-HashFunctions, X9-HashFunctions,
... -- implementations may define other methods ... -- implementations may define other methods
} }
-- id-kdf-kdf3 OID ::= (to be assigned) -- id-kdf-kdf3 OID ::= { x9-44-components kdf3(2) }
kdf3 ALGORITHM ::= {{ OID id-kdf-kdf2 PARMS KDF3-HashFunction }} kdf3 ALGORITHM ::= {{ OID id-kdf-kdf2 PARMS KDF3-HashFunction }}
KDF3-HashFunction ::= AlgorithmIdentifier {{KDF3-HashFunctions}} KDF3-HashFunction ::= AlgorithmIdentifier {{KDF3-HashFunctions}}
KDF3-HashFunctions ALGORITHM ::= { KDF3-HashFunctions ALGORITHM ::= {
X9-HashFunctions, X9-HashFunctions,
... -- implementations may define other methods ... -- implementations may define other methods
} }
skipping to change at page 23, line 30 skipping to change at page 22, line 21
* KDF2 based on SHA-1, Triple-DES Key Wrap with a 128-bit KEK * KDF2 based on SHA-1, Triple-DES Key Wrap with a 128-bit KEK
(two-key triple-DES) (two-key triple-DES)
30 4f 06 07 28 81 8c 71 02 01 02 30 44 30 21 06 30 4f 06 07 28 81 8c 71 02 01 02 30 44 30 21 06
07 28 81 8c 71 02 02 04 30 16 30 12 06 07 28 81 07 28 81 8c 71 02 02 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 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 30 0f 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06 05
00 00
* KDF2 based on SHA-224, Triple-DES Key Wrap with a 192-bit
KEK (three-key triple-DES)
[[to be defined]]
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The IETF Trust (2007).
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
Disclaimer Statement
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 34 change blocks. 
74 lines changed or deleted 56 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/