draft-ietf-smime-cms-rsa-kem-12.txt   draft-ietf-smime-cms-rsa-kem-13.txt 
S/MIME WG James Randall, Randall Consulting S/MIME WG James Randall, Randall Consulting
Internet Draft Burt Kaliski, EMC Internet Draft Burt Kaliski, EMC
Intended Status: Standards Track John Brainard, RSA Intended Status: Standards Track John Brainard, RSA
Sean Turner, IECA Sean Turner, IECA
Expires: September 8, 2010 March 8, 2010 Expires: November 29, 2010 May 29, 2010
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-12.txt> <draft-ietf-smime-cms-rsa-kem-13.txt>
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). The ASN.1 syntax is aligned with ANS X9.44 and Message Syntax (CMS). The ASN.1 syntax is aligned with an expected
ISO/IEC 18033-2. forthcoming change to ANS X9.44.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 time. It is inappropriate to use Internet-Drafts as reference
material 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/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
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
This Internet-Draft will expire on September 8, 2010. This Internet-Draft will expire on November 29, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 41 skipping to change at page 2, line 41
1. Introduction...................................................3 1. Introduction...................................................3
2. Use in CMS.....................................................4 2. Use in CMS.....................................................4
2.1. Underlying Components.....................................4 2.1. Underlying Components.....................................4
2.2. RecipientInfo Conventions.................................5 2.2. RecipientInfo Conventions.................................5
2.3. Certificate Conventions...................................5 2.3. Certificate Conventions...................................5
2.4. SMIMECapabilities Attribute Conventions...................6 2.4. SMIMECapabilities Attribute Conventions...................6
3. Security Considerations........................................7 3. Security Considerations........................................7
4. IANA Considerations............................................9 4. IANA Considerations............................................9
5. Acknowledgements...............................................9 5. Acknowledgements...............................................9
6. References.....................................................9 6. References....................................................10
6.1. Normative References......................................9 6.1. Normative References.....................................10
6.2. Informative References...................................10 6.2. Informative References...................................11
Appendix A. RSA-KEM Key Transport Algorithm......................11 Appendix A. RSA-KEM Key Transport Algorithm......................11
A.1. Underlying Components....................................11 A.1. Underlying Components....................................12
A.2. Sender's Operations......................................12 A.2. Sender's Operations......................................12
A.3. Recipient's Operations...................................13 A.3. Recipient's Operations...................................13
Appendix B. ASN.1 Syntax.........................................14 Appendix B. ASN.1 Syntax.........................................15
B.1. RSA-KEM Key Transport Algorithm..........................15 B.1. RSA-KEM Key Transport Algorithm..........................15
B.2 Selected Underlying Components............................17 B.2. Selected Underlying Components...........................17
B.2.1. Key Derivation Functions............................17 B.2.1. Key Derivation Functions............................17
B.2.2 Symmetric Key-Wrapping Schemes.......................19 B.2.2. Symmetric Key-Wrapping Schemes......................19
B.3 ASN.1 module..............................................20 B.3. ASN.1 module.............................................20
B.4 Examples..................................................25 B.4. Examples.................................................26
Authors' Addresses...............................................27 Authors' Addresses...............................................28
1. Introduction 1. Introduction
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.
Most previous key transport algorithms based on the RSA public-key Most previous key transport algorithms based on the RSA public-key
cryptosystem (e.g., the popular PKCS #1 v1.5 algorithm [PKCS1]) have cryptosystem (e.g., the popular PKCS #1 v1.5 algorithm [PKCS1]) have
the following general form: the following general form:
skipping to change at page 4, line 15 skipping to change at page 4, line 15
result, the algorithm enjoys a "tight" security proof in the random result, the algorithm enjoys a "tight" security proof in the random
oracle model. (In other padding schemes, such as PKCS #1 v1.5, the 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 input has structure and/or depends on the keying data, and the
provable security assurances are not as strong.) The approach is also provable security assurances are not as strong.) The approach is also
architecturally convenient because the public-key operations are architecturally convenient because the public-key operations are
separate from the symmetric operations on the keying data. Another separate from the symmetric operations on the keying data. Another
benefit is that the length of the keying data is bounded only by the benefit is that the length of the keying data is bounded only by the
symmetric key-wrapping scheme, not the size of the RSA modulus. symmetric key-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 as well as in ANS-X9.44 and ISO/IEC 18033- in several draft standards as well as in ANS-X9.44 [ANS-9.44]. It has
2. It has also been recommended by the NESSIE project [NESSIE]. also been recommended by the NESSIE project [NESSIE]. Originally,
[ANS-9.44] specified the of different object identifier to identify
the RSA-KEM Key Transport Algorithm. [ANS-9.44] used id-ac-generic-
hybrid while this document uses id-rsa-kem. These OIDs are used in
the KeyTransportInfo field to indicate the key encryption algorithm,
in certificates to allow recipients to restrict their public keys for
use with RSA-KEM only, and in SMIME Capability attributes to allow
recipients to advertise their support for RSA-KEM. Legacy
implementations that wish to interoperate with [ANS-X9.44] should
consult that specification for more information on id-ac-generic-
hybrid.
For completeness, a specification of the algorithm is given in For completeness, a specification of the algorithm is given in
Appendix A of this document; ASN.1 syntax is given in Appendix B. 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].
skipping to change at page 4, line 40 skipping to change at page 5, line 5
The RSA-KEM Key Transport Algorithm MAY be employed for one or more The RSA-KEM Key Transport Algorithm MAY be employed for one or more
recipients in the CMS enveloped-data content type (Section 6 of recipients in the CMS enveloped-data content type (Section 6 of
[CMS]), where the keying data processed by the algorithm is the CMS [CMS]), where the keying data processed by the algorithm is the CMS
content-encryption key. content-encryption key.
2.1. Underlying Components 2.1. Underlying Components
A CMS implementation that supports the RSA-KEM Key Transport A CMS implementation that supports the RSA-KEM Key Transport
Algorithm MUST support at least the following underlying components: Algorithm MUST support at least the following underlying components:
o For the key derivation function, KDF3 (see [IEEE-P1363a]) based on o For the key derivation function, KDF3 (see [ANS-9.44]) based on
SHA-256 (see [FIPS-180-3]). KDF3 is an instantiation of the SHA-256 (see [FIPS-180-3]). KDF3 is an instantiation of the
Concatenation Key Derivation Function defined in [NIST-SP800-56A]. Concatenation Key Derivation Function defined in [NIST-SP800-
56A].
o For the key-wrapping scheme, AES-Wrap-128, i.e., the AES Key Wrap o For the key-wrapping scheme, AES-Wrap-128, i.e., the AES Key
with a 128-bit key encrypting key (see [AES-WRAP]). Wrap with a 128-bit key encrypting key (see [AES-WRAP]).
An implementation SHOULD also support KDF2 (see [ANS-X9.44]) based on An implementation SHOULD also support KDF2 (see [ANS-X9.44]) based on
SHA-1 (this function is also specified as the key derivation function SHA-1 (this function is also specified as the key derivation function
in [ANS-X9.63]). The Camellia key wrap algorithm (see [CAMELLIA]) in [ANS-X9.63]). The Camellia key wrap algorithm (see [CAMELLIA])
SHOULD be supported if Camellia is supported as a content-encryption SHOULD be supported if Camellia is supported as a content-encryption
cipher. The Triple-DES Key Wrap (see [3DES-WRAP]) SHOULD also be cipher. The Triple-DES Key Wrap (see [3DES-WRAP]) SHOULD also be
supported if Triple-DES is supported as a content-encryption cipher. supported if Triple-DES is supported as a content-encryption cipher.
It MAY support other underlying components. When AES or Camellia are It MAY support other underlying components. When AES or Camellia are
used, the data block size is 128 bits and the key size can be 128, 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 192, or 256 bits, while Triple DES requires a data block size of 64
bits and a key size of 112 or 168 bits. bits and a key size of 112 or 168 bits.
2.2. RecipientInfo Conventions 2.2. RecipientInfo Conventions
When the RSA-KEM Key Transport Algorithm is employed for a recipient, When the RSA-KEM Key Transport Algorithm is employed for a recipient,
the RecipientInfo alternative for that recipient MUST be the RecipientInfo alternative for that recipient MUST be
KeyTransRecipientInfo. The algorithm-specific fields of the KeyTransRecipientInfo. The algorithm-specific fields of the
KeyTransRecipientInfo value MUST have the following values: KeyTransRecipientInfo value MUST have the following values:
o keyEncryptionAlgorithm.algorithm MUST be id-rsa-kem (see Appendix o keyEncryptionAlgorithm.algorithm MUST be id-rsa-kem (see
B); Appendix B);
o keyEncryptionAlgorithm.parameters MUST be a value of type o keyEncryptionAlgorithm.parameters MUST be a value of type
GenericHybridParameters, identifying the RSA-KEM key encapsulation GenericHybridParameters, identifying the RSA-KEM key
mechanism (see Appendix B); encapsulation mechanism (see Appendix B);
o encryptedKey MUST be the encrypted keying data output by the o encryptedKey MUST be the encrypted keying data output by the
algorithm, where the keying data is the content-encryption key (see algorithm, where the keying data is the content-encryption key
Appendix A). (see Appendix A).
2.3. Certificate Conventions 2.3. Certificate Conventions
The conventions specified in this section augment RFC 5280 [PROFILE]. The conventions specified in this section augment RFC 5280 [PROFILE].
A recipient who employs the RSA-KEM Key Transport Algorithm MAY A recipient who employs the RSA-KEM Key Transport Algorithm MAY
identify the public key in a certificate by the same identify the public key in a certificate by the same
AlgorithmIdentifier as for the PKCS #1 v1.5 algorithm, i.e., using AlgorithmIdentifier as for the PKCS #1 v1.5 algorithm, i.e., using
the rsaEncryption object identifier [PKCS1]. The fact that the user the rsaEncryption object identifier [PKCS1]. The fact that the user
will accept RSA-KEM with this public key is not indicated by the use will accept RSA-KEM with this public key is not indicated by the use
of this identifier. This may be signalled by the use of the of this identifier. This MAY be signaled by the use of the
appropriate SMIME Capabilities either in a message or in the appropriate SMIME Capabilities either in a message or in the
certificate. certificate.
If the recipient wishes only to employ the RSA-KEM Key Transport If the recipient wishes only to employ the RSA-KEM Key Transport
Algorithm with a given public key, the recipient MUST identify the Algorithm with a given public key, the recipient MUST identify the
public key in the certificate using the id-rsa-kem object identifier public key in the certificate using the id-rsa-kem object identifier
(see Appendix B). When the id-rsa-kem algorithm identifier appears in (see Appendix B). When the id-rsa-kem algorithm identifier appears in
the SubjectPublicKeyInfo algorithm field, the encoding SHALL omit the the SubjectPublicKeyInfo algorithm field, the encoding SHALL omit the
parameters field from AlgorithmIdentifier. That is, the parameters field from AlgorithmIdentifier. That is, the
AlgorithmIdentifier SHALL be a SEQUENCE of one component, the object AlgorithmIdentifier SHALL be a SEQUENCE of one component, the object
skipping to change at page 7, line 39 skipping to change at page 8, line 5
construction is reasonable; a key derivation function would need to construction is reasonable; a key derivation function would need to
be particularly weak to lead to an attack that is not possible in the be particularly weak to lead to an attack that is not possible in the
random oracle model. random oracle model.
The RSA key size and the underlying components should be selected The RSA key size and the underlying components should be selected
consistent with the desired symmetric security level for an consistent with the desired symmetric security level for an
application. Several security levels have been identified in NIST application. Several security levels have been identified in NIST
FIPS PUB 800-57 [NIST-GUIDELINE]. For brevity, the first three levels FIPS PUB 800-57 [NIST-GUIDELINE]. For brevity, the first three levels
are mentioned here: are mentioned here:
o 80-bit security. The RSA key size SHOULD be at least 1024 bits, o 80-bit security. The RSA key size SHOULD be at least 1024 bits,
the hash function underlying the KDF SHOULD be SHA-1 or above, and the hash function underlying the KDF SHOULD be SHA-1 or above,
the symmetric key-wrapping scheme SHOULD be AES Key Wrap, Triple-DES and the symmetric key-wrapping scheme SHOULD be AES Key Wrap,
Key Wrap, or Camellia Key Wrap. Triple-DES Key Wrap, or Camellia Key Wrap.
o 112-bit security. The RSA key size SHOULD be at least 2048 bits, o 112-bit security. The RSA key size SHOULD be at least 2048 bits,
the hash function underlying the KDF SHOULD be SHA-224 or above, and the hash function underlying the KDF SHOULD be SHA-224 or above,
the symmetric key-wrapping scheme SHOULD be AES Key Wrap, Triple-DES and the symmetric key-wrapping scheme SHOULD be AES Key Wrap,
Key Wrap, or Camellia Key Wrap. Triple-DES Key Wrap, or Camellia Key Wrap.
o 128-bit security. The RSA key size SHOULD be at least 3072 bits, o 128-bit security. The RSA key size SHOULD be at least 3072 bits,
the hash function underlying the KDF SHOULD be SHA-256 or above, and the hash function underlying the KDF SHOULD be SHA-256 or above,
the symmetric key-wrapping scheme SHOULD be AES Key Wrap or Camellia and the symmetric key-wrapping scheme SHOULD be AES Key Wrap or
Key Wrap. Camellia Key Wrap.
Note that the AES Key Wrap or Camellia Key Wrap MAY be used at all 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 three of these levels; the use of AES or Camellia does not require a
128-bit security level for other components. 128-bit security level for other components.
Implementations MUST protect the RSA private key and the content- Implementations MUST protect the RSA private key and the content-
encryption key. Compromise of the RSA private key may result in the encryption key. Compromise of the RSA private key may result in the
disclosure of all messages protected with that key. Compromise of the disclosure of all messages protected with that key. Compromise of the
content-encryption key may result in disclosure of the associated content-encryption key may result in disclosure of the associated
encrypted content. encrypted content.
skipping to change at page 9, line 47 skipping to change at page 10, line 16
6.1. Normative References 6.1. Normative References
[3DES-WRAP] Housley, R. Triple-DES and RC2 Key Wrapping. RFC [3DES-WRAP] Housley, R. Triple-DES and RC2 Key Wrapping. RFC
3217. December 2001. 3217. December 2001.
[AES-WRAP] Schaad, J. and R. Housley. Advanced Encryption [AES-WRAP] Schaad, J. and R. Housley. Advanced Encryption
Standard (AES) Key Wrap Algorithm. RFC 3394. Standard (AES) Key Wrap Algorithm. RFC 3394.
September 2002. September 2002.
[ANS-X9.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.
[ANS-X9.63] American National Standard X9.63-2002: Public Key [ANS-X9.63] American National Standard X9.63-2002: Public Key
Cryptography for the Financial Services Industry: Cryptography for the Financial Services Industry:
Key Agreement and Key Transport Using Elliptic Key Agreement and Key Transport Using Elliptic
Curve Cryptography. Curve Cryptography.
[CAMELLIA] Kato, A., Moriai, S., and Kanda, M.: Use of the [CAMELLIA] Kato, A., Moriai, S., and Kanda, M.: Use of the
Camellia Encryption Algorithm in Cryptographic Camellia Encryption Algorithm in Cryptographic
Message Syntax. RFC 3657. December 2005. Message Syntax. RFC 3657. December 2005.
[CMS] Housley, R. Cryptographic Message Syntax. RFC [CMS] Housley, R. Cryptographic Message Syntax. RFC
skipping to change at page 10, line 37 skipping to change at page 11, line 11
[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.
6.2. Informative References 6.2. Informative References
[AES-WRAP-PAD] Housley, R., and M. Dworkin. Advanced Encryption [AES-WRAP-PAD] Housley, R., and M. Dworkin. Advanced Encryption
Standard (AES) Key Wrap with Padding Algorithm. Standard (AES) Key Wrap with Padding Algorithm.
RFC 5649. August 2009. RFC 5649. August 2009.
[ANS-X9.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.
[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
Public Key Cryptography: Additional Techniques.
IEEE, 2004.
[ISO-IEC-18033-2] ISO/IEC 18033-2:2005 Information technology --
Security techniques -- Encryption algorithms --
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 Special Publication 800-57: Recommendation for
Pairwise Key Establishment Schemes Using Discrete 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. http://csrc.nist.gov/publications/index.html.
skipping to change at page 12, line 5 skipping to change at page 12, line 11
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
private key to recover the keying data. private key to recover the keying data.
A.1. Underlying Components A.1. Underlying Components
The algorithm has the following underlying components: The algorithm has the following underlying components:
o KDF, a key derivation function, which derives keying data of a 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 key-wrapping scheme, which encrypts keying Data o Wrap, a symmetric key-wrapping scheme, which encrypts keying
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. (Both the AES and Camellia Key Wraps, for instance, 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, 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
skipping to change at page 12, line 45 skipping to change at page 13, line 5
The sender performs the following operations: The sender performs the following operations:
1. Generate a random integer z between 0 and n-1 (see Note), and 1. Generate a random integer z between 0 and n-1 (see Note), and
convert z to a byte string Z of length nLen, most significant byte convert z to a byte string Z of length nLen, most significant byte
first: first:
z = RandomInteger (0, n-1) z = RandomInteger (0, n-1)
Z = IntegerToString (z, nLen) Z = IntegerToString (z, nLen)
2. Encrypt the random integer z using the recipient's public key n,e) 2. Encrypt the random integer z using the recipient's public key
and convert the resulting integer c to a ciphertext C, a byte string (n,e) and convert the resulting integer c to a ciphertext C, a byte
of length nLen: string of length nLen:
c = z^e mod n c = z^e mod n
C = IntegerToString (c, nLen) C = IntegerToString (c, nLen)
3. Derive a key-encrypting key KEK of length kekLen bytes from the 3. Derive a key-encrypting key KEK of length kekLen bytes from the
byte string Z using the underlying key derivation function: byte string Z using the underlying key derivation function:
KEK = KDF (Z, kekLen) KEK = KDF (Z, kekLen)
skipping to change at page 14, line 44 skipping to change at page 15, line 8
of the implementation SHOULD be the same at these steps for all of the implementation SHOULD be the same at these steps for all
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 ANS
ISO/IEC 18033-2 [ISO-IEC-18033-2], and is the same as employed in ANS
X9.44 [ANS-X9.44]. The syntax for the scheme is given in Section B.1. X9.44 [ANS-X9.44]. The syntax for the scheme is given in Section B.1.
The syntax for selected underlying components including those The syntax for selected underlying components including 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 ::= {
skipping to change at page 16, line 5 skipping to change at page 16, line 15
GenericHybridParameters is as follows: GenericHybridParameters is as follows:
GenericHybridParameters ::= { GenericHybridParameters ::= {
kem KeyEncapsulationMechanism, kem KeyEncapsulationMechanism,
dem DataEncapsulationMechanism dem DataEncapsulationMechanism
} }
The fields of type GenericHybridParameters have the following The fields of type GenericHybridParameters have the following
meanings: meanings:
o kem identifies the underlying key encapsulation mechanism, which o kem identifies the underlying key encapsulation mechanism, which
in this case is also denoted as RSA-KEM, per ISO/IEC 18033-2. in this case is also denoted as RSA-KEM.
The object identifier for RSA-KEM (as a key encapsulation The object identifier for RSA-KEM (as a key encapsulation
mechanism) is id-kem-rsa, which is defined in ISO/IEC 18033-2 as: mechanism) is id-kem-rsa as:
id-kem-rsa OID ::= { id-kem-rsa OID ::= {
is18033-2 key-encapsulation-mechanism(2) rsa(4) is18033-2 key-encapsulation-mechanism(2) rsa(4)
} }
The associated parameters for id-kem-rsa have type The associated parameters for id-kem-rsa have type
RsaKemParameters: RsaKemParameters:
RsaKemParameters ::= { RsaKemParameters ::= {
keyDerivationFunction KeyDerivationFunction, keyDerivationFunction KeyDerivationFunction,
skipping to change at page 16, line 42 skipping to change at page 17, line 5
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 key, * keyLength is the length in bytes of the key-encrypting key,
which depends on the underlying symmetric key-wrapping scheme. which depends on the underlying symmetric key-wrapping scheme.
KeyLength ::= INTEGER (1..MAX) KeyLength ::= INTEGER (1..MAX)
o dem identifies the underlying data encapsulation mechanism. For o dem identifies the underlying data encapsulation mechanism. For
alignment with ANS X9.44, it MUST be an X9-approved symmetric alignment with ANS X9.44, it MUST be an X9-approved symmetric
key-wrapping scheme. (See Note.) However, other symmetric key- key-wrapping scheme. (See Note.) However, other symmetric key-
wrapping schemes MAY be used with CMS. Please see B.2.2 for the wrapping schemes MAY be used with CMS. Please see B.2.2 for the
syntax for the AES, Triple-DES, and Camellia Key Wraps. syntax for the AES, Triple-DES, and Camellia Key Wraps.
DataEncapsulationMechanism ::= DataEncapsulationMechanism ::=
AlgorithmIdentifier {{DEMAlgorithms}} AlgorithmIdentifier {{DEMAlgorithms}}
DEMAlgorithms ALGORITHM ::= { DEMAlgorithms ALGORITHM ::= {
X9-SymmetricKeyWrappingSchemes, X9-SymmetricKeyWrappingSchemes,
Camellia-KeyWrappingSchemes, Camellia-KeyWrappingSchemes,
... -- implementations may define other methods ... -- implementations may define other methods
} }
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
} }
Camellia-KeyWrappingSchemes ALGORITHM ::= { Camellia-KeyWrappingSchemes ALGORITHM ::= {
Camellia128-Wrap | Camellia192-Wrap | Camellia256-Wrap Camellia128-Wrap | Camellia192-Wrap | Camellia256-Wrap
} }
NOTE: The generic hybrid cipher in ISO/IEC 18033-2 can encrypt B.2. Selected Underlying Components
arbitrary data, hence the term "data encapsulation mechanism". The
symmetric key-wrapping schemes take the role of data encapsulation
mechanisms in the RSA-KEM Key Transport Algorithm. ISO/IEC 18033-2
allows only three specific data encapsulation mechanisms, not
including any of these symmetric key-wrapping schemes. However, the
ASN.1 syntax in that document expects that additional algorithms will
be allowed.
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: The object identifier for KDF2 (see [ANS X9.44]) is:
id-kdf-kdf2 OID ::= { x9-44-components kdf2(1) } 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 ANS X9.44, the hash function MUST be an ASC X9- alignment with ANS X9.44, the hash function MUST be an ASC X9-
approved hash function. However, other hash functions MAY be used approved hash function. However, other hash functions MAY be used
skipping to change at page 19, line 7 skipping to change at page 19, line 7
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 [AES- the key encrypting key. There are three object identifiers (see [AES-
WRAP]): WRAP]):
id-aes128-Wrap OID ::= { nistAlgorithm aes(1) aes128-Wrap(5) } id-aes128-Wrap OID ::= { nistAlgorithm aes(1) aes128-Wrap(5) }
id-aes192-Wrap OID ::= { nistAlgorithm aes(1) aes192-Wrap(25) } id-aes192-Wrap OID ::= { nistAlgorithm aes(1) aes192-Wrap(25) }
id-aes256-Wrap OID ::= { nistAlgorithm aes(1) aes256-Wrap(45) } id-aes256-Wrap OID ::= { nistAlgorithm aes(1) aes256-Wrap(45) }
These object identifiers have no associated parameters. These object identifiers have no associated parameters.
skipping to change at page 20, line 21 skipping to change at page 20, line 21
{ iso(1) member-body(2) 392 200011 61 security(1) { iso(1) member-body(2) 392 200011 61 security(1)
algorithm(1) key-wrap-algorithm(3) algorithm(1) key-wrap-algorithm(3)
camellia256-wrap(4) } camellia256-wrap(4) }
These object identifiers have no associated parameters. These object identifiers have no associated parameters.
camellia128-Wrap ALGORITHM ::= { OID id-camellia128-Wrap } camellia128-Wrap ALGORITHM ::= { OID id-camellia128-Wrap }
camellia192-Wrap ALGORITHM ::= { OID id-camellia192-Wrap } camellia192-Wrap ALGORITHM ::= { OID id-camellia192-Wrap }
camellia256-Wrap ALGORITHM ::= { OID id-camellia256-Wrap } camellia256-Wrap ALGORITHM ::= { OID id-camellia256-Wrap }
B.3 ASN.1 module B.3. ASN.1 module
CMS-RSA-KEM CMS-RSA-KEM
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) cms-rsa-kem(21) } pkcs-9(9) smime(16) modules(0) cms-rsa-kem(21) }
DEFINITIONS ::= DEFINITIONS ::=
BEGIN BEGIN
-- EXPORTS ALL -- EXPORTS ALL
skipping to change at page 25, line 4 skipping to change at page 25, line 6
{ iso(1) member-body(2) 392 200011 61 security(1) { iso(1) member-body(2) 392 200011 61 security(1)
algorithm(1) key-wrap-algorithm(3) algorithm(1) key-wrap-algorithm(3)
camellia192-wrap(3) } camellia192-wrap(3) }
id-camellia256-Wrap OBJECT IDENTIFIER ::= id-camellia256-Wrap OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) 392 200011 61 security(1) { iso(1) member-body(2) 392 200011 61 security(1)
algorithm(1) key-wrap-algorithm(3) algorithm(1) key-wrap-algorithm(3)
camellia256-wrap(4) } camellia256-wrap(4) }
camellia128-Wrap ALGORITHM ::= { OID id-camellia128-Wrap } camellia128-Wrap ALGORITHM ::= { OID id-camellia128-Wrap }
camellia192-Wrap ALGORITHM ::= { OID id-camellia192-Wrap } camellia192-Wrap ALGORITHM ::= { OID id-camellia192-Wrap }
camellia256-Wrap ALGORITHM ::= { OID id-camellia256-Wrap } camellia256-Wrap ALGORITHM ::= { OID id-camellia256-Wrap }
END END
B.4 Examples B.4. Examples
As an example, if the key derivation function is KDF3 based on SHA- As an example, if the key derivation function is KDF3 based on SHA-
256 and the symmetric key-wrapping scheme is the AES Key Wrap with a 256 and the symmetric key-wrapping scheme is the AES Key Wrap with a
128-bit KEK, the AlgorithmIdentifier for the RSA-KEM Key Transport 128-bit KEK, the AlgorithmIdentifier for the RSA-KEM Key Transport
Algorithm will have the following value: Algorithm will have the following value:
SEQUENCE { SEQUENCE {
id-rsa-kem, -- RSA-KEM cipher id-rsa-kem, -- RSA-KEM cipher
SEQUENCE { -- GenericHybridParameters SEQUENCE { -- GenericHybridParameters
SEQUENCE { -- key encapsulation mechanism SEQUENCE { -- key encapsulation mechanism
skipping to change at page 26, line 4 skipping to change at page 26, line 30
SEQUENCE { -- KDF3-HashFunction SEQUENCE { -- KDF3-HashFunction
id-sha256 -- SHA-256; no parameters (preferred) id-sha256 -- SHA-256; no parameters (preferred)
}, },
16 -- KEK length in bytes 16 -- KEK length in bytes
}, },
SEQUENCE { -- data encapsulation mechanism SEQUENCE { -- data encapsulation mechanism
id-aes128-Wrap -- AES-128 Wrap; no parameters id-aes128-Wrap -- AES-128 Wrap; no parameters
} }
} }
} }
This AlgorithmIdentifier value has the following DER encoding:
This AlgorithmIdentifier value has the following DER encoding (??
indicates the algorithm number which is to be assigned):
30 47 30 47
06 0b 2a 86 48 86 f7 0d 01 09 10 03 0e -- id-rsa-kem 06 0b 2a 86 48 86 f7 0d 01 09 10 03 0e -- id-rsa-kem
30 38 30 38
30 29 30 29
06 07 28 81 8c 71 02 02 04 -- id-kem-rsa 06 07 28 81 8c 71 02 02 04 -- id-kem-rsa
30 1e 30 1e
30 19 30 19
06 0a 2b 81 05 10 86 48 09 2c 01 02 -- id-kdf-kdf3 06 0a 2b 81 05 10 86 48 09 2c 01 02 -- id-kdf-kdf3
30 0b 30 0b
 End of changes. 35 change blocks. 
87 lines changed or deleted 83 lines changed or added

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