draft-ietf-smime-cms-rsa-kem-08.txt | draft-ietf-smime-cms-rsa-kem-09.txt | |||
---|---|---|---|---|

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 | ||||

S/MIME Working Group James Randall, Randall Consulting | Use of the RSA-KEM Key Transport Algorithm in CMS | |||

Internet Draft Burt Kaliski, EMC | <draft-ietf-smime-cms-rsa-kem-09.txt> | |||

John Brainard, RSA | ||||

Sean Turner, IECA | ||||

Expires: June 6, 2010 Category: Standards | ||||

December 7, 2009 | ||||

Use of the RSA-KEM Key Transport Algorithm in CMS | Status of this Memo | |||

<draft-ietf-smime-cms-rsa-kem-08.txt> | ||||

Status of this Memo | This Internet-Draft 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 | ||||

the person(s) controlling the copyright in such materials, this | ||||

document may not be modified outside the IETF Standards Process, and | ||||

derivative works of it may not be created outside the IETF Standards | ||||

Process, except to format it for publication as an RFC or to | ||||

translate it into languages other than English. | ||||

This Internet-Draft is submitted to IETF in full conformance with the | Internet-Drafts are working documents of the Internet Engineering | |||

provisions of BCP 78 and BCP 79. This document may contain material | Task Force (IETF), its areas, and its working groups. Note that | |||

from IETF Documents or IETF Contributions published or made publicly | other groups may also distribute working documents as Internet- | |||

available before November 10, 2008. The person(s) controlling the | Drafts. | |||

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 | ||||

the person(s) controlling the copyright in such materials, this | ||||

document may not be modified outside the IETF Standards Process, and | ||||

derivative works of it may not be created outside the IETF Standards | ||||

Process, except to format it for publication as an RFC or to | ||||

translate it into languages other than English. | ||||

Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are draft documents valid for a maximum of six months | |||

Task Force (IETF), its areas, and its working groups. Note that | and may be updated, replaced, or obsoleted by other documents at any | |||

other groups may also distribute working documents as Internet- | time. It is inappropriate to use Internet-Drafts as reference | |||

Drafts. | material or to cite them other than as "work in progress." | |||

Internet-Drafts are draft documents valid for a maximum of six months | The list of current Internet-Drafts can be accessed at | |||

and may be updated, replaced, or obsoleted by other documents at any | http://www.ietf.org/ietf/1id-abstracts.txt | |||

time. It is inappropriate to use Internet-Drafts as reference | ||||

material or to cite them other than as "work in progress." | ||||

The list of current Internet-Drafts can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||

http://www.ietf.org/ietf/1id-abstracts.txt | http://www.ietf.org/shadow.html | |||

The list of Internet-Draft Shadow Directories can be accessed at | This Internet-Draft will expire on June 8, 2010. | |||

http://www.ietf.org/shadow.html | ||||

Internet-Drafts are working documents of the Internet Engineering | Copyright Notice | |||

Task Force (IETF), its areas, and its working groups. Note that other | ||||

groups may also distribute working documents as Internet-Drafts. | ||||

This Internet-Draft will expire on January 6, 2010. | Copyright (c) 2009 IETF Trust and the persons identified as the | |||

document authors. All rights reserved. | ||||

Copyright Notice | 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/license-info). | ||||

Please review these documents carefully, as they describe your rights | ||||

and restrictions with respect to this document. | ||||

Copyright (c) 2009 IETF Trust and the persons identified as the | Abstract | |||

document authors. All rights reserved. | ||||

This document is subject to BCP 78 and the IETF Trust's Legal | The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) | |||

Provisions Relating to IETF Documents in effect on the date of | mechanism for transporting keying data to a recipient using the | |||

publication of this document (http://trustee.ietf.org/license-info). | recipient's RSA public key. This document specifies the conventions | |||

Please review these documents carefully, as they describe your | for using the RSA-KEM Key Transport Algorithm with the Cryptographic | |||

rights and restrictions with respect to this document. | Message Syntax (CMS). The ASN.1 syntax is aligned with ANS X9.44 and | |||

ISO/IEC 18033-2. | ||||

Comments or suggestions for improvement may be made on the "ietf- | Conventions Used in This Document | |||

smime" mailing list, or directly to the authors. | ||||

Abstract | 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]. | ||||

The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) | Table of Contents | |||

mechanism for transporting keying data to a recipient using the | ||||

recipient's RSA public key. This document specifies the conventions | ||||

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 | ||||

ISO/IEC 18033-2. | ||||

Conventions Used in This Document | 1. Introduction...................................................3 | |||

2. Use in CMS.....................................................4 | ||||

2.1. Underlying Components.....................................4 | ||||

2.2. RecipientInfo Conventions.................................5 | ||||

2.3. Certificate Conventions...................................5 | ||||

2.4. SMIMECapabilities Attribute Conventions...................6 | ||||

3. Security Considerations........................................7 | ||||

4. References.....................................................9 | ||||

4.1. Normative References......................................9 | ||||

4.2. Informative References....................................9 | ||||

Appendix A. RSA-KEM Key Transport Algorithm......................11 | ||||

A.1. Underlying Components....................................11 | ||||

A.2. Sender's Operation.......................................11 | ||||

A.3. Recipient's Operations...................................12 | ||||

Appendix B. ASN.1 Syntax.........................................14 | ||||

B.2 Selected Underlying Components............................16 | ||||

B.2.1. Key Derivation Functions............................16 | ||||

B.2.2 Symmetric Key-Wrapping Schemes.......................18 | ||||

B.3 ASN.1 module..............................................19 | ||||

B.4 Examples..................................................24 | ||||

IANA Considerations..............................................25 | ||||

Acknowledgements.................................................25 | ||||

Authors' Addresses...............................................26 | ||||

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | 1. Introduction | |||

"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | ||||

document are to be interpreted as described in RFC 2119 [STDWORDS]. | ||||

1. Introduction | The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) | |||

mechanism for transporting keying data to a recipient using the | ||||

recipient's RSA public key. | ||||

The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) | Most previous key transport algorithms based on the RSA public-key | |||

mechanism for transporting keying data to a recipient using the | cryptosystem (e.g., the popular PKCS #1 v1.5 algorithm [PKCS1]) have | |||

recipient's RSA public key. | the following general form: | |||

Most previous key transport algorithms based on the RSA public-key | 1. Format or "pad" the keying data to obtain an integer m. | |||

cryptosystem (e.g., the popular PKCS #1 v1.5 algorithm [PKCS1]) have | ||||

the following general form: | ||||

1. Format or "pad" the keying data to obtain an integer m. | 2. Encrypt the integer m with the recipient's RSA public key: | |||

2. Encrypt the integer m with the recipient's RSA public key: | c = m^e mod n | |||

c = m^e mod n | 3. Output c as the encrypted keying data. | |||

3. Output c as the encrypted keying data. | The RSA-KEM Key Transport Algorithm takes a different approach that | |||

provides higher security assurance, by encrypting a _random_ integer | ||||

with the recipient's public key, and using a symmetric key-wrapping | ||||

scheme to encrypt the keying data. It has the following form: | ||||

The RSA-KEM Key Transport Algorithm takes a different approach that | 1. Generate a random integer z between 0 and n-1. | |||

provides higher security assurance, by encrypting a _random_ integer | ||||

with the recipient's public key, and using a symmetric key-wrapping | ||||

scheme to encrypt the keying data. It has the following form: | ||||

1. Generate a random integer z between 0 and n-1. | 2. Encrypt the integer z with the recipient's RSA public key: | |||

2. Encrypt the integer z with the recipient's RSA public key: | c = z^e mod n | |||

c = z^e mod n | 3. Derive a key-encrypting key KEK from the integer z. | |||

3. Derive a key-encrypting key KEK from the integer z. | 4. Wrap the keying data using KEK to obtain wrapped keying data WK. | |||

4. Wrap the keying data using KEK to obtain wrapped keying data WK. | 5. Output c and WK as the encrypted keying data. | |||

5. Output c and WK as the encrypted keying data. | This different approach provides higher security assurance because | |||

(a) the input to the underlying RSA operation is effectively a random | ||||

integer between 0 and n-1, 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 public-key operations are | ||||

separate from the symmetric operations on the keying data. One | ||||

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. | ||||

This different approach provides higher security assurance because | The RSA-KEM Key Transport Algorithm in various forms is being adopted | |||

(a) the input to the underlying RSA operation is effectively a random | in several draft standards as well as in ANS-X9.44 and ISO/IEC 18033- | |||

integer between 0 and n-1, where n is the RSA modulus, so it does not | 2. It has also been recommended by the NESSIE project [NESSIE]. | |||

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 public-key operations are | ||||

separate from the symmetric operations on the keying data. One | ||||

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. | ||||

The RSA-KEM Key Transport Algorithm in various forms is being adopted | For completeness, a specification of the algorithm is given in | |||

in several draft standards as well as in ANS-X9.44 and ISO/IEC 18033- | Appendix A of this document; ASN.1 syntax is given in Appendix B. | |||

2. It has also been recommended by the NESSIE project [NESSIE]. | ||||

For completeness, a specification of the algorithm is given in | NOTE: The term KEM stands for "key encapsulation mechanism" and | |||

Appendix A of this document; ASN.1 syntax is given in Appendix B. | refers to the first three steps of the process above. The | |||

formalization of key transport algorithms (or more generally, | ||||

asymmetric encryption schemes) in terms of key encapsulation | ||||

mechanisms is described further in research by Victor Shoup leading | ||||

to the development of the ISO/IEC 18033-2 standard [SHOUP]. | ||||

NOTE: The term KEM stands for "key encapsulation mechanism" and | 2. Use in CMS | |||

refers to the first three steps of the process above. The | ||||

formalization of key transport algorithms (or more generally, | ||||

asymmetric encryption schemes) in terms of key encapsulation | ||||

mechanisms is described further in research by Victor Shoup leading | ||||

to the development of the ISO/IEC 18033-2 standard [SHOUP]. | ||||

2. Use in CMS | The RSA-KEM Key Transport Algorithm MAY be employed for one or more | |||

recipients in the CMS enveloped-data content type (Section 6 of | ||||

[CMS]), where the keying data processed by the algorithm is the CMS | ||||

content-encryption key. | ||||

The RSA-KEM Key Transport Algorithm MAY be employed for one or more | The RSA-KEM Key Transport Algorithm SHOULD be considered for new CMS- | |||

recipients in the CMS enveloped-data content type (Section 6 of | based applications as a replacement for the widely implemented RSA | |||

[CMS]), where the keying data processed by the algorithm is the CMS | encryption algorithm specified originally in PKCS #1 v1.5 (see | |||

content-encryption key. | [PKCS1] and Section 4.2.1 of [CMSALGS]), which is vulnerable to | |||

chosen-ciphertext attacks. The RSAES-OAEP Key Transport Algorithm has | ||||

also been proposed as a replacement (see [PKCS1] and [CMS-OAEP]). | ||||

RSA-KEM has the advantage over RSAES-OAEP of a tighter security | ||||

proof, but the disadvantage of slightly longer encrypted keying data. | ||||

The RSA-KEM Key Transport Algorithm SHOULD be considered for new | 2.1. Underlying Components | |||

CMS-based applications as a replacement for the widely implemented | ||||

RSA encryption algorithm specified originally in PKCS #1 v1.5 (see | ||||

[PKCS1] and Section 4.2.1 of [CMSALGS]), which is vulnerable to | ||||

chosen-ciphertext attacks. The RSAES-OAEP Key Transport Algorithm has | ||||

also been proposed as a replacement (see [PKCS1] and [CMS-OAEP]). | ||||

RSA-KEM has the advantage over RSAES-OAEP of a tighter security | ||||

proof, but the disadvantage of slightly longer encrypted keying data. | ||||

2.1. Underlying Components | A CMS implementation that supports the RSA-KEM Key Transport | |||

Algorithm MUST support at least the following underlying components: | ||||

A CMS implementation that supports the RSA-KEM Key Transport | o For the key derivation function, KDF3 (see [IEEE-P1363a]) based on | |||

Algorithm MUST support at least the following underlying components: | SHA-256 (see [FIPS-180-2]). KDF3 is an instantiation of the | |||

Concatenation Key Derivation Function defined in [NIST-SP800-56A]. | ||||

o For the key derivation function, KDF3 (see [IEEE-P1363a]) based on | o For the key-wrapping scheme, AES-Wrap-128, i.e., the AES Key Wrap | |||

SHA-256 (see [FIPS-180-2]). KDF3 is an instantiation of the | with a 128-bit key encrypting key (see [AES-WRAP]) | |||

Concatenation Key Derivation Function defined in [SP800-56A]. | ||||

o For the key-wrapping scheme, AES-Wrap-128, i.e., the AES Key Wrap | An implementation SHOULD also support KDF2 (see [ANS-X9.44]) based on | |||

with a 128-bit key encrypting key (see [AES-WRAP]) | SHA-1 (this function is also specified as the key derivation function | |||

in [ANS-X9.63]). The Camellia key wrap algorithm (see [CAMELLIA]) | ||||

SHOULD be supported, and, if 3DES is supported as a content- | ||||

encryption cipher, then the Triple-DES Key Wrap (see [3DES-WRAP]) | ||||

SHOULD also be supported. | ||||

An implementation SHOULD also support KDF2 (see [ANS-X9.44]) based on | It MAY support other underlying components. When AES or Camellia are | |||

SHA-1 (this function is also specified as the key derivation function | used the data block size is 128 bits while the key size can be 128, | |||

in [ANS-X9.63]). The Camellia key wrap algorithm (see [CAMELLIA]) | 192, or 256 bits while Triple DES requires a data block size of 64 | |||

SHOULD be supported, and, if 3DES is supported as a content- | bits and a key size of 112 or 168 bits. | |||

encryption cipher, then the Triple-DES Key Wrap (see [3DES-WRAP]) | ||||

SHOULD also be supported. | ||||

It MAY support other underlying components. When AES or Camellia are | 2.2. RecipientInfo Conventions | |||

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 | ||||

bits and a key size of 112 or 168 bits. | ||||

2.2. RecipientInfo Conventions | When the RSA-KEM Key Transport Algorithm is employed for a recipient, | |||

the RecipientInfo alternative for that recipient MUST be | ||||

KeyTransRecipientInfo. The algorithm-specific fields of the | ||||

KeyTransRecipientInfo value MUST have the following values: | ||||

When the RSA-KEM Key Transport Algorithm is employed for a recipient, | o keyEncryptionAlgorithm.algorithm MUST be id-rsa-kem (see Appendix | |||

the RecipientInfo alternative for that recipient MUST be | B) | |||

KeyTransRecipientInfo. The algorithm-specific fields of the | ||||

KeyTransRecipientInfo value MUST have the following values: | ||||

o keyEncryptionAlgorithm.algorithm MUST be id-rsa-kem see Appendix | o keyEncryptionAlgorithm.parameters MUST be a value of type | |||

B) | GenericHybridParameters, identifying the RSA-KEM key encapsulation | |||

mechanism (see Appendix B) | ||||

o keyEncryptionAlgorithm.parameters MUST be a value of type | o encryptedKey MUST be the encrypted keying data output by the | |||

GenericHybridParameters, identifying the RSA-KEM key encapsulation | algorithm, where the keying data is the content-encryption key. (see | |||

mechanism (see Appendix B) | Appendix A) | |||

o encryptedKey MUST be the encrypted keying data output by the | 2.3. Certificate Conventions | |||

algorithm, where the keying data is the content-encryption | ||||

key.(see Appendix A) | ||||

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 | |||

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 RSA-KEM 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. | ||||

A recipient who employs the RSA-KEM Key Transport Algorithm MAY | If the recipient wishes only to employ the RSA-KEM Key Transport | |||

identify the public key in a certificate by the same | Algorithm with a given public key, the recipient MUST identify the | |||

AlgorithmIdentifier as for the PKCS #1 v1.5 algorithm, i.e., using | public key in the certificate using the id-rsa-kem object identifier | |||

the rsaEncryption object identifier [PKCS1]. The fact that the user | (see Appendix B). The parameters are absent. | |||

will accept RSA-KEM 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. | ||||

If the recipient wishes only to employ the RSA-KEM Key Transport | Regardless of the AlgorithmIdentifier used, the RSA public key is | |||

Algorithm with a given public key, the recipient MUST identify the | encoded in the same manner in the subject public key information. The | |||

public key in the certificate using the id-rsa-kem object identifier | RSA public key MUST be encoded using the type RSAPublicKey type: | |||

(see Appendix B). The parameters are absent. | ||||

Regardless of the AlgorithmIdentifier used, the RSA public key is | RSAPublicKey ::= SEQUENCE { | |||

encoded in the same manner in the subject public key information. The | modulus INTEGER, -- n | |||

RSA public key MUST be encoded using the type RSAPublicKey type: | publicExponent INTEGER -- e | |||

} | ||||

RSAPublicKey ::= SEQUENCE { | Here, the modulus is the modulus n, and publicExponent is the public | |||

modulus INTEGER, -- n | exponent e. The DER encoded RSAPublicKey is carried in the | |||

publicExponent INTEGER -- e | subjectPublicKey BIT STRING within the subject public key | |||

} | information. | |||

Here, the modulus is the modulus n, and publicExponent is the public | The intended application for the key MAY be indicated in the key | |||

exponent e. The DER encoded RSAPublicKey is carried in the | usage certificate extension (see [PROFILE], Section 4.2.1.3). If the | |||

subjectPublicKey BIT STRING within the subject public key | keyUsage extension is present in a certificate that conveys an RSA | |||

information. | public key with the id-rsa-kem object identifier as discussed above, | |||

then the key usage extension MUST contain the following value: | ||||

The intended application for the key MAY be indicated in the key | keyEncipherment. | |||

usage certificate extension (see [PROFILE], Section 4.2.1.3). If the | ||||

keyUsage extension is present in a certificate that conveys an RSA | ||||

public key with the id-rsa-kem object identifier as discussed above, | ||||

then the key usage extension MUST contain the following value: | ||||

keyEncipherment. | dataEncipherment SHOULD NOT be present. That is, a key intended to be | |||

employed only with the RSA-KEM Key Transport Algorithm SHOULD NOT | ||||

also be employed for data encryption or for authentication such as in | ||||

signatures. Good cryptographic practice employs a given RSA key pair | ||||

in only one scheme. This practice avoids the risk that vulnerability | ||||

in one scheme may compromise the security of the other, and may be | ||||

essential to maintain provable security. | ||||

dataEncipherment SHOULD NOT be present. That is, a key intended to be | 2.4. SMIMECapabilities Attribute Conventions | |||

employed only with the RSA-KEM Key Transport Algorithm SHOULD NOT | ||||

also be employed for data encryption or for authentication such as in | ||||

signatures. Good cryptographic practice employs a given RSA key pair | ||||

in only one scheme. This practice avoids the risk that vulnerability | ||||

in one scheme may compromise the security of the other, and may be | ||||

essential to maintain provable security. | ||||

2.4. SMIMECapabilities Attribute Conventions | RFC 3851 [MSG], Section 2.5.2 defines the SMIMECapabilities signed | |||

attribute (defined as a SEQUENCE of SMIMECapability SEQUENCEs) to be | ||||

used to specify a partial list of algorithms that the software | ||||

announcing the SMIMECapabilities can support. When constructing a | ||||

signedData object, compliant software MAY include the | ||||

SMIMECapabilities signed attribute announcing that it supports the | ||||

RSA-KEM Key Transport algorithm. | ||||

RFC 3851 [MSG], Section 2.5.2 defines the SMIMECapabilities signed | The SMIMECapability SEQUENCE representing the RSA-KEM Key Transport | |||

attribute (defined as a SEQUENCE of SMIMECapability SEQUENCEs) to be | Algorithm MUST include the id-rsa-kem object identifier (see Appendix | |||

used to specify a partial list of algorithms that the software | B) in the capabilityID field and MUST include a | |||

announcing the SMIMECapabilities can support. When constructing a | GenericHybridParameters value in the parameters field identifying the | |||

signedData object, compliant software MAY include the | components with which the algorithm is to be employed. | |||

SMIMECapabilities signed attribute announcing that it supports the | ||||

RSA-KEM Key Transport algorithm. | ||||

The SMIMECapability SEQUENCE representing the RSA-KEM Key Transport | The DER encoding of a SMIMECapability SEQUENCE is the same as the DER | |||

Algorithm MUST include the id-rsa-kem object identifier (see Appendix | encoding of an AlgorithmIdentifier. Example DER encodings for typical | |||

B) in the capabilityID field and MUST include a | sets of components are given in Appendix B.4. | |||

GenericHybridParameters value in the parameters field identifying the | ||||

components with which the algorithm is to be employed. | ||||

The DER encoding of a SMIMECapability SEQUENCE is the same as the DER | 3. Security Considerations | |||

encoding of an AlgorithmIdentifier. Example DER encodings for typical | ||||

sets of components are given in Appendix B.4. | ||||

3. Security Considerations | The security of the RSA-KEM Key Transport Algorithm described in this | |||

document can be shown to be tightly related to the difficulty of | ||||

either solving the RSA problem or breaking the underlying symmetric | ||||

key-wrapping scheme, if the underlying key derivation function is | ||||

modeled as a random oracle, and assuming that the symmetric key- | ||||

wrapping scheme satisfies the properties of a data encapsulation | ||||

mechanism [SHOUP]. While in practice a random-oracle result does not | ||||

provide an actual security proof for any particular key derivation | ||||

function, the result does provide assurance that the general | ||||

construction is reasonable; a key derivation function would need to | ||||

be particularly weak to lead to an attack that is not possible in the | ||||

random oracle model. | ||||

The security of the RSA-KEM Key Transport Algorithm described in this | The RSA key size and the underlying components should be selected | |||

document can be shown to be tightly related to the difficulty of | consistent with the desired symmetric security level for an | |||

either solving the RSA problem or breaking the underlying symmetric | application. Several security levels have been identified in NIST | |||

key-wrapping scheme, if the underlying key derivation function is | FIPS PUB 800-57 [NIST-GUIDELINE]. For brevity, the first threelevels | |||

modeled as a random oracle, and assuming that the symmetric key- | are mentioned here: | |||

wrapping scheme satisfies the properties of a data encapsulation | ||||

mechanism [SHOUP]. While in practice a random-oracle result does not | ||||

provide an actual security proof for any particular key derivation | ||||

function, the result does provide assurance that the general | ||||

construction is reasonable; a key derivation function would need to | ||||

be particularly weak to lead to an attack that is not possible in the | ||||

random oracle model. | ||||

The RSA key size and the underlying components should be selected | o 80-bit security. The RSA key size SHOULD be at least 1024 bits, | |||

consistent with the desired symmetric security level for an | the hash function underlying the KDF SHOULD be SHA-1 or above, and | |||

application. Several security levels have been identified in [NIST- | the symmetric key-wrapping scheme SHOULD be AES Key Wrap, Triple-DES | |||

FIPS PUB 800-57]. For brevity, the first three levels are mentioned | Key Wrap, or Camellia Key Wrap. | |||

here: | ||||

o 80-bit security. The RSA key size SHOULD be at least 1024 bits, | o 112-bit security. The RSA key size SHOULD be at least 2048 bits, | |||

the hash function underlying the KDF SHOULD be SHA-1 or above, and | the hash function underlying the KDF SHOULD be SHA-224 or above, and | |||

the symmetric key-wrapping scheme SHOULD be AES Key Wrap, Triple- | the symmetric key-wrapping scheme SHOULD be AES Key Wrap, Triple-DES | |||

DES Key Wrap, or Camellia Key Wrap. | Key Wrap, or Camellia Key Wrap. | |||

o 112-bit security. The RSA key size SHOULD be at least 2048 bits, | o 128-bit security. The RSA key size SHOULD be at least 3072 bits, | |||

the hash function underlying the KDF SHOULD be SHA-224 or above, | the hash function underlying the KDF SHOULD be SHA-256 or above, and | |||

and the symmetric key-wrapping scheme SHOULD be AES Key Wrap, | the symmetric key-wrapping scheme SHOULD be AES Key Wrap or Camellia | |||

Triple-DES Key Wrap, or Camellia Key Wrap. | Key Wrap. | |||

o 128-bit security. The RSA key size SHOULD be at least 3072 bits, | Note that the AES Key Wrap or Camellia Key Wrap MAY be used at all | |||

the hash function underlying the KDF SHOULD be SHA-256 or above, | three of these levels; the use of AES or Camellia does not require a | |||

and the symmetric key-wrapping scheme SHOULD be AES Key Wrap or | 128-bit security level for other components. | |||

Camellia Key Wrap. | ||||

Note that the AES Key Wrap or Camellia Key Wrap MAY be used at all | Implementations MUST protect the RSA private key and the content- | |||

three of these levels; the use of AES or Camellia does not require a | encryption key. Compromise of the RSA private key may result in the | |||

128-bit security level for other components. | disclosure of all messages protected with that key. Compromise of the | |||

content-encryption key may result in disclosure of the associated | ||||

encrypted content. | ||||

Implementations MUST protect the RSA private key and the content- | Additional considerations related to key management may be found in | |||

encryption key. Compromise of the RSA private key may result in the | [NIST-GUIDELINE]. | |||

disclosure of all messages protected with that key. Compromise of the | ||||

content-encryption key may result in disclosure of the associated | ||||

encrypted content. | ||||

Additional considerations related to key management may be found in | The security of the algorithm also depends on the strength of the | |||

[NIST-GUIDELINE]. | random number generator, which SHOULD have a comparable security | |||

level. For further discussion on random number generation, please see | ||||

[RANDOM]. | ||||

The security of the algorithm also depends on the strength of the | Implementations SHOULD NOT reveal information about intermediate | |||

random number generator, which SHOULD have a comparable security | values or calculations, whether by timing or other "side channels", | |||

level. For further discussion on random number generation, please see | or otherwise an opponent may be able to determine information about | |||

[RANDOM]. | the keying data and/or the recipient's private key. Although not all | |||

intermediate information may be useful to an opponent, it is | ||||

preferable to conceal as much information as is practical, unless | ||||

analysis specifically indicates that the information would not be | ||||

useful. | ||||

Implementations SHOULD NOT reveal information about intermediate | Generally, good cryptographic practice employs a given RSA key pair | |||

values or calculations, whether by timing or other "side channels", | in only one scheme. This practice avoids the risk that vulnerability | |||

or otherwise an opponent may be able to determine information about | in one scheme may compromise the security of the other, and may be | |||

the keying data and/or the recipient's private key. Although not all | essential to maintain provable security. While RSA public keys have | |||

intermediate information may be useful to an opponent, it is | often been employed for multiple purposes such as key transport and | |||

preferable to conceal as much information as is practical, unless | digital signature without any known bad interactions, for increased | |||

analysis specifically indicates that the information would not be | security assurance, such combined use of an RSA key pair is NOT | |||

useful. | RECOMMENDED in the future (unless the different schemes are | |||

specifically designed to be used together). | ||||

Generally, good cryptographic practice employs a given RSA key pair | Accordingly, an RSA key pair used for the RSA-KEM Key Transport | |||

in only one scheme. This practice avoids the risk that vulnerability | Algorithm SHOULD NOT also be used for digital signatures. (Indeed, | |||

in one scheme may compromise the security of the other, and may be | ASC X9 requires such a separation between key establishment key pairs | |||

essential to maintain provable security. While RSA public keys have | and digital signature key pairs.) Continuing this principle of key | |||

often been employed for multiple purposes such as key transport and | separation, a key pair used for the RSA-KEM Key Transport Algorithm | |||

digital signature without any known bad interactions, for increased | SHOULD NOT be used with other key establishment schemes, or for data | |||

security assurance, such combined use of an RSA key pair is NOT | encryption, or with more than one set of underlying algorithm | |||

RECOMMENDED in the future (unless the different schemes are | components. | |||

specifically designed to be used together). | ||||

Accordingly, an RSA key pair used for the RSA-KEM Key Transport | Parties MAY formalize the assurance that one another's | |||

Algorithm SHOULD NOT also be used for digital signatures. (Indeed, | implementations are correct through implementation validation, e.g. | |||

ASC X9 requires such a separation between key establishment key pairs | NIST's Cryptographic Module Validation Program (CMVP). | |||

and digital signature key pairs.) Continuing this principle of key | ||||

separation, a key pair used for the RSA-KEM 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 | 4. References | |||

implementations are correct through implementation validation, e.g. | ||||

NIST's Cryptographic Module Validation Program (CMVP). | ||||

4. References | 4.1. Normative References | |||

4.1. Normative References | [3DES-WRAP] Housley, R. Triple-DES and RC2 Key Wrapping. RFC | |||

3217. December 2001. | ||||

[3DES-WRAP] Housley, R. Triple-DES and RC2 Key Wrapping. RFC | [AES-WRAP] Schaad, J. and R. Housley. Advanced Encryption | |||

3217. December 2001. | Standard (AES) Key Wrap Algorithm. RFC 3394. | |||

September 2002. | ||||

[AES-WRAP] Schaad, J. and R. Housley. Advanced Encryption | [ANS-X9.63] American National Standard X9.63-2002: Public Key | |||

Standard (AES) Key Wrap Algorithm. RFC 3394. | Cryptography for the Financial Services Industry: | |||

September 2002. | Key Agreement and Key Transport Using Elliptic | |||

Curve Cryptography. | ||||

[ANS-X9.63] American National Standard X9.63-2002: Public Key | [CAMELLIA] Kato, A., Moriai, S., and Kanda, M.: Use of the | |||

Cryptography for the Financial Services Industry: | Camellia Encryption Algorithm in Cryptographic | |||

Key Agreement and Key Transport Using Elliptic | Message Syntax. RFC 3657. December 2005. | |||

Curve Cryptography. | ||||

[CAMELLIA] Kato, A., Moriai, S., and Kanda, M.: Use of the | [CMS] Housley, R. Cryptographic Message Syntax. RFC | |||

Camellia Encryption Algorithm in Cryptographic | 5652. September 20009. | |||

Message Syntax. RFC 3657. December 2005. | ||||

[CMS] Housley, R. Cryptographic Message Syntax. RFC | [CMSALGS] Housley, R. Cryptographic Message Syntax (CMS) | |||

3852. July 2004. | Algorithms. RFC 3370. August 2002. | |||

[CMSALGS] Housley, R. Cryptographic Message Syntax (CMS) | [FIPS-180-2] National Institute of Standards and Technology | |||

Algorithms. RFC 3370. August 2002. | (NIST). FIPS 180-2: Secure Hash Standard. August | |||

2002. | ||||

[FIPS-180-2] National Institute of Standards and Technology | [MSG] Ramsdell, B. S/MIME Version 3 Message | |||

(NIST). FIPS 180-2: Secure Hash Standard. August | Specification. RFC 3851. July 2004. | |||

2002. | ||||

[MSG] Ramsdell, B. S/MIME Version 3 Message | [PROFILE] Cooper, D., Santesson, S., Farrell, S., Boeyen, | |||

Specification. RFC 3851. July 2004. | S., Housley, R., and W. Polk. Internet X.509 | |||

Public Key Infrastructure Certificate and | ||||

Certificate Revocation List (CRL) Profile. RFC | ||||

5280. May 2008. | ||||

[PROFILE] Cooper, D., Santesson, S., Farrell, S., | [STDWORDS] Bradner, S. Key Words for Use in RFCs to Indicate | |||

Boeyen, S., Housley, R., and W. Polk. Internet | Requirement Levels. RFC 2119. March 1997. | |||

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 | 4.2. Informative References | |||

Requirement Levels. RFC 2119. March 1997. | ||||

4.2. Informative References | [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.44] ASC X9F1 Working Group. American National | [CMS-OAEP] Housley, R. Use of the RSAES-OAEP Key Transport | |||

Standard X9.44: Public Key Cryptography for the | Algorithm in the Cryptographic Message Syntax | |||

Financial Services Industry -- Key Establishment | (CMS). RFC 3560. July 2003. | |||

Using Integer Factorization Cryptography. 2007 | ||||

[CMS-OAEP] Housley, R. Use of the RSAES-OAEP Key Transport | [IEEE-P1363a] IEEE Std 1363a-2004: Standard Specifications for | |||

Algorithm in the Cryptographic Message Syntax | Public Key Cryptography: Additional Techniques. | |||

(CMS). RFC 3560. July 2003. | IEEE, 2004. | |||

[IEEE-P1363a] IEEE Std 1363a-2004: Standard Specifications for | [ISO-IEC-18033-2] ISO/IEC 18033-2:2005 Information technology -- | |||

Public Key Cryptography: Additional Techniques. | Security techniques -- Encryption algorithms -- | |||

IEEE, 2004. | Part 2: Asymmetric Ciphers. ISO/IEC, 2005. | |||

[ISO-IEC-18033-2] ISO/IEC 18033-2:2005 Information technology -- | [NESSIE] NESSIE Consortium. Portfolio of Recommended | |||

Security techniques -- Encryption algorithms -- | Cryptographic Primitives. February 27, 2003. | |||

Part 2: Asymmetric Ciphers. ISO/IEC, 2005. | Available via http://www.cryptonessie.org/. | |||

[NESSIE] NESSIE Consortium. Portfolio of Recommended | [NIST-GUIDELINE] National Institute of Standards and Technology. | |||

Cryptographic Primitives. February 27, 2003. | Special Publication 800-57: Recommendation for | |||

Available via http://www.cryptonessie.org/. | Pairwise Key Establishment Schemes Using Discrete | |||

Logarithm Cryptography March 2007. Available via: | ||||

http://csrc.nist.gov/publications/index.html. | ||||

[NIST-GUIDELINE] National Institute of Standards and Technology. | [NIST-SP800-56A] National Institute of Standards and Technology. | |||

Special Publication 800-57: Recommendation for | Special Publication 800-56A: Recommendation for | |||

Pairwise Key Establishment Schemes Using Discrete | Key Management. Part 1: General Guideline. August | |||

Logarithm Cryptography March 2007. Available via: | 2005. Available via: | |||

http://csrc.nist.gov/publications/index.html. | http://csrc.nist.gov/publications/index.html. | |||

[NIST-SP800-56A] National Institute of Standards and Technology. | [PKCS1] Jonsson, J. and B. Kaliski. PKCS #1: RSA | |||

Special Publication 800-56A: Recommendation for | Cryptography Specifications Version 2.1. RFC 3447. | |||

Key Management. Part 1: General Guideline. | February 2003. | |||

August 2005. Available via: | ||||

http://csrc.nist.gov/publications/index.html. | ||||

[PKCS1] Jonsson, J. and B. Kaliski. PKCS #1: RSA | [RANDOM] Eastlake, D., S. Crocker, and J. Schiller. | |||

Cryptography Specifications Version 2.1. RFC | Randomness Recommendations for Security. RFC 4086. | |||

3447. February 2003. | June 2005. | |||

[RANDOM] Eastlake, D., S. Crocker, and J. Schiller. | [SHOUP] Shoup, V. A Proposal for an ISO Standard for | |||

Randomness Recommendations for Security. RFC | Public Key Encryption. Version 2.1, December 20, | |||

4086. June 2005. | 2001. Available via http://www.shoup.net/papers/. | |||

[SHOUP] Shoup, V. A Proposal for an ISO Standard for | Appendix A. RSA-KEM Key Transport Algorithm | |||

Public Key Encryption. Version 2.1, December 20, | ||||

2001. Available via http://www.shoup.net/papers/. | ||||

Appendix A. | The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) | |||

RSA-KEM Key Transport Algorithm | mechanism for transporting keying data to a recipient using the | |||

recipient's RSA public key. | ||||

The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) | With this type of algorithm, a sender encrypts the keying data using | |||

mechanism for transporting keying data to a recipient using the | the recipient's public key to obtain encrypted keying data. The | |||

recipient's RSA public key. | recipient decrypts the encrypted keying data using the recipient's | |||

private key to recover the keying data. | ||||

With this type of algorithm, a sender encrypts the keying data using | A.1. Underlying Components | |||

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: | |||

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 | ||||

o KDF, a key derivation function, which derives keying data of a | o Wrap, a symmetric key-wrapping scheme, which encrypts keying Data | |||

specified length from a shared secret value | using a key-encrypting key | |||

o Wrap, a symmetric key-wrapping scheme, which encrypts keying Data | In the following, kekLen denotes the length in bytes of the key- | |||

using a key-encrypting key | encrypting key for the underlying symmetric key-wrapping scheme. | |||

In the following, kekLen denotes the length in bytes of the key- | In this scheme, the length of the keying data to be transported MUST | |||

encrypting key for the underlying symmetric key-wrapping scheme. | 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 Triple-DES keys) is outside the scope of | ||||

this algorithm. With some key derivation functions, it is possible to | ||||

include other information besides the shared secret value in the | ||||

input to the function. Also, with some symmetric key-wrapping | ||||

schemes, it is possible to associate a label with the keying data. | ||||

Such uses are outside the scope of this document, as they are not | ||||

directly supported by CMS. | ||||

In this scheme, the length of the keying data to be transported MUST | A.2. Sender's Operation | |||

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 Triple-DES keys) is outside the scope of | ||||

this algorithm. With some key derivation functions, it is possible to | ||||

include other information besides the shared secret value in the | ||||

input to the function. Also, with some symmetric key-wrapping | ||||

schemes, it is possible to associate a label with the keying data. | ||||

Such uses are outside the scope of this document, as they are not | ||||

directly supported by CMS. | ||||

A.2. Sender's Operations | Let (n,e) be the recipient's RSA public key (see [PKCS1] for details) | |||

and let K be the keying data to be transported. | ||||

Let (n,e) be the recipient's RSA public key (see [PKCS1] for | Let nLen denote the length in bytes of the modulus n, i.e., the least | |||

details) and let K be the keying data to be transported. | integer such that 2^{8*nLen} > n. | |||

Let nLen denote the length in bytes of the modulus n, i.e., the least | The sender performs the following operations: | |||

integer such that 2^{8*nLen} > n. | ||||

The sender performs the following operations: | 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 | ||||

first: | ||||

1. Generate a random integer z between 0 and n-1 (see Note), and | z = RandomInteger (0, n-1) | |||

convert z to a byte string Z of length nLen, most significant byte | ||||

first: | ||||

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 n,e) | |||

and convert the resulting integer c to a ciphertext C, a byte | and convert the resulting integer c to a ciphertext C, a byte string | |||

string of length nLen: | of length nLen: | |||

c = z^e mod n | c = z^e mod n | |||

C = IntegerToString (c, nLen) | ||||

3. Derive a key-encrypting key KEK of length kekLen bytes from the | C = IntegerToString (c, nLen) | |||

byte string Z using the underlying key derivation function: | ||||

KEK = KDF (Z, kekLen) | 3. Derive a key-encrypting key KEK of length kekLen bytes from the | |||

byte string Z using the underlying key derivation function: | ||||

4. Wrap the keying data K with the key-encrypting key KEK using the | KEK = KDF (Z, kekLen) | |||

underlying key-wrapping scheme to obtain wrapped keying data WK: | ||||

WK = Wrap (KEK, K) | 4. Wrap the keying data K with the key-encrypting key KEK using the | |||

underlying key-wrapping scheme to obtain wrapped keying data WK: | ||||

5. Concatenate the ciphertext C and the wrapped keying data WK to | WK = Wrap (KEK, K) | |||

obtain the encrypted keying data EK: | ||||

EK = C || WK | 5. Concatenate the ciphertext C and the wrapped keying data WK to | |||

obtain the encrypted keying data EK: | ||||

6. Output the encrypted keying data EK. | EK = C || WK | |||

NOTE: The random integer z MUST be generated independently at random | 6. Output the encrypted keying data EK. | |||

for different encryption operations, whether for the same or | ||||

different recipients. | ||||

A.3. Recipient's Operations | NOTE: The random integer z MUST be generated independently at random | |||

for different encryption operations, whether for the same or | ||||

different recipients. | ||||

Let (n,d) be the recipient's RSA private key (see [PKCS1]; other | A.3. Recipient's Operations | |||

private key formats are allowed) and let EK be the encrypted keying | ||||

data. | ||||

Let nLen denote the length in bytes of the modulus n. | Let (n,d) be the recipient's RSA private key (see [PKCS1]; other | |||

private key formats are allowed) and let EK be the encrypted keying | ||||

data. | ||||

The recipient performs the following operations: | Let nLen denote the length in bytes of the modulus n. | |||

1. Separate the encrypted keying data EK into a ciphertext C of | The recipient performs the following operations: | |||

length nLen bytes and wrapped keying data WK: | ||||

C || WK = EK | 1. Separate the encrypted keying data EK into a ciphertext C of | |||

length nLen bytes and wrapped keying data WK: | ||||

If the length of the encrypted keying data is less than nLen | C || WK = EK | |||

bytes, output "decryption error" and stop. | ||||

2. Convert the ciphertext C to an integer c, most significant byte | If the length of the encrypted keying data is less than nLen | |||

first. Decrypt the integer c using the recipient's private key | bytes, output "decryption error" and stop. | |||

(n,d) to recover an integer z (see Note): | ||||

c = StringToInteger (C) | 2. Convert the ciphertext C to an integer c, most significant byte | |||

z = c^d mod n | first. Decrypt the integer c using the recipient's private key | |||

(n,d) to recover an integer z (see Note): | ||||

If the integer c is not between 0 and n-1, output "decryption | c = StringToInteger (C) | |||

error" and stop. | ||||

3. Convert the integer z to a byte string Z of length nLen, most | z = c^d mod n | |||

significant byte first (see Note): | ||||

Z = IntegerToString (z, nLen) | If the integer c is not between 0 and n-1, output "decryption | |||

error" and stop. | ||||

4. Derive a key-encrypting key KEK of length kekLen bytes from | 3. Convert the integer z to a byte string Z of length nLen, most | |||

the byte string Z using the underlying key derivation function | significant byte first (see Note): | |||

(see Note): | ||||

KEK = KDF (Z, kekLen) | Z = IntegerToString (z, nLen) | |||

5. Unwrap the wrapped keying data WK with the key-encrypting key | 4. Derive a key-encrypting key KEK of length kekLen bytes from the | |||

KEK using the underlying key-wrapping scheme to recover the | byte string Z using the underlying key derivation function (see | |||

keying data K: | Note): | |||

K = Unwrap (KEK, WK) | KEK = KDF (Z, kekLen) | |||

If the unwrapping operation outputs an error, output "decryption | 5. Unwrap the wrapped keying data WK with the key-encrypting key KEK | |||

error" and stop. | using the underlying key-wrapping scheme to recover the keying | |||

data K: | ||||

6. Output the keying data K. | K = Unwrap (KEK, WK) | |||

NOTE: Implementations SHOULD NOT reveal information about the integer | If the unwrapping operation outputs an error, output "decryption | |||

z and the string Z, nor about the calculation of the exponentiation | error" and stop. | |||

in Step 2, the conversion in Step 3, or the key derivation in Step 4, | ||||

whether by timing or other "side channels". The observable behavior | ||||

of the implementation SHOULD be the same at these steps for all | ||||

ciphertexts C that are in range. (For example, IntegerToString | ||||

conversion should take the same amount of time regardless of the | ||||

actual value of the integer z.) The integer z, the string Z and other | ||||

intermediate results MUST be securely deleted when they are no longer | ||||

needed. | ||||

Appendix B. | 6. Output the keying data K. | |||

ASN.1 Syntax | ||||

The ASN.1 syntax for identifying the RSA-KEM Key Transport Algorithm | NOTE: Implementations SHOULD NOT reveal information about the integer | |||

is an extension of the syntax for the "generic hybrid cipher" in | z and the string Z, nor about the calculation of the exponentiation | |||

ISO/IEC 18033-2 [ISO-IEC-18033-2], and is the same as employed in ANS | in Step 2, the conversion in Step 3, or the key derivation in Step 4, | |||

X9.44 [ANS-X9.44]. The syntax for the scheme is given in Section B.1. | whether by timing or other "side channels". The observable behavior | |||

The syntax for selected underlying components including those | of the implementation SHOULD be the same at these steps for all | |||

mentioned above is given in B.2. | ciphertexts C that are in range. (For example, IntegerToString | |||

conversion should take the same amount of time regardless of the | ||||

actual value of the integer z.) The integer z, the string Z and other | ||||

intermediate results MUST be securely deleted when they are no longer | ||||

needed. | ||||

The following object identifier prefixes are used in the definitions | Appendix B. ASN.1 Syntax | |||

below: | ||||

is18033-2 OID ::= { iso(1) standard(0) is18033(18033) part2(2) } | The ASN.1 syntax for identifying the RSA-KEM Key Transport Algorithm | |||

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 ANS | ||||

X9.44 [ANS-X9.44]. The syntax for the scheme is given in Section B.1. | ||||

The syntax for selected underlying components including those | ||||

mentioned above is given in B.2. | ||||

nistAlgorithm OID ::= { | The following object identifier prefixes are used in the definitions | |||

joint-iso-itu-t(2) country(16) us(840) organization(1) | below: | |||

gov(101) csor(3) nistAlgorithm(4) | ||||

} | ||||

pkcs-1 OID ::= { | is18033-2 OID ::= { iso(1) standard(0) is18033(18033) part2(2) } | |||

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 | nistAlgorithm OID ::= { | |||

identifier has null parameters: | joint-iso-itu-t(2) country(16) us(840) organization(1) | |||

gov(101) csor(3) nistAlgorithm(4) | ||||

} | ||||

NullParms ::= NULL | pkcs-1 OID ::= { | |||

iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) | ||||

} | ||||

The material in this Appendix is based on ANS X9.44. | NullParms is a more descriptive synonym for NULL when an algorithm | |||

identifier has null parameters: | ||||

B.1 RSA-KEM Key Transport Algorithm | NullParms ::= NULL | |||

The object identifier for the RSA-KEM Key Transport Algorithm is id- | The material in this Appendix is based on ANS X9.44. | |||

rsa-kem, which is defined in the draft as: | ||||

id-rsa-kem OID ::= { | B.1. RSA-KEM Key Transport Algorithm | |||

iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) | ||||

pkcs-9(9) smime(16) alg(3) TBA | ||||

} | ||||

When id-rsa-kem is used in an AlgorithmIdentifier, the parameters | The object identifier for the RSA-KEM Key Transport Algorithm is id- | |||

MUST employ the GenericHybridParameters syntax. The parameters MUST | rsa-kem, which is defined in the draft as: | |||

be absent when used in the subjectPublicKeyInfo field The syntax for | ||||

GenericHybridParameters is as follows: | ||||

GenericHybridParameters ::= { | id-rsa-kem OID ::= { | |||

kem KeyEncapsulationMechanism, | iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) | |||

dem DataEncapsulationMechanism | pkcs-9(9) smime(16) alg(3) TBA | |||

} | } | |||

The fields of type GenericHybridParameters have the following | When id-rsa-kem is used in an AlgorithmIdentifier, the parameters | |||

meanings: | MUST employ the GenericHybridParameters syntax. The parameters MUST | |||

be absent when used in the subjectPublicKeyInfo field The syntax for | ||||

GenericHybridParameters is as follows: | ||||

o kem identifies the underlying key encapsulation mechanism. For the | GenericHybridParameters ::= { | |||

RSA-KEM Key Transport Algorithm, the scheme is RSA-KEM from | kem KeyEncapsulationMechanism, | |||

ISO/IEC 18033-2. | dem DataEncapsulationMechanism | |||

} | ||||

The object identifier for RSA-KEM (as a key encapsulation | The fields of type GenericHybridParameters have the following | |||

mechanism) is id-kem-rsa, which is defined in ISO/IEC 18033-2 as | meanings: | |||

id-kem-rsa OID ::= { | o kem identifies the underlying key encapsulation mechanism. For the | |||

is18033-2 key-encapsulation-mechanism(2) rsa(4) | RSA-KEM Key Transport Algorithm, the scheme is RSA-KEM from | |||

} | ISO/IEC 18033-2. | |||

The associated parameters for id-kem-rsa have type | The object identifier for RSA-KEM (as a key encapsulation | |||

RsaKemParameters: | mechanism) is id-kem-rsa, which is defined in ISO/IEC 18033-2 as: | |||

RsaKemParameters ::= { | id-kem-rsa OID ::= { | |||

keyDerivationFunction KeyDerivationFunction, | is18033-2 key-encapsulation-mechanism(2) rsa(4) | |||

keyLength KeyLength | } | |||

} | ||||

The fields of type RsaKemParameters have the following meanings: | The associated parameters for id-kem-rsa have type | |||

RsaKemParameters: | ||||

* keyDerivationFunction identifies the underlying key | RsaKemParameters ::= { | |||

derivation function. For alignment with ANS X9.44, it | keyDerivationFunction KeyDerivationFunction, | |||

MUST be KDF2 or KDF3. However, other key derivation | keyLength KeyLength | |||

functions MAY be used with CMS. Please see B.2.1 for | } | |||

the syntax for KDF2 and KDF3. | ||||

KeyDerivationFunction ::= | The fields of type RsaKemParameters have the following meanings: | |||

AlgorithmIdentifier {{KDFAlgorithms}} | ||||

KDFAlgorithms ALGORITHM ::= { | * keyDerivationFunction identifies the underlying key derivation | |||

kdf2 | kdf3, | function. For alignment with ANS X9.44, it MUST be KDF2 or KDF3. | |||

... -- implementations may define other methods | However, other key derivation functions MAY be used with CMS. | |||

} | Please see B.2.1 for the syntax for KDF2 and KDF3. | |||

* keyLength is the length in bytes of the key-encrypting | KeyDerivationFunction ::= AlgorithmIdentifier {{KDFAlgorithms}} | |||

key, which depends on the underlying symmetric key- | ||||

wrapping scheme. | ||||

KeyLength ::= INTEGER (1..MAX) | KDFAlgorithms ALGORITHM ::= { | |||

kdf2 | kdf3, | ||||

... -- implementations may define other methods | ||||

} | ||||

o dem identifies the underlying data encapsulation mechanism. For | * keyLength is the length in bytes of the key-encrypting key, | |||

alignment with ANS X9.44, it MUST be an X9-approved symmetric key- | which depends on the underlying symmetric key-wrapping scheme. | |||

wrapping scheme. (See Note.) However, other symmetric key-wrapping | ||||

schemes MAY be used with CMS. Please see B.2.2 for the syntax for | ||||

the AES, Triple-DES, and Camellia Key Wraps. | ||||

DataEncapsulationMechanism ::= | KeyLength ::= INTEGER (1..MAX) | |||

AlgorithmIdentifier {{DEMAlgorithms}} | ||||

DEMAlgorithms ALGORITHM ::= { | o dem identifies the underlying data encapsulation mechanism. For | |||

X9-SymmetricKeyWrappingSchemes, | alignment with ANS X9.44, it MUST be an X9-approved symmetric | |||

Camellia-KeyWrappingSchemes, | key-wrapping scheme. (See Note.) However, other symmetric key- | |||

... -- implementations may define other methods | wrapping schemes MAY be used with CMS. Please see B.2.2 for the | |||

} | syntax for the AES, Triple-DES, and Camellia Key Wraps. | |||

X9-SymmetricKeyWrappingSchemes ALGORITHM ::= { | DataEncapsulationMechanism ::= | |||

aes128-Wrap | aes192-Wrap | aes256-Wrap | tdes-Wrap, | AlgorithmIdentifier {{DEMAlgorithms}} | |||

... -- allows for future expansion | ||||

} | ||||

Camellia-KeyWrappingSchemes ALGORITHM ::= { | DEMAlgorithms ALGORITHM ::= { | |||

Camellia128-Wrap | Camellia192-Wrap | Camellia256-Wrap | X9-SymmetricKeyWrappingSchemes, | |||

} | Camellia-KeyWrappingSchemes, | |||

... -- implementations may define other methods | ||||

} | ||||

NOTE: The generic hybrid cipher in ISO/IEC 18033-2 can encrypt | X9-SymmetricKeyWrappingSchemes ALGORITHM ::= { | |||

arbitrary data, hence the term "data encapsulation mechanism". The | aes128-Wrap | aes192-Wrap | aes256-Wrap | tdes-Wrap, | |||

symmetric key-wrapping schemes take the role of data encapsulation | ... -- allows for future expansion | |||

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 | Camellia-KeyWrappingSchemes ALGORITHM ::= { | |||

Camellia128-Wrap | Camellia192-Wrap | Camellia256-Wrap | ||||

} | ||||

B.2.1 Key Derivation Functions | NOTE: The generic hybrid cipher in ISO/IEC 18033-2 can encrypt | |||

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. | ||||

The object identifier for KDF2 (see [ANS X9.44]) is: | B.2 Selected Underlying Components | |||

id-kdf-kdf2 OID ::= { x9-44-components kdf2(1) } | B.2.1. Key Derivation Functions | |||

The associated parameters identify the underlying hash function. For | The object identifier for KDF2 (see [ANS X9.44]) is: | |||

alignment with ANS X9.44, the hash function MUST be an ASC X9- | ||||

approved hash function. However, other hash functions MAY be used | ||||

with CMS. | ||||

kdf2 ALGORITHM ::= { OID id-kdf-kdf2 PARMS KDF2-HashFunction } | id-kdf-kdf2 OID ::= { x9-44-components kdf2(1) } | |||

KDF2-HashFunction ::= AlgorithmIdentifier {{KDF2- | ||||

HashFunctions}} | ||||

KDF2-HashFunctions ALGORITHM ::= { | The associated parameters identify the underlying hash function. For | |||

X9-HashFunctions, | alignment with ANS X9.44, the hash function MUST be an ASC X9- | |||

... -- implementations may define other methods | approved hash function. However, other hash functions MAY be used | |||

} | with CMS. | |||

X9-HashFunctions ALGORITHM ::= { | kdf2 ALGORITHM ::= { OID id-kdf-kdf2 PARMS KDF2-HashFunction } | |||

sha1 | sha224 | sha256 | sha384 | sha512, | ||||

... -- allows for future expansion | ||||

} | ||||

The object identifier for SHA-1 is | KDF2-HashFunction ::= AlgorithmIdentifier {{KDF2-HashFunctions}} | |||

id-sha1 OID ::= { | KDF2-HashFunctions ALGORITHM ::= { | |||

iso(1) identified-organization(3) oiw(14) secsig(3) | X9-HashFunctions, | |||

algorithms(2) sha1(26) | ... -- implementations may define other methods | |||

} | } | |||

The object identifiers for SHA-224, SHA-256, SHA-384 and SHA-512 are | X9-HashFunctions ALGORITHM ::= { | |||

sha1 | sha224 | sha256 | sha384 | sha512, | ||||

... -- allows for future expansion | ||||

} | ||||

id-sha224 OID ::= { nistAlgorithm hashAlgs(2) sha224(4) } | The object identifier for SHA-1 is: | |||

id-sha256 OID ::= { nistAlgorithm hashAlgs(2) sha256(1) } | ||||

id-sha384 OID ::= { nistAlgorithm hashAlgs(2) sha384(2) } | ||||

id-sha512 OID ::= { nistAlgorithm hashAlgs(2) sha512(3) } | ||||

There has been some confusion over whether the various SHA object | id-sha1 OID ::= { | |||

identifiers have a NULL parameter, or no associated parameters. As | iso(1) identified-organization(3) oiw(14) secsig(3) | |||

also discussed in [PKCS1], implementations SHOULD generate algorithm | algorithms(2) sha1(26) | |||

identifiers without parameters, and MUST accept algorithm identifiers | } | |||

either without parameters, or with NULL parameters. | ||||

sha1 ALGORITHM ::= { OID id-sha1 } -- NULLParms MUST be | The object identifiers for SHA-224, SHA-256, SHA-384 and SHA-512 are | |||

sha224 ALGORITHM ::= { OID id-sha224 } -- accepted for these | ||||

sha256 ALGORITHM ::= { OID id-sha256 } -- OIDs | ||||

sha384 ALGORITHM ::= { OID id-sha384 } -- "" | ||||

sha512 ALGORITHM ::= { OID id-sha512 } -- "" | ||||

The object identifier for KDF3 (see [ANS X9.44]) is: | id-sha224 OID ::= { nistAlgorithm hashAlgs(2) sha224(4) } | |||

id-sha256 OID ::= { nistAlgorithm hashAlgs(2) sha256(1) } | ||||

id-sha384 OID ::= { nistAlgorithm hashAlgs(2) sha384(2) } | ||||

id-sha512 OID ::= { nistAlgorithm hashAlgs(2) sha512(3) } | ||||

id-kdf-kdf3 OID ::= { x9-44-components kdf3(2) } | There has been some confusion over whether the various SHA object | |||

identifiers have a NULL parameter, or no associated parameters. As | ||||

also discussed in [PKCS1], implementations SHOULD generate algorithm | ||||

identifiers without parameters, and MUST accept algorithm identifiers | ||||

either without parameters, or with NULL parameters. | ||||

The associated parameters identify the underlying hash function. For | sha1 ALGORITHM ::= { OID id-sha1 } -- NULLParms MUST be | |||

alignment with the draft ANS X9.44, the hash function MUST be an ASC | sha224 ALGORITHM ::= { OID id-sha224 } -- accepted for these | |||

X9-approved hash function. (See Note.) However, other hash functions | sha256 ALGORITHM ::= { OID id-sha256 } -- OIDs | |||

MAY be used with CMS. | sha384 ALGORITHM ::= { OID id-sha384 } -- "" | |||

sha512 ALGORITHM ::= { OID id-sha512 } -- "" | ||||

kdf3 ALGORITHM ::= { OID id-kdf-kdf3 PARMS KDF3-HashFunction } | The object identifier for KDF3 (see [ANS X9.44]) is: | |||

KDF3-HashFunction ::= AlgorithmIdentifier { KDF3-HashFunctions } | id-kdf-kdf3 OID ::= { x9-44-components kdf3(2) } | |||

KDF3-HashFunctions ALGORITHM ::= { | The associated parameters identify the underlying hash function. For | |||

X9-HashFunctions, | alignment with the draft ANS X9.44, the hash function MUST be an ASC | |||

... -- implementations may define other methods | X9-approved hash function. (See Note.) However, other hash functions | |||

} | MAY be used with CMS. | |||

B.2.2 Symmetric Key-Wrapping Schemes | kdf3 ALGORITHM ::= { OID id-kdf-kdf3 PARMS KDF3-HashFunction } | |||

The object identifiers for the AES Key Wrap depends on the size of | KDF3-HashFunction ::= AlgorithmIdentifier { KDF3-HashFunctions } | |||

the key encrypting key. There are three object identifiers (see | ||||

[AES-WRAP]): | ||||

id-aes128-Wrap OID ::= { nistAlgorithm aes(1) aes128-Wrap(5) } | KDF3-HashFunctions ALGORITHM ::= { | |||

id-aes192-Wrap OID ::= { nistAlgorithm aes(1) aes192-Wrap(25) } | X9-HashFunctions, | |||

id-aes256-Wrap OID ::= { nistAlgorithm aes(1) aes256-Wrap(45) } | ... -- implementations may define other methods | |||

} | ||||

These object identifiers have no associated parameters. | B.2.2 Symmetric Key-Wrapping Schemes | |||

aes128-Wrap ALGORITHM ::= { OID id-aes128-Wrap } | The object identifiers for the AES Key Wrap depends on the size of | |||

aes192-Wrap ALGORITHM ::= { OID id-aes192-Wrap } | the key encrypting key. There are three object identifiers (see [AES- | |||

aes256-Wrap ALGORITHM ::= { OID id-aes256-Wrap } | WRAP]): | |||

The object identifier for the Triple-DES Key Wrap (see [3DES-WRAP]) | id-aes128-Wrap OID ::= { nistAlgorithm aes(1) aes128-Wrap(5) } | |||

is | id-aes192-Wrap OID ::= { nistAlgorithm aes(1) aes192-Wrap(25) } | |||

id-aes256-Wrap OID ::= { nistAlgorithm aes(1) aes256-Wrap(45) } | ||||

id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { | These object identifiers have no associated parameters. | |||

iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) | ||||

smime(16) alg(3) 6 | ||||

} | ||||

This object identifier has a NULL parameter. | aes128-Wrap ALGORITHM ::= { OID id-aes128-Wrap } | |||

aes192-Wrap ALGORITHM ::= { OID id-aes192-Wrap } | ||||

aes256-Wrap ALGORITHM ::= { OID id-aes256-Wrap } | ||||

tdes-Wrap ALGORITHM ::= | The object identifier for the Triple-DES Key Wrap (see [3DES-WRAP]) | |||

{ OID id-alg-CMS3DESwrap PARMS NullParms } | is: | |||

NOTE: As of this writing, the AES Key Wrap and the Triple-DES Key | id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { | |||

Wrap are in the process of being approved by ASC X9. | iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) | |||

smime(16) alg(3) 6 | ||||

} | ||||

The object identifiers for the Camellia Key Wrap depend on the size | This object identifier has a NULL parameter. | |||

of the key encrypting key. There are three object identifiers: | ||||

id-camellia128-Wrap OBJECT IDENTIFIER ::= | tdes-Wrap ALGORITHM ::= | |||

{ iso(1) member-body(2) 392 200011 61 security(1) | { OID id-alg-CMS3DESwrap PARMS NullParms } | |||

algorithm(1) key-wrap-algorithm(3) | ||||

camellia128-wrap(2) } | ||||

id-camellia192-Wrap OBJECT IDENTIFIER ::= | NOTE: As of this writing, the AES Key Wrap and the Triple-DES Key | |||

{ iso(1) member-body(2) 392 200011 61 security(1) | Wrap are in the process of being approved by ASC X9. | |||

algorithm(1) key-wrap-algorithm(3) | ||||

camellia192-wrap(3) } | ||||

id-camellia256-Wrap OBJECT IDENTIFIER ::= | The object identifiers for the Camellia Key Wrap depend on the size | |||

{ iso(1) member-body(2) 392 200011 61 security(1) | of the key encrypting key. There are three object identifiers: | |||

algorithm(1) key-wrap-algorithm(3) | ||||

camellia256-wrap(4) } | ||||

These object identifiers have no associated parameters. | id-camellia128-Wrap OBJECT IDENTIFIER ::= | |||

{ iso(1) member-body(2) 392 200011 61 security(1) | ||||

algorithm(1) key-wrap-algorithm(3) | ||||

camellia128-wrap(2) } | ||||

camellia128-Wrap ALGORITHM ::= { OID id-camellia128-Wrap } | id-camellia192-Wrap OBJECT IDENTIFIER ::= | |||

camellia192-Wrap ALGORITHM ::= { OID id-camellia192-Wrap } | { iso(1) member-body(2) 392 200011 61 security(1) | |||

camellia256-Wrap ALGORITHM ::= { OID id-camellia256-Wrap } | algorithm(1) key-wrap-algorithm(3) | |||

camellia192-wrap(3) } | ||||

B.3 ASN.1 module | id-camellia256-Wrap OBJECT IDENTIFIER ::= | |||

{ iso(1) member-body(2) 392 200011 61 security(1) | ||||

algorithm(1) key-wrap-algorithm(3) | ||||

camellia256-wrap(4) } | ||||

CMS-RSA-KEM | These object identifiers have no associated parameters. | |||

{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) | ||||

pkcs-9(9) smime(16) modules(0) cms-rsa-kem(21) } | ||||

DEFINITIONS ::= | camellia128-Wrap ALGORITHM ::= { OID id-camellia128-Wrap } | |||

camellia192-Wrap ALGORITHM ::= { OID id-camellia192-Wrap } | ||||

camellia256-Wrap ALGORITHM ::= { OID id-camellia256-Wrap } | ||||

BEGIN | B.3 ASN.1 module | |||

-- EXPORTS ALL | CMS-RSA-KEM | |||

{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) | ||||

pkcs-9(9) smime(16) modules(0) cms-rsa-kem(21) } | ||||

-- IMPORTS None | DEFINITIONS ::= | |||

-- Useful types and definitions | BEGIN | |||

OID ::= OBJECT IDENTIFIER -- alias | -- EXPORTS ALL | |||

-- Unless otherwise stated, if an object identifier has associated | -- IMPORTS None | |||

-- parameters (i.e., the PARMS element is specified), the | -- Useful types and definitions | |||

-- parameters field shall be included in algorithm identifier | ||||

-- values. The parameters field shall be omitted if and only if | ||||

-- the object identifier does not have associated parameters | ||||

-- (i.e., the PARMS element is omitted), unless otherwise stated. | ||||

ALGORITHM ::= CLASS { | OID ::= OBJECT IDENTIFIER -- alias | |||

&id OBJECT IDENTIFIER UNIQUE, | ||||

&Type OPTIONAL | ||||

} | ||||

WITH SYNTAX { OID &id [PARMS &Type] } | ||||

AlgorithmIdentifier { ALGORITHM:IOSet } ::= SEQUENCE { | -- Unless otherwise stated, if an object identifier has associated | |||

algorithm ALGORITHM.&id( {IOSet} ), | -- parameters (i.e., the PARMS element is specified), the | |||

parameters ALGORITHM.&Type( {IOSet}{@algorithm} ) OPTIONAL | -- parameters field shall be included in algorithm identifier | |||

} | -- values. The parameters field shall be omitted if and only if | |||

-- the object identifier does not have associated parameters | ||||

-- (i.e., the PARMS element is omitted), unless otherwise stated. | ||||

NullParms ::= NULL | ALGORITHM ::= CLASS { | |||

&id OBJECT IDENTIFIER UNIQUE, | ||||

&Type OPTIONAL | ||||

} | ||||

WITH SYNTAX { OID &id [PARMS &Type] } | ||||

-- ISO/IEC 18033-2 arc | AlgorithmIdentifier { ALGORITHM:IOSet } ::= SEQUENCE { | |||

algorithm ALGORITHM.&id( {IOSet} ), | ||||

parameters ALGORITHM.&Type( {IOSet}{@algorithm} ) OPTIONAL | ||||

} | ||||

is18033-2 OID ::= { iso(1) standard(0) is18033(18033) part2(2) } | NullParms ::= NULL | |||

-- NIST algorithm arc | -- ISO/IEC 18033-2 arc | |||

nistAlgorithm OID ::= { | is18033-2 OID ::= { iso(1) standard(0) is18033(18033) part2(2) } | |||

joint-iso-itu-t(2) country(16) us(840) organization(1) | ||||

gov(101) csor(3) nistAlgorithm(4) | ||||

} | ||||

-- PKCS #1 arc | -- NIST algorithm arc | |||

pkcs-1 OID ::= { | nistAlgorithm OID ::= { | |||

iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) | joint-iso-itu-t(2) country(16) us(840) organization(1) | |||

} | gov(101) csor(3) nistAlgorithm(4) | |||

} | ||||

-- RSA-KEM Key Transport Algorithm | -- PKCS #1 arc | |||

id-rsa-kem OID ::= { | pkcs-1 OID ::= { | |||

iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) | iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) | |||

pkcs-9(9) smime(16) alg(3) TBA | } | |||

} | ||||

GenericHybridParameters ::= SEQUENCE { | -- RSA-KEM Key Transport Algorithm | |||

kem KeyEncapsulationMechanism, | ||||

dem DataEncapsulationMechanism | ||||

} | ||||

KeyEncapsulationMechanism ::= AlgorithmIdentifier {{KEMAlgorithms}} | id-rsa-kem OID ::= { | |||

id-kem-rsa OID ::= { | iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) | |||

is18033-2 key-encapsulation-mechanism(2) rsa(4) | pkcs-9(9) smime(16) alg(3) TBA | |||

} | } | |||

RsaKemParameters ::= SEQUENCE { | GenericHybridParameters ::= SEQUENCE { | |||

keyDerivationFunction KeyDerivationFunction, | kem KeyEncapsulationMechanism, | |||

keyLength KeyLength | dem DataEncapsulationMechanism | |||

} | } | |||

KeyDerivationFunction ::= AlgorithmIdentifier {{KDFAlgorithms}} | KeyEncapsulationMechanism ::= AlgorithmIdentifier {{KEMAlgorithms}} | |||

KDFAlgorithms ALGORITHM ::= { | KEMAlgorithms ALGORITHM ::= { kem-rsa, ... } | |||

kdf2 | kdf3, | ||||

... -- implementations may define other methods | ||||

} | ||||

KeyLength ::= INTEGER (1..MAX) | kem-rsa ALGORITHM ::= { OID id-kem-rsa PARMS RsaKemParameters } | |||

id-kem-rsa OID ::= { | ||||

is18033-2 key-encapsulation-mechanism(2) rsa(4) | ||||

} | ||||

DataEncapsulationMechanism ::= | RsaKemParameters ::= SEQUENCE { | |||

AlgorithmIdentifier {{DEMAlgorithms}} | keyDerivationFunction KeyDerivationFunction, | |||

keyLength KeyLength | ||||

} | ||||

DEMAlgorithms ALGORITHM ::= { | KeyDerivationFunction ::= AlgorithmIdentifier {{KDFAlgorithms}} | |||

X9-SymmetricKeyWrappingSchemes | | ||||

Camellia-KeyWrappingSchemes, | ||||

... -- implementations may define other methods | ||||

} | ||||

X9-SymmetricKeyWrappingSchemes ALGORITHM ::= { | KDFAlgorithms ALGORITHM ::= { | |||

aes128-Wrap | aes192-Wrap | aes256-Wrap | tdes-Wrap, | kdf2 | kdf3, | |||

... -- allows for future expansion | ... -- implementations may define other methods | |||

} | } | |||

X9-SymmetricKeyWrappingScheme ::= | KeyLength ::= INTEGER (1..MAX) | |||

AlgorithmIdentifier {{ X9-SymmetricKeyWrappingSchemes }} | ||||

Camellia-KeyWrappingSchemes ALGORITHM ::= { | DataEncapsulationMechanism ::= AlgorithmIdentifier {{DEMAlgorithms}} | |||

camellia128-Wrap | camellia192-Wrap | camellia256-Wrap, | ||||

... -- allows for future expansion | ||||

} | ||||

Camellia-KeyWrappingScheme ::= | DEMAlgorithms ALGORITHM ::= { | |||

AlgorithmIdentifier {{ Camellia-KeyWrappingSchemes }} | X9-SymmetricKeyWrappingSchemes | | |||

Camellia-KeyWrappingSchemes, | ||||

... -- implementations may define other methods | ||||

} | ||||

-- Key Derivation Functions | X9-SymmetricKeyWrappingSchemes ALGORITHM ::= { | |||

aes128-Wrap | aes192-Wrap | aes256-Wrap | tdes-Wrap, | ||||

... -- allows for future expansion | ||||

} | ||||

id-kdf-kdf2 OID ::= { x9-44-components kdf2(1) } | X9-SymmetricKeyWrappingScheme ::= | |||

-- Base arc | AlgorithmIdentifier {{ X9-SymmetricKeyWrappingSchemes }} | |||

x9-44 OID ::= { | Camellia-KeyWrappingSchemes ALGORITHM ::= { | |||

iso(1) identified-organization(3) tc68(133) country(16) x9(840) | camellia128-Wrap | camellia192-Wrap | camellia256-Wrap, | |||

x9Standards(9) x9-44(44) | ... -- allows for future expansion | |||

} | } | |||

x9-44-components OID ::= { x9-44 components(1) } | Camellia-KeyWrappingScheme ::= | |||

AlgorithmIdentifier {{ Camellia-KeyWrappingSchemes }} | ||||

kdf2 ALGORITHM ::= { OID id-kdf-kdf2 PARMS KDF2-HashFunction } | -- Key Derivation Functions | |||

KDF2-HashFunction ::= AlgorithmIdentifier {{ KDF2-HashFunctions }} | id-kdf-kdf2 OID ::= { x9-44-components kdf2(1) } | |||

KDF2-HashFunctions ALGORITHM ::= { | -- Base arc | |||

X9-HashFunctions, | x9-44 OID ::= { | |||

... -- implementations may define other methods | iso(1) identified-organization(3) tc68(133) country(16) x9(840) | |||

} | x9Standards(9) x9-44(44) | |||

} | ||||

-- id-kdf-kdf3 OID ::= { x9-44-components kdf3(2) } kdf3 ALGORITHM | x9-44-components OID ::= { x9-44 components(1) } | |||

::= { OID id-kdf-kdf2 PARMS KDF3-HashFunction } KDF3-HashFunction | ||||

::= AlgorithmIdentifier {{ KDF3-HashFunctions }} | ||||

KDF3-HashFunctions ALGORITHM ::= { | kdf2 ALGORITHM ::= { OID id-kdf-kdf2 PARMS KDF2-HashFunction } | |||

X9-HashFunctions, | ||||

... -- implementations may define other methods | ||||

} | ||||

-- Hash Functions | KDF2-HashFunction ::= AlgorithmIdentifier {{ KDF2-HashFunctions }} | |||

X9-HashFunctions ALGORITHM ::= { | KDF2-HashFunctions ALGORITHM ::= { | |||

sha1 | sha224 | sha256 | sha384 | sha512, | X9-HashFunctions, | |||

... -- allows for future expansion | ... -- implementations may define other methods | |||

} | } | |||

id-sha1 OID ::= { | id-kdf-kdf3 OID ::= { x9-44-components kdf3(2) } | |||

iso(1) identified-organization(3) oiw(14) secsig(3) | ||||

algorithms(2) sha1(26) | ||||

} | ||||

id-sha224 OID ::= { nistAlgorithm hashAlgs(2) sha256(4) } | kdf3 ALGORITHM ::= { OID id-kdf-kdf2 PARMS KDF3-HashFunction } | |||

id-sha256 OID ::= { nistAlgorithm hashAlgs(2) sha256(1) } | ||||

id-sha384 OID ::= { nistAlgorithm hashAlgs(2) sha384(2) } | ||||

id-sha512 OID ::= { nistAlgorithm hashAlgs(2) sha512(3) } | ||||

sha1 ALGORITHM ::= { OID id-sha1 } -- NullParms MUST be | ||||

sha224 ALGORITHM ::= { OID id-sha224 } -- accepted for these | ||||

sha256 ALGORITHM ::= { OID id-sha256 } -- OIDs | ||||

sha384 ALGORITHM ::= { OID id-sha384 } -- "" | ||||

sha512 ALGORITHM ::= { OID id-sha512 } -- "" | ||||

-- Symmetric Key-Wrapping Schemes | KDF3-HashFunction ::= AlgorithmIdentifier {{ KDF3-HashFunctions }} | |||

id-aes128-Wrap OID ::= { nistAlgorithm aes(1) aes128-Wrap(5) } | KDF3-HashFunctions ALGORITHM ::= { | |||

id-aes192-Wrap OID ::= { nistAlgorithm aes(1) aes192-Wrap(25) } | X9-HashFunctions, | |||

id-aes256-Wrap OID ::= { nistAlgorithm aes(1) aes256-Wrap(45) } | ... -- implementations may define other methods | |||

} | ||||

aes128-Wrap ALGORITHM ::= { OID id-aes128-Wrap } | -- Hash Functions | |||

aes192-Wrap ALGORITHM ::= { OID id-aes192-Wrap } | ||||

aes256-Wrap ALGORITHM ::= { OID id-aes256-Wrap } | ||||

id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { | X9-HashFunctions ALGORITHM ::= { | |||

iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) | sha1 | sha224 | sha256 | sha384 | sha512, | |||

smime(16) alg(3) 6 | ... -- allows for future expansion | |||

} | } | |||

tdes-Wrap ALGORITHM ::= { OID id-alg-CMS3DESwrap PARMS NullParms } | id-sha1 OID ::= { | |||

iso(1) identified-organization(3) oiw(14) secsig(3) | ||||

algorithms(2) sha1(26) | ||||

} | ||||

id-camellia128-Wrap OBJECT IDENTIFIER ::= | id-sha224 OID ::= { nistAlgorithm hashAlgs(2) sha256(4) } | |||

{ iso(1) member-body(2) 392 200011 61 security(1) | ||||

algorithm(1) key-wrap-algorithm(3) | ||||

camellia128-wrap(2) } | ||||

id-camellia192-Wrap OBJECT IDENTIFIER ::= | id-sha256 OID ::= { nistAlgorithm hashAlgs(2) sha256(1) } | |||

{ iso(1) member-body(2) 392 200011 61 security(1) | ||||

algorithm(1) key-wrap-algorithm(3) | ||||

camellia192-wrap(3) } | ||||

id-camellia256-Wrap OBJECT IDENTIFIER ::= | id-sha384 OID ::= { nistAlgorithm hashAlgs(2) sha384(2) } | |||

{ iso(1) member-body(2) 392 200011 61 security(1) | ||||

algorithm(1) key-wrap-algorithm(3) | ||||

camellia256-wrap(4) } | ||||

camellia128-Wrap ALGORITHM ::= { OID id-camellia128-Wrap } | id-sha512 OID ::= { nistAlgorithm hashAlgs(2) sha512(3) } | |||

camellia192-Wrap ALGORITHM ::= { OID id-camellia192-Wrap } | sha1 ALGORITHM ::= { OID id-sha1 } -- NullParms MUST be | |||

camellia256-Wrap ALGORITHM ::= { OID id-camellia256-Wrap } | ||||

END | sha224 ALGORITHM ::= { OID id-sha224 } -- accepted for these | |||

B.4 Examples | sha256 ALGORITHM ::= { OID id-sha256 } -- OIDs | |||

As an example, if the key derivation function is KDF3 based on SHA- | sha384 ALGORITHM ::= { OID id-sha384 } -- "" | |||

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 | ||||

Algorithm will have the following value: | ||||

SEQUENCE { | sha512 ALGORITHM ::= { OID id-sha512 } -- "" | |||

id-rsa-kem, -- RSA-KEM cipher | ||||

SEQUENCE { -- GenericHybridParameters | ||||

SEQUENCE { -- key encapsulation mechanism | ||||

id-kem-rsa, -- RSA-KEM | ||||

SEQUENCE { -- RsaKemParameters | ||||

SEQUENCE { -- key derivation function | ||||

id-kdf-kdf3, -- KDF3 | ||||

SEQUENCE { -- KDF2-HashFunction | ||||

id-sha256 -- SHA-256; no parameters (preferred) | ||||

}, | ||||

16 -- KEK length in bytes | ||||

}, | ||||

SEQUENCE { -- data encapsulation mechanism | ||||

id-aes128-Wrap -- AES-128 Wrap; no parameters | ||||

} | ||||

} | ||||

} | ||||

This AlgorithmIdentifier value has the following DER encoding (?? | -- Symmetric Key-Wrapping Schemes | |||

indicates the algorithm number which is to be assigned): | ||||

30 53 | id-aes128-Wrap OID ::= { nistAlgorithm aes(1) aes128-Wrap(5) } | |||

06 0b 2a 86 48 86 f7 0d 01 09 10 03 ?? -- id-rsa-kem | ||||

30 44 | ||||

30 25 | ||||

06 07 28 81 8c 71 02 02 04 -- id-kem-rsa | ||||

30 1a | ||||

30 16 | ||||

06 07 28 81 8c 71 02 05 02 -- id-kdf-kdf3 | ||||

30 0b | ||||

06 09 60 86 48 01 65 03 04 02 01 -- id-sha256 | ||||

02 10 -- 16 bytes | ||||

30 0b | ||||

06 09 60 86 48 01 65 03 04 01 05 -- id-aes128-Wrap | ||||

The DER encodings for other typical sets of underlying components are | id-aes192-Wrap OID ::= { nistAlgorithm aes(1) aes192-Wrap(25) } | |||

as follows: | ||||

o KDF3 based on SHA-384, AES Key Wrap with a 192-bit KEK | id-aes256-Wrap OID ::= { nistAlgorithm aes(1) aes256-Wrap(45) } | |||

30 46 06 0b 2a 86 48 86 f7 0d 01 09 10 03 ?? 02 | aes128-Wrap ALGORITHM ::= { OID id-aes128-Wrap } | |||

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 | ||||

o KDF3 based on SHA-512, AES Key Wrap with a 256-bit KEK | aes192-Wrap ALGORITHM ::= { OID id-aes192-Wrap } | |||

30 46 06 0b 2a 86 48 86 f7 0d 01 09 10 03 ?? 02 | aes256-Wrap ALGORITHM ::= { OID id-aes256-Wrap } | |||

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 | ||||

o KDF2 based on SHA-1, Triple-DES Key Wrap with a 128-bit KEK (two- | id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { | |||

key triple-DES) | iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) | |||

smime(16) alg(3) 6 | ||||

} | ||||

30 46 06 0b 2a 86 48 86 f7 0d 01 09 10 03 ?? 02 | tdes-Wrap ALGORITHM ::= { OID id-alg-CMS3DESwrap PARMS NullParms } | |||

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 | id-camellia128-Wrap OBJECT IDENTIFIER ::= | |||

{ iso(1) member-body(2) 392 200011 61 security(1) | ||||

algorithm(1) key-wrap-algorithm(3) | ||||

camellia128-wrap(2) } | ||||

Within the CMS, algorithms are identified by object identifiers | id-camellia192-Wrap OBJECT IDENTIFIER ::= | |||

(OIDs). With one exception, all of the OIDs used in this document | { iso(1) member-body(2) 392 200011 61 security(1) | |||

were assigned in other IETF documents, in ISO/IEC standards | algorithm(1) key-wrap-algorithm(3) | |||

documents, by the National Institute of Standards and Technology | camellia192-wrap(3) } | |||

(NIST), and in Public-Key Cryptography Standards (PKCS) documents. | ||||

The one exception is that the ASN.1 module's identifier (see Appendix | ||||

B.3) is assigned in this document. No further action by the IANA is | ||||

necessary for this document or any anticipated updates. | ||||

Acknowledgments | id-camellia256-Wrap OBJECT IDENTIFIER ::= | |||

{ iso(1) member-body(2) 392 200011 61 security(1) | ||||

algorithm(1) key-wrap-algorithm(3) | ||||

camellia256-wrap(4) } | ||||

This document is one part of a strategy to align algorithm standards | camellia128-Wrap ALGORITHM ::= { OID id-camellia128-Wrap } | |||

produced by ASC X9, ISO/IEC JTC1 SC27, NIST, and the IETF. We would | camellia192-Wrap ALGORITHM ::= { OID id-camellia192-Wrap } | |||

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 | camellia256-Wrap ALGORITHM ::= { OID id-camellia256-Wrap } | |||

encouragement. We also appreciate the helpful direction we've | ||||

received from Blake Ramsdell and Jim Schaad in bringing this document | ||||

to fruition. A special thanks to Magnus Nystrom for his assistance on | ||||

Appendix B. Thanks also to Bob Griffin and John Linn for both | ||||

editorial direction and procedural guidance. | ||||

Author Information | END | |||

James Randall | B.4 Examples | |||

Randall Consulting | As an example, if the key derivation function is KDF3 based on SHA- | |||

55 Sandpiper Drive | 256 and the symmetric key-wrapping scheme is the AES Key Wrap with a | |||

Dover, NH 03820 | 128-bit KEK, the AlgorithmIdentifier for the RSA-KEM Key Transport | |||

USA | Algorithm will have the following value: | |||

Email: jdrandall@comcast.net | SEQUENCE { | |||

id-rsa-kem, -- RSA-KEM cipher | ||||

SEQUENCE { -- GenericHybridParameters | ||||

SEQUENCE { -- key encapsulation mechanism | ||||

id-kem-rsa, -- RSA-KEM | ||||

SEQUENCE { -- RsaKemParameters | ||||

SEQUENCE { -- key derivation function | ||||

id-kdf-kdf3, -- KDF3 | ||||

SEQUENCE { -- KDF3-HashFunction | ||||

id-sha256 -- SHA-256; no parameters (preferred) | ||||

}, | ||||

16 -- KEK length in bytes | ||||

}, | ||||

SEQUENCE { -- data encapsulation mechanism | ||||

id-aes128-Wrap -- AES-128 Wrap; no parameters | ||||

} | ||||

} | ||||

} | ||||

Burt Kaliski | This AlgorithmIdentifier value has the following DER encoding (?? | |||

indicates the algorithm number which is to be assigned): | ||||

EMC | 30 53 | |||

176 South Street | 06 0b 2a 86 48 86 f7 0d 01 09 10 03 ?? -- id-rsa-kem | |||

Hopkinton, MA 01748 | 30 44 | |||

USA | 30 25 | |||

06 07 28 81 8c 71 02 02 04 -- id-kem-rsa | ||||

30 1a | ||||

30 16 | ||||

06 07 28 81 8c 71 02 05 02 -- id-kdf-kdf3 | ||||

30 0b | ||||

06 09 60 86 48 01 65 03 04 02 01 -- id-sha256 | ||||

02 10 -- 16 bytes | ||||

Email: kaliski_burt@emc.com | 30 0b | |||

06 09 60 86 48 01 65 03 04 01 05 -- id-aes128-Wrap | ||||

John Brainard | The DER encodings for other typical sets of underlying components are | |||

as follows: | ||||

RSA, The Security Division of EMC | o KDF3 based on SHA-384, AES Key Wrap with a 192-bit KEK | |||

174 Middlesex Turnpike | ||||

Bedford, MA 01730 | ||||

USA | ||||

Email: jbrainard@rsa.com | ||||

Sean Turner | 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 | ||||

IECA, Inc. | o KDF3 based on SHA-512, AES Key Wrap with a 256-bit KEK | |||

3057 Nutley Street, Suite 106 | ||||

Fairfax, VA 22031 | ||||

USA | ||||

Email: turners@ieca.com | 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 | ||||

o KDF2 based on SHA-1, Triple-DES Key Wrap with a 128-bit KEK (two- | ||||

key triple-DES) | ||||

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 Public-Key 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. | ||||

Authors' Addresses | ||||

James Randall | ||||

Randall Consulting | ||||

55 Sandpiper Drive | ||||

Dover, NH 03820 | ||||

USA | ||||

Email: jdrandall@comcast.net | ||||

Burt Kaliski | ||||

EMC | ||||

176 South Street | ||||

Hopkinton, MA 01748 | ||||

USA | ||||

Email: kaliski_burt@emc.com | ||||

John Brainard | ||||

RSA, The Security Division of EMC | ||||

174 Middlesex Turnpike | ||||

Bedford, MA 01730 | ||||

USA | ||||

Email: jbrainard@rsa.com | ||||

Sean Turner | ||||

IECA, Inc. | ||||

3057 Nutley Street, Suite 106 | ||||

Fairfax, VA 22031 | ||||

USA | ||||

Email: turners@ieca.com | ||||

End of changes. 299 change blocks. | ||||

875 lines changed or deleted | | 832 lines changed or added | ||

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