draft-ietf-smime-cms-rsa-kem-13.txt | rfc5990.txt | |||
---|---|---|---|---|

S/MIME WG James Randall, Randall Consulting | ||||

Internet Draft Burt Kaliski, EMC | ||||

Intended Status: Standards Track John Brainard, RSA | ||||

Sean Turner, IECA | ||||

Expires: November 29, 2010 May 29, 2010 | ||||

Use of the RSA-KEM Key Transport Algorithm in CMS | Internet Engineering Task Force (IETF) J. Randall | |||

<draft-ietf-smime-cms-rsa-kem-13.txt> | Request for Comments: 5990 Randall Consulting | |||

Category: Standards Track B. Kaliski | ||||

ISSN: 2070-1721 EMC | ||||

J. Brainard | ||||

RSA | ||||

S. Turner | ||||

IECA | ||||

September 2010 | ||||

Use of the RSA-KEM Key Transport Algorithm | ||||

in the Cryptographic Message Syntax (CMS) | ||||

Abstract | Abstract | |||

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

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

recipient's RSA public key. This document specifies the conventions | recipient's RSA public key. ("KEM" stands for "key encapsulation | |||

for using the RSA-KEM Key Transport Algorithm with the Cryptographic | mechanism".) This document specifies the conventions for using the | |||

Message Syntax (CMS). The ASN.1 syntax is aligned with an expected | RSA-KEM Key Transport Algorithm with the Cryptographic Message Syntax | |||

forthcoming change to ANS X9.44. | (CMS). The ASN.1 syntax is aligned with an expected forthcoming | |||

change to American National Standard (ANS) X9.44. | ||||

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

Internet-Drafts are working documents of the Internet Engineering | Status of This Memo | |||

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

other groups may also distribute working documents as Internet- | ||||

Drafts. | ||||

Internet-Drafts are draft documents valid for a maximum of six months | This is an Internet Standards Track document. | |||

and may be updated, replaced, or obsoleted by other documents at any | ||||

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 | This document is a product of the Internet Engineering Task Force | |||

http://www.ietf.org/ietf/1id-abstracts.txt | (IETF). It represents the consensus of the IETF community. It has | |||

The list of Internet-Draft Shadow Directories can be accessed at | received public review and has been approved for publication by the | |||

http://www.ietf.org/shadow.html | Internet Engineering Steering Group (IESG). Further information on | |||

Internet Standards is available in Section 2 of RFC 5741. | ||||

This Internet-Draft will expire on November 29, 2010. | Information about the current status of this document, any errata, | |||

and how to provide feedback on it may be obtained at | ||||

http://www.rfc-editor.org/info/rfc5990. | ||||

Copyright Notice | Copyright Notice | |||

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

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

This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||

Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||

(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||

publication of this document. Please review these documents | publication of this document. Please review these documents | |||

carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||

to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||

include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||

the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||

described in the Simplified BSD License. | described in the Simplified BSD License. | |||

Conventions Used in This Document | ||||

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | ||||

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

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

Table of Contents | Table of Contents | |||

1. Introduction...................................................3 | 1. Introduction ....................................................3 | |||

2. Use in CMS.....................................................4 | 1.1. Conventions Used in This Document ..........................4 | |||

2.1. Underlying Components.....................................4 | 2. Use in CMS ......................................................4 | |||

2.2. RecipientInfo Conventions.................................5 | 2.1. Underlying Components ......................................4 | |||

2.3. Certificate Conventions...................................5 | 2.2. RecipientInfo Conventions ..................................5 | |||

2.4. SMIMECapabilities Attribute Conventions...................6 | 2.3. Certificate Conventions ....................................5 | |||

3. Security Considerations........................................7 | 2.4. SMIMECapabilities Attribute Conventions ....................6 | |||

4. IANA Considerations............................................9 | 3. Security Considerations .........................................7 | |||

5. Acknowledgements...............................................9 | 4. IANA Considerations .............................................9 | |||

6. References....................................................10 | 5. Acknowledgements ................................................9 | |||

6.1. Normative References.....................................10 | 6. References .....................................................10 | |||

6.2. Informative References...................................11 | 6.1. Normative References ......................................10 | |||

Appendix A. RSA-KEM Key Transport Algorithm......................11 | 6.2. Informative References ....................................11 | |||

A.1. Underlying Components....................................12 | Appendix A. RSA-KEM Key Transport Algorithm ......................12 | |||

A.2. Sender's Operations......................................12 | A.1. Underlying Components ....................................12 | |||

A.3. Recipient's Operations...................................13 | A.2. Sender's Operations ......................................12 | |||

Appendix B. ASN.1 Syntax.........................................15 | A.3. Recipient's Operations ...................................13 | |||

B.1. RSA-KEM Key Transport Algorithm..........................15 | Appendix B. ASN.1 Syntax .........................................15 | |||

B.2. Selected Underlying Components...........................17 | B.1. RSA-KEM Key Transport Algorithm ..........................16 | |||

B.2.1. Key Derivation Functions............................17 | B.2. Selected Underlying Components ...........................18 | |||

B.2.2. Symmetric Key-Wrapping Schemes......................19 | B.2.1. Key Derivation Functions ............................18 | |||

B.3. ASN.1 module.............................................20 | B.2.2. Symmetric Key-Wrapping Schemes ......................19 | |||

B.4. Examples.................................................26 | B.3. ASN.1 Module .............................................20 | |||

Authors' Addresses...............................................28 | B.4. Examples .................................................25 | |||

1. Introduction | 1. Introduction | |||

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

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

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

Most previous key transport algorithms based on the RSA public-key | Most previous key transport algorithms based on the RSA public-key | |||

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

the following general form: | the following general form: | |||

1. Format or "pad" the keying data to obtain an integer m. | 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 | The RSA-KEM Key Transport Algorithm takes a different approach that | |||

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

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

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

1. Generate a random integer z between 0 and n-1. | 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 | This different approach provides higher security assurance because | |||

(a) the input to the underlying RSA operation is effectively a random | (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 | 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) | have any structure that could be exploited by an adversary, and | |||

the input is independent of the keying data so the result of the RSA | (b) the input is independent of the keying data so the result of the | |||

decryption operation is not directly available to an adversary. As a | RSA decryption operation is not directly available to an adversary. | |||

result, the algorithm enjoys a "tight" security proof in the random | As a result, the algorithm enjoys a "tight" security proof in the | |||

oracle model. (In other padding schemes, such as PKCS #1 v1.5, the | random oracle model. (In other padding schemes, such as PKCS #1 | |||

input has structure and/or depends on the keying data, and the | v1.5, the input has structure and/or depends on the keying data, and | |||

provable security assurances are not as strong.) The approach is also | the provable security assurances are not as strong.) The approach is | |||

architecturally convenient because the public-key operations are | also architecturally convenient because the public-key operations are | |||

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

benefit is that the length of the keying data is bounded only by the | benefit is that the length of the keying data is bounded only by the | |||

symmetric key-wrapping scheme, not the size of the RSA modulus. | symmetric key-wrapping scheme, not the size of the RSA modulus. | |||

The RSA-KEM Key Transport Algorithm in various forms is being adopted | The RSA-KEM Key Transport Algorithm in various forms is being adopted | |||

in several draft standards as well as in ANS-X9.44 [ANS-9.44]. It has | in several draft standards as well as in American National Standard | |||

also been recommended by the NESSIE project [NESSIE]. Originally, | (ANS) X9.44 [ANS-X9.44]. It has also been recommended by the New | |||

[ANS-9.44] specified the of different object identifier to identify | European Schemes for Signatures, Integrity, and Encryption (NESSIE) | |||

the RSA-KEM Key Transport Algorithm. [ANS-9.44] used id-ac-generic- | project [NESSIE]. Originally, [ANS-X9.44] specified a different | |||

hybrid while this document uses id-rsa-kem. These OIDs are used in | object identifier to identify the RSA-KEM Key Transport Algorithm. | |||

the KeyTransportInfo field to indicate the key encryption algorithm, | [ANS-X9.44] used id-ac-generic-hybrid, while this document uses | |||

in certificates to allow recipients to restrict their public keys for | id-rsa-kem. These OIDs are used in the KeyTransportInfo field to | |||

use with RSA-KEM only, and in SMIME Capability attributes to allow | indicate the key encryption algorithm, in certificates to allow | |||

recipients to advertise their support for RSA-KEM. Legacy | recipients to restrict their public keys for use with RSA-KEM only, | |||

implementations that wish to interoperate with [ANS-X9.44] should | and in SMIME Capability attributes to allow recipients to advertise | |||

consult that specification for more information on id-ac-generic- | their support for RSA-KEM. Legacy implementations that wish to | |||

hybrid. | interoperate with [ANS-X9.44] should consult that specification for | |||

more information on id-ac-generic-hybrid. | ||||

For completeness, a specification of the algorithm is given in | For completeness, a specification of the algorithm is given in | |||

Appendix A of this document; ASN.1 syntax is given in Appendix B. | Appendix A of this document; ASN.1 syntax is given in Appendix B. | |||

NOTE: The term KEM stands for "key encapsulation mechanism" and | NOTE: The term "KEM" stands for "key encapsulation mechanism" and | |||

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

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

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

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

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

[SHOUP]. | ||||

2. Use in CMS | 1.1. Conventions Used in This Document | |||

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | ||||

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

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

2. Use in CMS | ||||

The RSA-KEM Key Transport Algorithm MAY be employed for one or more | The RSA-KEM Key Transport Algorithm MAY be employed for one or more | |||

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

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

content-encryption key. | content-encryption key. | |||

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

A CMS implementation that supports the RSA-KEM Key Transport | A CMS implementation that supports the RSA-KEM Key Transport | |||

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

o For the key derivation function, KDF3 (see [ANS-9.44]) based on | o For the key derivation function, KDF3 (see [ANS-X9.44]) based on | |||

SHA-256 (see [FIPS-180-3]). KDF3 is an instantiation of the | SHA-256 (see [FIPS-180-3]). KDF3 is an instantiation of the | |||

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

56A]. | ||||

o For the key-wrapping scheme, AES-Wrap-128, i.e., the AES Key | o For the key-wrapping scheme, AES-Wrap-128, i.e., the AES Key Wrap | |||

Wrap with a 128-bit key encrypting key (see [AES-WRAP]). | with a 128-bit key-encrypting key (see [AES-WRAP]). | |||

An implementation SHOULD also support KDF2 (see [ANS-X9.44]) based on | An implementation SHOULD also support KDF2 (see [ANS-X9.44]) based on | |||

SHA-1 (this function is also specified as the key derivation function | SHA-1 (this function is also specified as the key derivation function | |||

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

SHOULD be supported if Camellia is supported as a content-encryption | SHOULD be supported if Camellia is supported as a content-encryption | |||

cipher. The Triple-DES Key Wrap (see [3DES-WRAP]) SHOULD also be | cipher. The Triple-DES Key Wrap (see [3DES-WRAP]) SHOULD also be | |||

supported if Triple-DES is supported as a content-encryption cipher. | supported if Triple-DES is supported as a content-encryption cipher. | |||

It MAY support other underlying components. When AES or Camellia are | It MAY support other underlying components. When AES or Camellia is | |||

used, the data block size is 128 bits and the key size can be 128, | used, the data block size is 128 bits and the key size can be 128, | |||

192, or 256 bits, while Triple DES requires a data block size of 64 | 192, or 256 bits, while Triple-DES requires a data block size of | |||

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

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

When the RSA-KEM Key Transport Algorithm is employed for a recipient, | When the RSA-KEM Key Transport Algorithm is employed for a recipient, | |||

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

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

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

o keyEncryptionAlgorithm.algorithm MUST be id-rsa-kem (see | o keyEncryptionAlgorithm.algorithm MUST be id-rsa-kem (see | |||

Appendix B); | Appendix B); | |||

o keyEncryptionAlgorithm.parameters MUST be a value of type | o keyEncryptionAlgorithm.parameters MUST be a value of type | |||

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

encapsulation mechanism (see Appendix B); | mechanism (see Appendix B); | |||

o encryptedKey MUST be the encrypted keying data output by the | o encryptedKey MUST be the encrypted keying data output by the | |||

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

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

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

The conventions specified in this section augment RFC 5280 [PROFILE]. | The conventions specified in this section augment RFC 5280 [PROFILE]. | |||

A recipient who employs the RSA-KEM Key Transport Algorithm MAY | A recipient who employs the RSA-KEM Key Transport Algorithm MAY | |||

identify the public key in a certificate by the same | identify the public key in a certificate by the same | |||

AlgorithmIdentifier as for the PKCS #1 v1.5 algorithm, i.e., using | AlgorithmIdentifier as for the PKCS #1 v1.5 algorithm, i.e., using | |||

the rsaEncryption object identifier [PKCS1]. The fact that the user | the rsaEncryption object identifier [PKCS1]. The fact that the user | |||

will accept RSA-KEM with this public key is not indicated by the use | will accept RSA-KEM with this public key is not indicated by the use | |||

of this identifier. This MAY be signaled by the use of the | of this identifier. This MAY be signaled by the use of the | |||

appropriate SMIME Capabilities either in a message or in the | appropriate SMIME Capabilities either in a message or in the | |||

certificate. | certificate. | |||

If the recipient wishes only to employ the RSA-KEM Key Transport | If the recipient wishes only to employ the RSA-KEM Key Transport | |||

Algorithm with a given public key, the recipient MUST identify the | Algorithm with a given public key, the recipient MUST identify the | |||

public key in the certificate using the id-rsa-kem object identifier | public key in the certificate using the id-rsa-kem object identifier | |||

(see Appendix B). When the id-rsa-kem algorithm identifier appears in | (see Appendix B). When the id-rsa-kem algorithm identifier appears | |||

the SubjectPublicKeyInfo algorithm field, the encoding SHALL omit the | in the SubjectPublicKeyInfo algorithm field, the encoding SHALL omit | |||

parameters field from AlgorithmIdentifier. That is, the | the parameters field from AlgorithmIdentifier. That is, the | |||

AlgorithmIdentifier SHALL be a SEQUENCE of one component, the object | AlgorithmIdentifier SHALL be a SEQUENCE of one component, the object | |||

identifier id-rsa-kem. | identifier id-rsa-kem. | |||

Regardless of the AlgorithmIdentifier used, the RSA public key is | Regardless of the AlgorithmIdentifier used, the RSA public key is | |||

encoded in the same manner in the subject public key information. The | encoded in the same manner in the subject public key information. | |||

RSA public key MUST be encoded using the type RSAPublicKey type: | The RSA public key MUST be encoded using the type RSAPublicKey type: | |||

RSAPublicKey ::= SEQUENCE { | RSAPublicKey ::= SEQUENCE { | |||

modulus INTEGER, -- n | modulus INTEGER, -- n | |||

publicExponent INTEGER -- e | publicExponent INTEGER -- e | |||

} | } | |||

Here, the modulus is the modulus n, and publicExponent is the public | Here, the modulus is the modulus n, and publicExponent is the public | |||

exponent e. The DER encoded RSAPublicKey is carried in the | exponent e. The Distinguished Encoding Rules (DER)-encoded | |||

subjectPublicKey BIT STRING within the subject public key | RSAPublicKey is carried in the subjectPublicKey BIT STRING within the | |||

information. | subject public key information. | |||

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

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

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

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

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

keyEncipherment. | keyEncipherment | |||

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

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

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

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

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

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

essential to maintain provable security. | essential to maintain provable security. | |||

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

RFC 3851 [MSG], Section 2.5.2 defines the SMIMECapabilities signed | RFC 3851 [MSG], Section 2.5.2 defines the SMIMECapabilities signed | |||

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

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

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

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

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

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

The SMIMECapability SEQUENCE representing the RSA-KEM Key Transport | The SMIMECapability SEQUENCE representing the RSA-KEM Key Transport | |||

Algorithm MUST include the id-rsa-kem object identifier (see Appendix | Algorithm MUST include the id-rsa-kem object identifier (see | |||

B) in the capabilityID field and MUST include a | Appendix B) in the capabilityID field and MUST include a | |||

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

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

The DER encoding of a SMIMECapability SEQUENCE is the same as the DER | The DER encoding of a SMIMECapability SEQUENCE is the same as the DER | |||

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

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

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

The RSA-KEM Key Transport Algorithm should be considered for new CMS- | The RSA-KEM Key Transport Algorithm should be considered for new CMS- | |||

based applications as a replacement for the widely implemented RSA | based applications as a replacement for the widely implemented RSA | |||

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

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

chosen-ciphertext attacks. The RSAES-OAEP Key Transport Algorithm | chosen-ciphertext attacks. The RSA Encryption Scheme - Optimal | |||

Asymmetric Encryption Padding (RSAES-OAEP) Key Transport Algorithm | ||||

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

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

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

The security of the RSA-KEM Key Transport Algorithm described in this | The security of the RSA-KEM Key Transport Algorithm described in this | |||

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

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

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

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

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

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

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

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

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

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

random oracle model. | random oracle model. | |||

The RSA key size and the underlying components should be selected | The RSA key size and the underlying components should be selected | |||

consistent with the desired symmetric security level for an | consistent with the desired symmetric security level for an | |||

application. Several security levels have been identified in NIST | application. Several security levels have been identified in the | |||

FIPS PUB 800-57 [NIST-GUIDELINE]. For brevity, the first three levels | NIST FIPS PUB 800-57 [NIST-GUIDELINE]. For brevity, the first three | |||

are mentioned here: | levels are mentioned here: | |||

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

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

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

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

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

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

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

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

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

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

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

Camellia Key Wrap. | Camellia Key Wrap. | |||

Note that the AES Key Wrap or Camellia Key Wrap MAY be used at all | Note that the AES Key Wrap or Camellia Key Wrap MAY be used at all | |||

three of these levels; the use of AES or Camellia does not require a | three of these levels; the use of AES or Camellia does not require a | |||

128-bit security level for other components. | 128-bit security level for other components. | |||

Implementations MUST protect the RSA private key and the content- | Implementations MUST protect the RSA private key and the content- | |||

encryption key. Compromise of the RSA private key may result in the | encryption key. Compromise of the RSA private key may result in the | |||

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

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

encrypted content. | encrypted content. | |||

Additional considerations related to key management may be found in | Additional considerations related to key management may be found in | |||

[NIST-GUIDELINE]. | [NIST-GUIDELINE]. | |||

The security of the algorithm also depends on the strength of the | The security of the algorithm also depends on the strength of the | |||

random number generator, which SHOULD have a comparable security | random number generator, which SHOULD have a comparable security | |||

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

[RANDOM]. | see [RANDOM]. | |||

Implementations SHOULD NOT reveal information about intermediate | Implementations SHOULD NOT reveal information about intermediate | |||

values or calculations, whether by timing or other "side channels", | values or calculations, whether by timing or other "side channels", | |||

or otherwise an opponent may be able to determine information about | or otherwise an opponent may be able to determine information about | |||

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

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

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

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

useful. | useful. | |||

Generally, good cryptographic practice employs a given RSA key pair | Generally, good cryptographic practice employs a given RSA key pair | |||

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

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

essential to maintain provable security. While RSA public keys have | essential to maintain provable security. While RSA public keys have | |||

often been employed for multiple purposes such as key transport and | often been employed for multiple purposes such as key transport and | |||

digital signature without any known bad interactions, for increased | digital signature without any known bad interactions, for increased | |||

security assurance, such combined use of an RSA key pair is NOT | security assurance, such combined use of an RSA key pair is NOT | |||

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

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

Accordingly, an RSA key pair used for the RSA-KEM Key Transport | Accordingly, an RSA key pair used for the RSA-KEM Key Transport | |||

Algorithm SHOULD NOT also be used for digital signatures. (Indeed, | Algorithm SHOULD NOT also be used for digital signatures. (Indeed, | |||

ASC X9 requires such a separation between key establishment key pairs | the Accredited Standards Committee X9 (ASC X9) requires such a | |||

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

separation, a key pair used for the RSA-KEM Key Transport Algorithm | key pairs.) Continuing this principle of key separation, a key pair | |||

SHOULD NOT be used with other key establishment schemes, or for data | used for the RSA-KEM Key Transport Algorithm SHOULD NOT be used with | |||

encryption, or with more than one set of underlying algorithm | other key establishment schemes, or for data encryption, or with more | |||

components. | than one set of underlying algorithm components. | |||

Parties MAY formalize the assurance that one another's | Parties MAY formalize the assurance that one another's | |||

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

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

4. IANA Considerations | 4. IANA Considerations | |||

Within the CMS, algorithms are identified by object identifiers | Within the CMS, algorithms are identified by object identifiers | |||

(OIDs). With one exception, all of the OIDs used in this document | (OIDs). With one exception, all of the OIDs used in this document | |||

were assigned in other IETF documents, in ISO/IEC standards | were assigned in other IETF documents, in ISO/IEC standards | |||

documents, by the National Institute of Standards and Technology | documents, by the National Institute of Standards and Technology | |||

(NIST), and in Public-Key Cryptography Standards (PKCS) documents. | (NIST), and in Public-Key Cryptography Standards (PKCS) documents. | |||

The one exception is that the ASN.1 module's identifier (see Appendix | The two exceptions are the ASN.1 module's identifier (see Appendix | |||

B.3) is assigned in this document. No further action by the IANA is | B.3) and id-rsa-kem that are both assigned in this document. The | |||

necessary for this document or any anticipated updates. | module object identifiers are defined in an arc delegated by the | |||

former company RSA Data Security Inc. to the S/MIME Working Group. | ||||

When the S/MIME Working Group closes, this arc and its registration | ||||

procedures will be transferred to IANA. | ||||

5. Acknowledgements | 5. Acknowledgements | |||

This document is one part of a strategy to align algorithm standards | 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 | 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 | like to thank the members of the ASC X9F1 working group for their | |||

contributions to drafts of ANS X9.44 which led to this specification. | contributions to drafts of ANS X9.44, which led to this | |||

specification. | ||||

Our thanks to Russ Housley as well for his guidance and | Our thanks to Russ Housley as well for his guidance and | |||

encouragement. We also appreciate the helpful direction we've | encouragement. We also appreciate the helpful direction we've | |||

received from Blake Ramsdell and Jim Schaad in bringing this document | received from Blake Ramsdell and Jim Schaad in bringing this document | |||

to fruition. A special thanks to Magnus Nystrom for his assistance on | to fruition. A special thanks to Magnus Nystrom for his assistance | |||

Appendix B. Thanks also to Bob Griffin and John Linn for both | on Appendix B. Thanks also to Bob Griffin and John Linn for both | |||

editorial direction and procedural guidance. | editorial direction and procedural guidance. | |||

6. References | 6. References | |||

6.1. Normative References | 6.1. Normative References | |||

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

3217. December 2001. | RFC 3217, December 2001. | |||

[AES-WRAP] Schaad, J. and R. Housley. Advanced Encryption | [AES-WRAP] Schaad, J. and R. Housley, "Advanced Encryption | |||

Standard (AES) Key Wrap Algorithm. RFC 3394. | Standard (AES) Key Wrap Algorithm", RFC 3394, | |||

September 2002. | September 2002. | |||

[ANS-X9.44] ASC X9F1 Working Group. American National Standard | [ANS-X9.44] ASC X9F1 Working Group. American National Standard | |||

X9.44: Public Key Cryptography for the Financial | X9.44: Public Key Cryptography for the Financial | |||

Services Industry -- Key Establishment Using | Services Industry -- Key Establishment Using | |||

Integer Factorization Cryptography. 2007. | Integer Factorization Cryptography. 2007. | |||

[ANS-X9.63] American National Standard X9.63-2002: Public Key | [ANS-X9.63] American National Standard X9.63-2002: Public Key | |||

Cryptography for the Financial Services Industry: | Cryptography for the Financial Services Industry: | |||

Key Agreement and Key Transport Using Elliptic | Key Agreement and Key Transport Using Elliptic | |||

Curve Cryptography. | Curve Cryptography. | |||

[CAMELLIA] Kato, A., Moriai, S., and Kanda, M.: Use of the | [CAMELLIA] Moriai, S. and A. Kato, "Use of the Camellia | |||

Camellia Encryption Algorithm in Cryptographic | Encryption Algorithm in Cryptographic Message | |||

Message Syntax. RFC 3657. December 2005. | Syntax (CMS)", RFC 3657, January 2004. | |||

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

5652. September 20009. | RFC 5652, September 2009. | |||

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

Algorithms. RFC 3370. August 2002. | Algorithms", RFC 3370, August 2002. | |||

[FIPS-180-3] National Institute of Standards and Technology | [FIPS-180-3] National Institute of Standards and Technology | |||

(NIST). FIPS 180-3: Secure Hash Standard. October | (NIST). FIPS 180-3: Secure Hash Standard. October | |||

2008. | 2008. | |||

[MSG] Ramsdell, B., and S. Turner. S/MIME Version 3.2 | [MSG] Ramsdell, B. and S. Turner, "Secure/Multipurpose | |||

Message Specification. RFC 5751. January 2010. | Internet Mail Extensions (S/MIME) Version 3.2 | |||

Message Specification", RFC 5751, January 2010. | ||||

[PROFILE] Cooper, D., Santesson, S., Farrell, S., Boeyen, | [PROFILE] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., | |||

S., Housley, R., and W. Polk. Internet X.509 | Housley, R., and W. Polk, "Internet X.509 Public | |||

Public Key Infrastructure Certificate and | Key Infrastructure Certificate and Certificate | |||

Certificate Revocation List (CRL) Profile. RFC | Revocation List (CRL) Profile", RFC 5280, May 2008. | |||

5280. May 2008. | ||||

[STDWORDS] Bradner, S. Key Words for Use in RFCs to Indicate | [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate | |||

Requirement Levels. RFC 2119. March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||

6.2. Informative References | 6.2. Informative References | |||

[AES-WRAP-PAD] Housley, R., and M. Dworkin. Advanced Encryption | [AES-WRAP-PAD] Housley, R. and M. Dworkin, "Advanced Encryption | |||

Standard (AES) Key Wrap with Padding Algorithm. | Standard (AES) Key Wrap with Padding Algorithm", | |||

RFC 5649. August 2009. | RFC 5649, September 2009. | |||

[CMS-OAEP] Housley, R. Use of the RSAES-OAEP Key Transport | [CMS-OAEP] Housley, R., "Use of the RSAES-OAEP Key Transport | |||

Algorithm in the Cryptographic Message Syntax | Algorithm in Cryptographic Message Syntax (CMS)", | |||

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

[NESSIE] NESSIE Consortium. Portfolio of Recommended | [NESSIE] NESSIE Consortium. Portfolio of Recommended | |||

Cryptographic Primitives. February 27, 2003. | Cryptographic Primitives. February 2003. | |||

Available via http://www.cryptonessie.org/. | http://www.cryptonessie.org/. | |||

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

Special Publication 800-57: Recommendation for | Special Publication 800-57: Recommendation for Key | |||

Pairwise Key Establishment Schemes Using Discrete | Management - Part 1: General (Revised). March | |||

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

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

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

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

Key Management. Part 1: General Guideline. August | Pair-Wise Key Establishment Schemes Using Discrete | |||

2005. Available via: | Logarithm Cryptography (Revised). March 2007. | |||

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

[PKCS1] Jonsson, J. and B. Kaliski. PKCS #1: RSA | [PKCS1] Jonsson, J. and B. Kaliski, "Public-Key | |||

Cryptography Specifications Version 2.1. RFC 3447. | Cryptography Standards (PKCS) #1: RSA Cryptography | |||

February 2003. | Specifications Version 2.1", RFC 3447, February | |||

2003. | ||||

[RANDOM] Eastlake, D., S. Crocker, and J. Schiller. | [RANDOM] Eastlake 3rd, D., Schiller, J., and S. Crocker, | |||

Randomness Recommendations for Security. RFC 4086. | "Randomness Requirements for Security", BCP 106, | |||

June 2005. | RFC 4086, June 2005. | |||

[SHOUP] Shoup, V. A Proposal for an ISO Standard for | [SHOUP] Shoup, V. A Proposal for an ISO Standard for | |||

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

2001. Available via http://www.shoup.net/papers/. | 2001. http://eprint.iacr.org/2001/112. | |||

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

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

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

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

With this type of algorithm, a sender encrypts the keying data using | With this type of algorithm, a sender encrypts the keying data using | |||

the recipient's public key to obtain encrypted keying data. The | the recipient's public key to obtain encrypted keying data. The | |||

recipient decrypts the encrypted keying data using the recipient's | recipient decrypts the encrypted keying data using the recipient's | |||

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

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

The algorithm has the following underlying components: | The algorithm has the following underlying components: | |||

o KDF, a key derivation function, which derives keying data of a | o KDF, a key derivation function, which derives keying data of a | |||

specified length from a shared secret value; | specified length from a shared secret value; | |||

o Wrap, a symmetric key-wrapping scheme, which encrypts keying | o Wrap, a symmetric key-wrapping scheme, which encrypts keying Data | |||

Data using a key-encrypting key. | using a key-encrypting key. | |||

In the following, kekLen denotes the length in bytes of the key- | In the following, kekLen denotes the length in bytes of the key- | |||

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

In this scheme, the length of the keying data to be transported MUST | In this scheme, the length of the keying data to be transported MUST | |||

be among the lengths supported by the underlying symmetric key- | be among the lengths supported by the underlying symmetric key- | |||

wrapping scheme. (Both the AES and Camellia Key Wraps, for instance, | wrapping scheme. (Both the AES and Camellia Key Wraps, for instance, | |||

require the length of the keying data to be a multiple of 8 bytes, | require the length of the keying data to be a multiple of 8 bytes, | |||

and at least 16 bytes.) Usage and formatting of the keying data | and at least 16 bytes.) Usage and formatting of the keying data | |||

(e.g., parity adjustment for Triple-DES keys) is outside the scope of | (e.g., parity adjustment for Triple-DES keys) is outside the scope of | |||

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

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

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

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

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

directly supported by CMS. | directly supported by CMS. | |||

A.2. Sender's Operations | A.2. Sender's Operations | |||

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

and let K be the keying data to be transported. | details), and let K be the keying data to be transported. | |||

Let nLen denote the length in bytes of the modulus n, i.e., the least | Let nLen denote the length in bytes of the modulus n, i.e., the least | |||

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

The sender performs the following operations: | The sender performs the following operations: | |||

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

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

first: | first: | |||

z = RandomInteger (0, n-1) | z = RandomInteger (0, n-1) | |||

Z = IntegerToString (z, nLen) | Z = IntegerToString (z, nLen) | |||

2. Encrypt the random integer z using the recipient's public key | 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 | (n,e), and convert the resulting integer c to a ciphertext C, a | |||

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

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

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

3. Derive a key-encrypting key KEK of length kekLen bytes from the | 3. Derive a key-encrypting key KEK of length kekLen bytes from the | |||

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

KEK = KDF (Z, kekLen) | KEK = KDF (Z, kekLen) | |||

4. Wrap the keying data K with the key-encrypting key KEK using the | 4. Wrap the keying data K with the key-encrypting key KEK using the | |||

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

WK = Wrap (KEK, K) | WK = Wrap (KEK, K) | |||

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

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

EK = C || WK | EK = C || WK | |||

6. Output the encrypted keying data EK. | 6. Output the encrypted keying data EK. | |||

NOTE: The random integer z MUST be generated independently at random | NOTE: The random integer z MUST be generated independently at random | |||

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

different recipients. | different recipients. | |||

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

Let (n,d) be the recipient's RSA private key (see [PKCS1]; other | 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 | private key formats are allowed), and let EK be the encrypted keying | |||

data. | data. | |||

Let nLen denote the length in bytes of the modulus n. | Let nLen denote the length in bytes of the modulus n. | |||

The recipient performs the following operations: | The recipient performs the following operations: | |||

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

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

C || WK = EK | C || WK = EK | |||

If the length of the encrypted keying data is less than nLen | If the length of the encrypted keying data is less than nLen | |||

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

2. Convert the ciphertext C to an integer c, most significant byte | 2. Convert the ciphertext C to an integer c, most significant byte | |||

first. Decrypt the integer c using the recipient's private key | first. Decrypt the integer c using the recipient's private key | |||

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

c = StringToInteger (C) | c = StringToInteger (C) | |||

z = c^d mod n | z = c^d mod n | |||

If the integer c is not between 0 and n-1, output "decryption | If the integer c is not between 0 and n-1, output "decryption | |||

error" and stop. | error", and stop. | |||

3. Convert the integer z to a byte string Z of length nLen, most | 3. Convert the integer z to a byte string Z of length nLen, most | |||

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

Z = IntegerToString (z, nLen) | Z = IntegerToString (z, nLen) | |||

4. Derive a key-encrypting key KEK of length kekLen bytes from the | 4. Derive a key-encrypting key KEK of length kekLen bytes from the | |||

byte string Z using the underlying key derivation function (see | byte string Z using the underlying key derivation function (see | |||

Note): | note): | |||

KEK = KDF (Z, kekLen) | KEK = KDF (Z, kekLen) | |||

5. Unwrap the wrapped keying data WK with the key-encrypting key KEK | 5. Unwrap the wrapped keying data WK with the key-encrypting key KEK | |||

using the underlying key-wrapping scheme to recover the keying | using the underlying key-wrapping scheme to recover the keying | |||

data K: | data K: | |||

K = Unwrap (KEK, WK) | K = Unwrap (KEK, WK) | |||

If the unwrapping operation outputs an error, output "decryption | If the unwrapping operation outputs an error, output "decryption | |||

error" and stop. | error", and stop. | |||

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

NOTE: Implementations SHOULD NOT reveal information about the integer | NOTE: Implementations SHOULD NOT reveal information about the | |||

z and the string Z, nor about the calculation of the exponentiation | integer z and the string Z, nor about the calculation of the | |||

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

whether by timing or other "side channels". The observable behavior | derivation in Step 4, whether by timing or other "side channels". | |||

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

ciphertexts C that are in range. (For example, IntegerToString | these steps for all ciphertexts C that are in range. (For example, | |||

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

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

intermediate results MUST be securely deleted when they are no longer | string Z, and other intermediate results MUST be securely deleted | |||

needed. | when they are no longer needed. | |||

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

The ASN.1 syntax for identifying the RSA-KEM Key Transport Algorithm | The ASN.1 syntax for identifying the RSA-KEM Key Transport Algorithm | |||

is an extension of the syntax for the "generic hybrid cipher" in ANS | is an extension of the syntax for the "generic hybrid cipher" in | |||

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

The syntax for selected underlying components including those | Appendix B.1. The syntax for selected underlying components | |||

mentioned above is given in B.2. | including those mentioned above is given in Appendix B.2. | |||

The following object identifier prefixes are used in the definitions | The following object identifier prefixes are used in the definitions | |||

below: | below: | |||

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

nistAlgorithm OID ::= { | nistAlgorithm OID ::= { | |||

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

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

} | } | |||

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

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

} | } | |||

x9-44 OID ::= { iso(1) identified-organization(3) tc68(133) | x9-44 OID ::= { iso(1) identified-organization(3) tc68(133) | |||

country(16) x9(840) x9Standards(9) x9-44(44) } | country(16) x9(840) x9Standards(9) x9-44(44) } | |||

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

NullParms is a more descriptive synonym for NULL when an algorithm | NullParms is a more descriptive synonym for NULL when an algorithm | |||

identifier has null parameters: | identifier has null parameters: | |||

NullParms ::= NULL | NullParms ::= NULL | |||

The material in this Appendix is based on ANS X9.44. | The material in this Appendix is based on ANS X9.44. | |||

B.1. RSA-KEM Key Transport Algorithm | B.1. RSA-KEM Key Transport Algorithm | |||

The object identifier for the RSA-KEM Key Transport Algorithm is id- | The object identifier for the RSA-KEM Key Transport Algorithm is | |||

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

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

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

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

} | } | |||

When id-rsa-kem is used in an AlgorithmIdentifier, the parameters | When id-rsa-kem is used in an AlgorithmIdentifier, the parameters | |||

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

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

GenericHybridParameters is as follows: | for GenericHybridParameters is as follows: | |||

GenericHybridParameters ::= { | GenericHybridParameters ::= { | |||

kem KeyEncapsulationMechanism, | kem KeyEncapsulationMechanism, | |||

dem DataEncapsulationMechanism | dem DataEncapsulationMechanism | |||

} | } | |||

The fields of type GenericHybridParameters have the following | The fields of type GenericHybridParameters have the following | |||

meanings: | meanings: | |||

o kem identifies the underlying key encapsulation mechanism, which | o kem identifies the underlying key encapsulation mechanism, | |||

in this case is also denoted as RSA-KEM. | which in this case is also denoted as RSA-KEM. | |||

The object identifier for RSA-KEM (as a key encapsulation | The object identifier for RSA-KEM (as a key encapsulation | |||

mechanism) is id-kem-rsa as: | mechanism) is id-kem-rsa as: | |||

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

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

} | } | |||

The associated parameters for id-kem-rsa have type | The associated parameters for id-kem-rsa have type | |||

RsaKemParameters: | RsaKemParameters: | |||

RsaKemParameters ::= { | RsaKemParameters ::= { | |||

keyDerivationFunction KeyDerivationFunction, | keyDerivationFunction KeyDerivationFunction, | |||

keyLength KeyLength | keyLength KeyLength | |||

} | } | |||

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

meanings: | ||||

* keyDerivationFunction identifies the underlying key derivation | * keyDerivationFunction identifies the underlying key | |||

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

However, other key derivation functions MAY be used with CMS. | be KDF2 or KDF3. However, other key derivation functions | |||

Please see B.2.1 for the syntax for KDF2 and KDF3. | MAY be used with CMS. Please see Appendix B.2.1 for the | |||

syntax for KDF2 and KDF3. | ||||

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

AlgorithmIdentifier {{KDFAlgorithms}} | ||||

KDFAlgorithms ALGORITHM ::= { | KDFAlgorithms ALGORITHM ::= { | |||

kdf2 | kdf3, | kdf2 | kdf3, | |||

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

} | } | |||

* keyLength is the length in bytes of the key-encrypting key, | * keyLength is the length in bytes of the key-encrypting key, | |||

which depends on the underlying symmetric key-wrapping scheme. | which depends on the underlying symmetric key-wrapping | |||

scheme. | ||||

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

o dem identifies the underlying data encapsulation mechanism. For | o dem identifies the underlying data encapsulation mechanism. | |||

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

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

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

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

Wraps. | ||||

DataEncapsulationMechanism ::= | DataEncapsulationMechanism ::= | |||

AlgorithmIdentifier {{DEMAlgorithms}} | AlgorithmIdentifier {{DEMAlgorithms}} | |||

DEMAlgorithms ALGORITHM ::= { | DEMAlgorithms ALGORITHM ::= { | |||

X9-SymmetricKeyWrappingSchemes, | X9-SymmetricKeyWrappingSchemes, | |||

Camellia-KeyWrappingSchemes, | Camellia-KeyWrappingSchemes, | |||

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

} | } | |||

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

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

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

} | } | |||

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

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

} | } | |||

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

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

The object identifier for KDF2 (see [ANS X9.44]) is: | The object identifier for KDF2 (see [ANS-X9.44]) is: | |||

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

The associated parameters identify the underlying hash function. For | The associated parameters identify the underlying hash function. For | |||

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

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

with CMS. | with CMS. | |||

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

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

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

X9-HashFunctions, | X9-HashFunctions, | |||

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

} | } | |||

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

sha1 | sha224 | sha256 | sha384 | sha512, | X9-HashFunctions ALGORITHM ::= { | |||

... -- allows for future expansion | sha1 | sha224 | sha256 | sha384 | sha512, | |||

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

} | ||||

The object identifier for SHA-1 is: | The object identifier for SHA-1 is: | |||

id-sha1 OID ::= { | id-sha1 OID ::= { | |||

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

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

} | } | |||

The object identifiers for SHA-224, SHA-256, SHA-384 and SHA-512 are | The object identifiers for SHA-224, SHA-256, SHA-384, and SHA-512 are | |||

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

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

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

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

There has been some confusion over whether the various SHA object | There has been some confusion over whether the various SHA object | |||

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

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

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

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

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

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

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

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

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

The object identifier for KDF3 (see [ANS X9.44]) is: | The object identifier for KDF3 (see [ANS-X9.44]) is: | |||

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

The associated parameters identify the underlying hash function. For | The associated parameters identify the underlying hash function. For | |||

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

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

with CMS. | with CMS. | |||

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

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

KDF3-HashFunctions ALGORITHM ::= { | KDF3-HashFunctions ALGORITHM ::= { | |||

X9-HashFunctions, | X9-HashFunctions, | |||

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

} | } | |||

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

The object identifiers for the AES Key Wrap depends on the size of | The object identifiers for the AES Key Wrap depend on the size of the | |||

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

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

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

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

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

These object identifiers have no associated parameters. | These object identifiers have no associated parameters. | |||

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

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

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

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

is: | [3DES-WRAP]) is: | |||

id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { | id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { | |||

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

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

} | } | |||

This object identifier has a NULL parameter. | This object identifier has a NULL parameter. | |||

tdes-Wrap ALGORITHM ::= | tdes-Wrap ALGORITHM ::= | |||

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

NOTE: ASC X9 has not yet incorporated AES Key Wrap with Padding [AES- | NOTE: ASC X9 has not yet incorporated AES Key Wrap with Padding | |||

WRAP-PAD] in to ANS X9.44. When ASC X9.44 adds AES Key Wrap with | [AES-WRAP-PAD] into ANS X9.44. When ASC X9.44 adds AES Key Wrap with | |||

Padding, this document will also be updated. | Padding, this document will also be updated. | |||

The object identifiers for the Camellia Key Wrap depend on the size | The object identifiers for the Camellia Key Wrap depend on the size | |||

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

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

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

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

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

id-camellia192-Wrap OBJECT IDENTIFIER ::= | id-camellia192-Wrap OBJECT IDENTIFIER ::= | |||

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

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

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

id-camellia256-Wrap OBJECT IDENTIFIER ::= | id-camellia256-Wrap OBJECT IDENTIFIER ::= | |||

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

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

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

These object identifiers have no associated parameters. | These object identifiers have no associated parameters. | |||

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

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

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

B.3. ASN.1 module | B.3. ASN.1 Module | |||

CMS-RSA-KEM | CMS-RSA-KEM | |||

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

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

DEFINITIONS ::= | DEFINITIONS ::= | |||

BEGIN | BEGIN | |||

-- EXPORTS ALL | -- EXPORTS ALL | |||

-- IMPORTS None | -- IMPORTS None | |||

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

skipping to change at page 20, line 36 | skipping to change at page 21, line 4 | |||

DEFINITIONS ::= | DEFINITIONS ::= | |||

BEGIN | BEGIN | |||

-- EXPORTS ALL | -- EXPORTS ALL | |||

-- IMPORTS None | -- IMPORTS None | |||

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

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

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

-- parameters (i.e., the PARMS element is specified), the | -- parameters (i.e., the PARMS element is specified), the | |||

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

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

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

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

ALGORITHM ::= CLASS { | ALGORITHM ::= CLASS { | |||

&id OBJECT IDENTIFIER UNIQUE, | &id OBJECT IDENTIFIER UNIQUE, | |||

&Type OPTIONAL | &Type OPTIONAL | |||

} | } | |||

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

AlgorithmIdentifier { ALGORITHM:IOSet } ::= SEQUENCE { | AlgorithmIdentifier { ALGORITHM:IOSet } ::= SEQUENCE { | |||

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

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

} | } | |||

NullParms ::= NULL | NullParms ::= NULL | |||

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

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

-- NIST algorithm arc | -- NIST algorithm arc | |||

nistAlgorithm OID ::= { | nistAlgorithm OID ::= { | |||

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

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

} | } | |||

-- PKCS #1 arc | -- PKCS #1 arc | |||

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

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

} | } | |||

-- RSA-KEM Key Transport Algorithm | -- RSA-KEM Key Transport Algorithm | |||

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

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

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

} | } | |||

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

kem KeyEncapsulationMechanism, | kem KeyEncapsulationMechanism, | |||

dem DataEncapsulationMechanism | dem DataEncapsulationMechanism | |||

} | } | |||

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

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

kem-rsa ALGORITHM ::= { OID id-kem-rsa PARMS RsaKemParameters } | kem-rsa ALGORITHM ::= { OID id-kem-rsa PARMS RsaKemParameters } | |||

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

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

} | } | |||

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

keyDerivationFunction KeyDerivationFunction, | keyDerivationFunction KeyDerivationFunction, | |||

keyLength KeyLength | keyLength KeyLength | |||

} | } | |||

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

KDFAlgorithms ALGORITHM ::= { | KDFAlgorithms ALGORITHM ::= { | |||

kdf2 | kdf3, | kdf2 | kdf3, | |||

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

} | } | |||

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

DataEncapsulationMechanism ::= AlgorithmIdentifier {{DEMAlgorithms}} | DataEncapsulationMechanism ::= AlgorithmIdentifier {{DEMAlgorithms}} | |||

DEMAlgorithms ALGORITHM ::= { | DEMAlgorithms ALGORITHM ::= { | |||

X9-SymmetricKeyWrappingSchemes | | X9-SymmetricKeyWrappingSchemes | | |||

Camellia-KeyWrappingSchemes, | Camellia-KeyWrappingSchemes, | |||

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

} | } | |||

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

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

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

} | } | |||

X9-SymmetricKeyWrappingScheme ::= | X9-SymmetricKeyWrappingScheme ::= | |||

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

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

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

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

} | } | |||

Camellia-KeyWrappingScheme ::= | Camellia-KeyWrappingScheme ::= | |||

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

-- Key Derivation Functions | -- Key Derivation Functions | |||

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

-- Base arc | -- Base arc | |||

x9-44 OID ::= { | x9-44 OID ::= { | |||

iso(1) identified-organization(3) tc68(133) country(16) x9(840) | iso(1) identified-organization(3) tc68(133) country(16) x9(840) | |||

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

} | } | |||

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

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

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

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

X9-HashFunctions, | X9-HashFunctions, | |||

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

} | } | |||

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

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

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

KDF3-HashFunctions ALGORITHM ::= { | KDF3-HashFunctions ALGORITHM ::= { | |||

X9-HashFunctions, | X9-HashFunctions, | |||

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

} | } | |||

-- Hash Functions | -- Hash Functions | |||

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

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

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

} | } | |||

id-sha1 OID ::= { | id-sha1 OID ::= { | |||

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

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

} | } | |||

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

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

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

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

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

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

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

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

skipping to change at page 24, line 31 | skipping to change at page 24, line 42 | |||

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

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

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

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

id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { | id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { | |||

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

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

} | } | |||

tdes-Wrap ALGORITHM ::= { OID id-alg-CMS3DESwrap PARMS NullParms } | tdes-Wrap ALGORITHM ::= { OID id-alg-CMS3DESwrap PARMS NullParms } | |||

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

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

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

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

id-camellia192-Wrap OBJECT IDENTIFIER ::= | id-camellia192-Wrap OBJECT IDENTIFIER ::= | |||

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

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

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

id-camellia256-Wrap OBJECT IDENTIFIER ::= | id-camellia256-Wrap OBJECT IDENTIFIER ::= | |||

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

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

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

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

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

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

END | END | |||

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

As an example, if the key derivation function is KDF3 based on SHA- | As an example, if the key derivation function is KDF3 based on | |||

256 and the symmetric key-wrapping scheme is the AES Key Wrap with a | SHA-256 and the symmetric key-wrapping scheme is the AES Key Wrap | |||

128-bit KEK, the AlgorithmIdentifier for the RSA-KEM Key Transport | with a 128-bit KEK, the AlgorithmIdentifier for the RSA-KEM Key | |||

Algorithm will have the following value: | Transport Algorithm will have the following value: | |||

SEQUENCE { | SEQUENCE { | |||

id-rsa-kem, -- RSA-KEM cipher | id-rsa-kem, -- RSA-KEM cipher | |||

SEQUENCE { -- GenericHybridParameters | SEQUENCE { -- GenericHybridParameters | |||

SEQUENCE { -- key encapsulation mechanism | SEQUENCE { -- key encapsulation mechanism | |||

id-kem-rsa, -- RSA-KEM | id-kem-rsa, -- RSA-KEM | |||

SEQUENCE { -- RsaKemParameters | SEQUENCE { -- RsaKemParameters | |||

SEQUENCE { -- key derivation function | SEQUENCE { -- key derivation function | |||

id-kdf-kdf3, -- KDF3 | id-kdf-kdf3, -- KDF3 | |||

SEQUENCE { -- KDF3-HashFunction | SEQUENCE { -- KDF3-HashFunction | |||

id-sha256 -- SHA-256; no parameters (preferred) | id-sha256 -- SHA-256; no parameters (preferred) | |||

}, | }, | |||

16 -- KEK length in bytes | 16 -- KEK length in bytes | |||

}, | }, | |||

SEQUENCE { -- data encapsulation mechanism | SEQUENCE { -- data encapsulation mechanism | |||

id-aes128-Wrap -- AES-128 Wrap; no parameters | id-aes128-Wrap -- AES-128 Wrap; no parameters | |||

} | } | |||

} | } | |||

} | } | |||

This AlgorithmIdentifier value has the following DER encoding: | ||||

This AlgorithmIdentifier value has the following DER encoding (?? | ||||

indicates the algorithm number which is to be assigned): | ||||

30 47 | 30 47 | |||

06 0b 2a 86 48 86 f7 0d 01 09 10 03 0e -- id-rsa-kem | 06 0b 2a 86 48 86 f7 0d 01 09 10 03 0e -- id-rsa-kem | |||

30 38 | 30 38 | |||

30 29 | 30 29 | |||

06 07 28 81 8c 71 02 02 04 -- id-kem-rsa | 06 07 28 81 8c 71 02 02 04 -- id-kem-rsa | |||

30 1e | 30 1e | |||

30 19 | 30 19 | |||

06 0a 2b 81 05 10 86 48 09 2c 01 02 -- id-kdf-kdf3 | 06 0a 2b 81 05 10 86 48 09 2c 01 02 -- id-kdf-kdf3 | |||

30 0b | 30 0b | |||

06 09 60 86 48 01 65 03 04 02 01 -- id-sha256 | 06 09 60 86 48 01 65 03 04 02 01 -- id-sha256 | |||

02 01 10 -- 16 bytes | 02 01 10 -- 16 bytes | |||

30 0b | 30 0b | |||

06 09 60 86 48 01 65 03 04 01 05 -- id-aes128-Wrap | 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 | The DER encodings for other typical sets of underlying components are | |||

as follows: | as follows: | |||

o KDF3 based on SHA-384, AES Key Wrap with a 192-bit KEK | o KDF3 based on SHA-384, AES Key Wrap with a 192-bit KEK | |||

30 47 06 0b 2a 86 48 86 f7 0d 01 09 10 03 0e 30 | 30 47 06 0b 2a 86 48 86 f7 0d 01 09 10 03 0e 30 | |||

38 30 29 06 07 28 81 8c 71 02 02 04 30 1e 30 19 | 38 30 29 06 07 28 81 8c 71 02 02 04 30 1e 30 19 | |||

06 0a 2b 81 05 10 86 48 09 2c 01 02 30 0b 06 09 | 06 0a 2b 81 05 10 86 48 09 2c 01 02 30 0b 06 09 | |||

60 86 48 01 65 03 04 02 02 02 01 18 30 0b 06 09 | 60 86 48 01 65 03 04 02 02 02 01 18 30 0b 06 09 | |||

60 86 48 01 65 03 04 01 19 | 60 86 48 01 65 03 04 01 19 | |||

o KDF3 based on SHA-512, AES Key Wrap with a 256-bit KEK | o KDF3 based on SHA-512, AES Key Wrap with a 256-bit KEK | |||

30 47 06 0b 2a 86 48 86 f7 0d 01 09 10 03 0e 30 | 30 47 06 0b 2a 86 48 86 f7 0d 01 09 10 03 0e 30 | |||

38 30 29 06 07 28 81 8c 71 02 02 04 30 1e 30 19 | 38 30 29 06 07 28 81 8c 71 02 02 04 30 1e 30 19 | |||

06 0a 2b 81 05 10 86 48 09 2c 01 02 30 0b 06 09 | 06 0a 2b 81 05 10 86 48 09 2c 01 02 30 0b 06 09 | |||

60 86 48 01 65 03 04 02 03 02 01 20 30 0b 06 09 | 60 86 48 01 65 03 04 02 03 02 01 20 30 0b 06 09 | |||

60 86 48 01 65 03 04 01 2d | 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- | o KDF2 based on SHA-1, Triple-DES Key Wrap with a 128-bit KEK (two- | |||

key triple-DES) | key Triple-DES) | |||

30 45 06 0b 2a 86 48 86 f7 0d 01 09 10 03 0e 30 | 30 45 06 0b 2a 86 48 86 f7 0d 01 09 10 03 0e 30 | |||

36 30 25 06 07 28 81 8c 71 02 02 04 30 1a 30 15 | 36 30 25 06 07 28 81 8c 71 02 02 04 30 1a 30 15 | |||

06 0a 2b 81 05 10 86 48 09 2c 01 01 30 07 06 05 | 06 0a 2b 81 05 10 86 48 09 2c 01 01 30 07 06 05 | |||

2b 0e 03 02 1a 02 01 10 30 0d 06 0b 2a 86 48 86 | 2b 0e 03 02 1a 02 01 10 30 0d 06 0b 2a 86 48 86 | |||

f7 0d 01 09 10 03 06 | f7 0d 01 09 10 03 06 | |||

Authors' Addresses | Authors' Addresses | |||

James Randall | James Randall | |||

Randall Consulting | Randall Consulting | |||

55 Sandpiper Drive | 55 Sandpiper Drive | |||

Dover, NH 03820 | Dover, NH 03820 | |||

USA | USA | |||

Email: jdrandall@comcast.net | EMail: jdrandall@comcast.net | |||

Burt Kaliski | Burt Kaliski | |||

EMC | EMC | |||

176 South Street | 176 South Street | |||

Hopkinton, MA 01748 | Hopkinton, MA 01748 | |||

USA | USA | |||

Email: kaliski_burt@emc.com | EMail: burt.kaliski@emc.com | |||

John Brainard | John Brainard | |||

RSA, The Security Division of EMC | RSA, The Security Division of EMC | |||

174 Middlesex Turnpike | 174 Middlesex Turnpike | |||

Bedford, MA 01730 | Bedford, MA 01730 | |||

USA | USA | |||

Email: jbrainard@rsa.com | EMail: jbrainard@rsa.com | |||

Sean Turner | Sean Turner | |||

IECA, Inc. | IECA, Inc. | |||

3057 Nutley Street, Suite 106 | 3057 Nutley Street, Suite 106 | |||

Fairfax, VA 22031 | Fairfax, VA 22031 | |||

USA | USA | |||

Email: turners@ieca.com | EMail: turners@ieca.com | |||

End of changes. 238 change blocks. | ||||

539 lines changed or deleted | | 539 lines changed or added | ||

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