draft-ietf-smime-cms-rsa-kem-00.txt | draft-ietf-smime-cms-rsa-kem-01.txt | |||
---|---|---|---|---|

S/MIME Working Group B. Kaliski | S/MIME Working Group B. Kaliski | |||

Internet Draft RSA Laboratories | Internet Draft RSA Laboratories | |||

Document: draft-ietf-smime-cms-rsa-kem-00.txt May 2003 | Document: draft-ietf-smime-cms-rsa-kem-01.txt October 2003 | |||

Category: Standards | Category: Standards | |||

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

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

Status of this Memo | Status of this Memo | |||

This document is an Internet-Draft and is subject to all provisions | This document is an Internet-Draft and is subject to all provisions | |||

of Section 10 of RFC2026. | of Section 10 of RFC2026. | |||

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

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

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

Drafts. | Drafts. | |||

skipping to change at page 1, line 37 | skipping to change at page 1, line 37 | |||

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

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

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

Comments or suggestions for improvement may be made on the "ietf- | Comments or suggestions for improvement may be made on the "ietf- | |||

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

Abstract | Abstract | |||

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

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

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

conventions for using the RSA-KEM Key Transport Algorithm with the | for using the RSA-KEM Key Transport Algorithm with the Cryptographic | |||

Cryptographic Message Syntax (CMS). | Message Syntax (CMS). This version (-01) updates the ASN.1 syntax to | |||

align with the latest drafts of ANS X9.44 and ISO/IEC 18033-2, and | ||||

adds material on certificate conventions and S/MIME capabilities. | ||||

Conventions Used in This Document | Conventions Used in This Document | |||

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

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

this document are to be interpreted as described in RFC 2119 | this document are to be interpreted as described in RFC 2119 | |||

[STDWORDS]. | [STDWORDS]. | |||

1. Introduction | 1. Introduction | |||

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

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

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 | 4. Wrap the keying data using KEK to obtain wrapped keying data | |||

KD. | WK. | |||

5. Output c and KD 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 | |||

the input to the underlying RSA operation is random and independent | the input to the underlying RSA operation is random and independent | |||

of the message, and the key-encrypting key KEK is derived from it in | of the message, and the key-encrypting key KEK is derived from it in | |||

a strong way. As a result, the algorithm enjoys a "tight" security | a strong way. As a result, the algorithm enjoys a "tight" security | |||

proof in the random oracle model. It is also architecturally | proof in the random oracle model. It is also architecturally | |||

convenient because the public-key operations are separate from the | convenient because the public-key operations are separate from the | |||

symmetric operations on the keying data. One benefit is that the | symmetric operations on the keying data. One benefit is that the | |||

length of the keying data is bounded only by the symmetric key | length of the keying data is bounded only by the symmetric key- | |||

wrapping scheme, not the size of the RSA modulus. | wrapping scheme, not the size of the RSA modulus. | |||

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

adopted in several draft standards including ANSI X9.44 [ANSI-X9.44] | in several draft standards including the draft ANS X9.44 [ANS-X9.44] | |||

and ISO/IEC 18033-2 [ISO-IEC-18033-2]. It has also been recommended | and the draft ISO/IEC 18033-2 [ISO-IEC-18033-2]. It has also been | |||

by the NESSIE project [NESSIE]. Although the other standards are | recommended by the NESSIE project [NESSIE]. Although the other | |||

still in development, the algorithm is fairly stable across the | standards are still in development, the algorithm is stable across | |||

drafts. For completeness, a specification of the algorithm is given | the drafts. For completeness, a specification of the algorithm is | |||

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

Appendix B. | ||||

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

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

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

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

mechanisms is a result of research by Victor Shoup leading to the | mechanisms is described further in research by Victor Shoup leading | |||

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

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

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

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

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

skipping to change at page 3, line 35 | skipping to change at page 3, line 35 | |||

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

OAEP]). RSA-KEM has the advantage over RSAES-OAEP of a tighter | OAEP]). RSA-KEM has the advantage over RSAES-OAEP of a tighter | |||

security proof, but the disadvantage of slightly longer encrypted | security proof, but the disadvantage of slightly longer encrypted | |||

keying data. | keying data. | |||

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

* For the key derivation function, KDF2 (see [ANSI-X9.44][IEEE- | * For the key derivation function, KDF2 (see [ANS-X9.44][IEEE- | |||

P1363a]) based on SHA-1 (see [NIST-SHA2]) (this function is | P1363a]) based on SHA-1 (see [FIPS-180-2]) (this function is | |||

also specified as the key derivation function in [ANSI-X9.63]) | also specified as the key derivation function in [ANS-X9.63]) | |||

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

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

An implementation SHOULD also support KDF2 based on SHA-256 (see | An implementation SHOULD also support KDF2 based on SHA-256 (see | |||

[NIST-SHA2]), and the Triple-DES Key Wrap (see [3DES-WRAP]). It MAY | [FIPS-180-2]), and the Triple-DES Key Wrap (see [3DES-WRAP]). It MAY | |||

support other underlying components. | support other underlying components. | |||

2.2 RecipientInfo Conventions | 2.2 RecipientInfo Conventions | |||

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

recipient, the RecipientInfo alternative for that recipient MUST be | recipient, 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: | |||

* keyEncryptionAlgorithm.algorithm MUST be id-kts2-basic (see | * keyEncryptionAlgorithm.algorithm MUST be id-ac-generic-hybrid | |||

Appendix B) | (see Appendix B) | |||

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

KTS2-Parms (see Appendix B) | GenericHybridParameters, identifying the RSA-KEM key | |||

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

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

algorithm (see Appendix A) | algorithm (see Appendix A) | |||

2.3 Certificate Conventions | 2.3 Certificate Conventions | |||

The conventions specified in this section augment RFC 3280 [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 rsaEncryption object identifier [PKCS1]. | |||

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-kts2-basic object | public key in the certificate using the id-ac-generic-hybrid object | |||

identifier (see Appendix B) where the KTS2-Params value indicates | identifier (see Appendix B) where the associated | |||

the underlying components with which the algorithm is to be | GenericHybridParameters value indicates the underlying components | |||

employed. | with which the algorithm is to be employed. The certificate user MUST | |||

perform the RSA-KEM Key Transport algorithm using only those | ||||

components. | ||||

[[matching rules to be added]] | Regardless of the AlgorithmIdentifier used, the RSA public key is | |||

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

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

RSAPublicKey ::= SEQUENCE { | ||||

modulus INTEGER, -- n | ||||

publicExponent INTEGER -- e | ||||

} | ||||

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

exponent e. The DER encoded RSAPublicKey is carried in the | ||||

subjectPublicKey BIT STRING within the subject public key | ||||

information. | ||||

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

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

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

public key with the id-ac-generic-hybrid object identifier as | ||||

discussed above, then the key usage extension MUST contain the | ||||

following value: | ||||

keyEncipherment. | ||||

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

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

also be employed for data encryption. | ||||

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

[[to be added]] | RFC 2633 [MSG], Section 2.5.2 defines the SMIMECapabilities signed | |||

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

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

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

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

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

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

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

Algorithm MUST include the id-ac-generic-hybrid object identifier | ||||

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

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

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

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

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

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

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

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

this document has been shown to be tightly related to the difficulty | this document can be shown to be tightly related to the difficulty | |||

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

symmetric key wrapping scheme, if the underlying key derivation | symmetric key-wrapping scheme, if the underlying key derivation | |||

function is modeled as a random oracle [SHOUP]. While in practice a | function is modeled as a random oracle, and assuming that the | |||

random-oracle result does not provide an actual security proof for | symmetric key-wrapping scheme satisfies the properties of a data | |||

any particular key derivation function, the result does provide | encapsulation mechanism [SHOUP]. While in practice a random-oracle | |||

assurance that the general construction is reasonable; a key | result does not provide an actual security proof for any particular | |||

derivation function would need to be particularly weak to lead to an | key derivation function, the result does provide assurance that the | |||

attack that is not possible in the random oracle model. | general construction is reasonable; a key derivation function would | |||

need to be particularly weak to lead to an attack that is not | ||||

possible in the random oracle model. | ||||

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

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

application. Several security levels have been identified in [NIST- | application. Several security levels have been identified in [NIST- | |||

GUIDELINES]. For brevity, the first three levels are mentioned here: | GUIDELINE]. For brevity, the first three levels are mentioned here: | |||

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

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

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

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

* 112-bit security. The RSA key size SHOULD be at least 2048 | * 112-bit security. The RSA key size SHOULD be at least 2048 | |||

bits, the hash function underlying KDF2 SHOULD be SHA-224 or | bits, the hash function underlying KDF2 SHOULD be SHA-224 or | |||

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

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

* 128-bit security. The RSA key size SHOULD be at least 3072 | * 128-bit security. The RSA key size SHOULD be at least 3072 | |||

bits, the hash function underlying KDF2 SHOULD be SHA-256 or | bits, the hash function underlying KDF2 SHOULD be SHA-256 or | |||

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

Wrap. | Wrap. | |||

Note that the AES Key Wrap MAY be used at all three of these levels; | Note that the AES Key Wrap MAY be used at all three of these levels; | |||

the use of AES does not require a 128-bit security level for other | the use of AES does not require a 128-bit security level for other | |||

components. | components. | |||

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

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

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

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

encrypted content. | ||||

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

[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 | level. For further discussion on random number generation, please | |||

see [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 it practical to, | preferable to conceal as much information as is practical, unless | |||

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

not be useful. | useful. | |||

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

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

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

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

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

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

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

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

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

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

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

ASC X9 requires such a separation between key establishment key pairs | ||||

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

separation, a key pair used for the RSA-KEM Key Transport Algorithm | ||||

SHOULD NOT be used with other key establishment schemes, or for data | ||||

encryption, or with more than one set of underlying algorithm | ||||

components. | ||||

Parties MAY wish to formalize the assurance that one another's | Parties MAY wish to 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. References | 4. References | |||

4.1 Normative References | 4.1 Normative References | |||

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

3217. December 2001. | 3217. December 2001. | |||

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

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

September 2002. | September 2002. | |||

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

CMS Housley, R. Cryptographic Message Syntax. RFC | CMS Housley, R. Cryptographic Message Syntax. RFC | |||

3369. August 2002. | 3369. August 2002. | |||

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

Algorithms. RFC 3370. August 2002. | Algorithms. RFC 3370. August 2002. | |||

NIST-SHA2 National Institute of Standards and Technology | FIPS-180-2 National Institute of Standards and Technology | |||

(NIST). FIPS 180-2: Secure Hash Standard. August | (NIST). FIPS 180-2: Secure Hash Standard. August | |||

2002. | 2002. | |||

MSG Ramsdell, B. S/MIME Version 3 Message | ||||

Specification. RFC 2633. June 1999. | ||||

PROFILE Housley, R., Polk, W., Ford, W. and D. Solo. | ||||

Internet X.509 Public Key Infrastructure: | ||||

Certificate and Certificate Revocation List (CRL) | ||||

Profile. RFC 3280. April 2002. | ||||

STDWORDS Bradner, S. Key Words for Use in RFCs to Indicate | STDWORDS Bradner, S. Key Words for Use in RFCs to Indicate | |||

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

4.2 Informative References | 4.2 Informative References | |||

ANSI-X9.44 ANSI X9F1 Working Group. ANSI X9.44: Public Key | ANS-X9.44 ASC X9F1 Working Group. Draft American National | |||

Cryptography for the Financial Services Industry - | Standard X9.44: Public Key Cryptography for the | |||

- Key Establishment Using Integer Factorization | Financial Services Industry -- Key Establishment | |||

Cryptography. Draft D4.1, April 1, 2003. | Using Integer Factorization Cryptography. Draft D6, | |||

October 15, 2003. | ||||

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

Algorithm in CMS. Internet Draft <draft-ietf- | Algorithm in the Cryptographic Message Syntax | |||

smime-cms-rsaes-oaep-07.txt>. December 2002. | (CMS). RFC 3560. July 2003. | |||

IEEE-P1363a IEEE P1363 Working Group. IEEE P1363a: Standard | IEEE-P1363a IEEE P1363 Working Group. IEEE P1363a: Standard | |||

Specifications for Public Key Cryptography: | Specifications for Public Key Cryptography: | |||

Additional Techniques. Draft D12, May 12, 2003. | Additional Techniques. Draft D12, May 12, 2003. | |||

Available via http://grouper.ieee.org/groups/1363. | Available via http://grouper.ieee.org/groups/1363. | |||

ISO-IEC-18033-2 ISO/IEC 18033-2: Information technology -- | ISO-IEC-18033-2 ISO/IEC 18033-2: Information technology -- Security | |||

Security techniques -- Encryption algorithms -- | techniques -- Encryption algorithms – Part 2: | |||

Part 2: Asymmetric Ciphers. Committee Draft, | Asymmetric Ciphers. 2nd Committee Draft, July 10, | |||

December 18, 2002. | 2003. | |||

NESSIE NESSIE Consortium. Portfolio of Recommended | NESSIE NESSIE Consortium. Portfolio of Recommended | |||

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

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

NIST-GUIDELINES National Institute of Standards and Technology. | NIST-GUIDELINE National Institute of Standards and Technology. | |||

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

Management. Part 1: General Guideline. Draft, | Management. Part 1: General Guideline. Draft, | |||

January 2003. Available via | January 2003. Available via | |||

http://csrc.nist.gov/CryptoToolkit/tkkeymgmt.html. | http://csrc.nist.gov/CryptoToolkit/tkkeymgmt.html. | |||

NIST-SCHEMES National Institute of Standards and Technology. | ||||

Special Publication 800-56: Recommendation on Key | ||||

Establishment Schemes. Draft 2.0, January 2003. | ||||

Available via | ||||

http://csrc.nist.gov/CryptoToolkit/tkkeymgmt.html. | ||||

PKCS1 Jonsson, J. and B. Kaliski. PKCS #1: RSA | PKCS1 Jonsson, J. and B. Kaliski. PKCS #1: RSA | |||

Cryptography Specifications Version 2.1. RFC 3447. | Cryptography Specifications Version 2.1. RFC 3447. | |||

February 2003. | February 2003. | |||

RANDOM Eastlake, D., S. Crocker, and J. Schiller. | RANDOM Eastlake, D., S. Crocker, and J. Schiller. | |||

Randomness Recommendations for Security. RFC 1750. | Randomness Recommendations for Security. RFC 1750. | |||

December 1994. | December 1994. | |||

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

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. Available via http://www.shoup.net/papers/. | |||

5. IANA Considerations | 5. IANA Considerations | |||

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

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

Public-Key Cryptography Standards (PKCS) documents, Accredited | were assigned in other IETF documents, in ISO/IEC standards | |||

Standards Committee (ASC) X9 documents, or by the National Institute | documents, by the National Institute of Standards and Technology | |||

of Standards and Technology (NIST). No further action by the IANA is | (NIST), and in Public-Key Cryptography Standards (PKCS) documents. | |||

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

B.3) is assigned in this document. No further action by the IANA is | ||||

necessary for this document or any anticipated updates. | necessary for this document or any anticipated updates. | |||

6. Acknowledgments | 6. Acknowledgments | |||

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. I would | produced by ASC X9, ISO/IEC JTC1 SC27, NIST, and the IETF. I would | |||

like to thank the members of the ANSI X9F1 working group for their | like to thank the members of the ASC X9F1 working group for their | |||

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

specification. My thanks as well to Russ Housley as well for his | My thanks as well to Russ Housley as well for his guidance and | |||

guidance and encouragement. | encouragement. I also appreciate the helpful direction I've received | |||

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

fruition. | ||||

7. Author Address | 7. Author's Address | |||

Burt Kaliski | Burt Kaliski | |||

RSA Laboratories | RSA Laboratories | |||

174 Middlesex Turnpike | 174 Middlesex Turnpike | |||

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

USA | USA | |||

bkaliski@rsasecurity.com | bkaliski@rsasecurity.com | |||

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

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

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

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

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

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

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

data using a key-encrypting key | data using a key-encrypting key | |||

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

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

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

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

wrapping scheme. (The AES Key Wrap, for instance, requires the | wrapping scheme. (The AES Key Wrap, for instance, requires the length | |||

length of the keying data to be a multiple of 8 bytes, and at least | of the keying data to be a multiple of 8 bytes, and at least 16 | |||

16 bytes.) Usage and formatting of the keying data (e.g., parity | bytes.) Usage and formatting of the keying data (e.g., parity | |||

adjustment for Triple-DES keys) is outside the scope of this | adjustment for Triple-DES keys) is outside the scope of this | |||

algorithm. | algorithm. | |||

With some key derivation functions, it is possible to include other | With some key derivation functions, it is possible to include other | |||

information besides the shared secret value in the input to the | information besides the shared secret value in the input to the | |||

function. Also, with some symmetric key wrapping schemes, it is | function. Also, with some symmetric key-wrapping schemes, it is | |||

possible to associate a label with the keying data. Such uses are | possible to associate a label with the keying data. Such uses are | |||

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

supported by CMS. | 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 | Let (n,e) be the recipient's RSA public key (see [PKCS1] for details) | |||

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

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

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 | convert z to a byte string Z of length nLen, most significant | |||

byte first: | byte 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 | (n,e) and convert the resulting integer c to a ciphertext C, a | |||

byte 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 | 3. Derive a key-encrypting key KEK of length kekLen bytes from the | |||

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

function: | ||||

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

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

scheme with the key-encrypting key KEK to obtain wrapped | the underlying key-wrapping scheme to obtain wrapped keying | |||

keying data WK: | 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 | |||

skipping to change at page 9, line 49 | skipping to change at page 11, line 31 | |||

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 | 4. Derive a key-encrypting key KEK of length kekLen bytes from | |||

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

(see Note): | (see Note): | |||

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

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

wrapping scheme with the key-encrypting key KEK to recover the | KEK using the underlying key-wrapping scheme to recover the | |||

keying data K: | keying data K: | |||

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

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

"decryption error" and stop. | "decryption error" and stop. | |||

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

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

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

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

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

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

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

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

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

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

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

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

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

is a special case of the syntax for Key Transport Scheme 2 (KTS2) in | is an extension of the syntax for the "generic hybrid cipher" in the | |||

the draft ANSI X9.44 [ANSI-X9.44]. The syntax for the scheme is | draft ISO/IEC 18033-2 [ISO-IEC-18033-2], and is the same as employed | |||

in the draft ANS X9.44 [ANS-X9.44]. The syntax for the scheme is | ||||

given in Section B.1. The syntax for selected underlying components | given in Section B.1. The syntax for selected underlying components | |||

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

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

below: | below: | |||

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

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

x9(840) x9Standards(9) x9-44(44) | nistAlgorithm OID ::= { | |||

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

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

} | } | |||

nistAlgorithm OID ::= { | NullParms is a more descriptive synonym for NULL when an algorithm | |||

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

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

} | NullParms ::= NULL | |||

The material in this Appendix is based on a draft standard and is | The material in this Appendix is based on a draft standard and is | |||

SUBJECT TO CHANGE as that standard is developed. | SUBJECT TO CHANGE as that standard is developed. | |||

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

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

same as for the basic KTS2 scheme in the draft ANSI X9.44, id-kts2- | same as for the "generic hybrid cipher" in the draft ANS ISO/IEC | |||

basic, which is defined in the draft as | 18033-2, id-ac-generic-hybrid, which is defined in the draft as | |||

id-kts2-basic OID ::= { x9-44 schemes(2) kts2-basic(7) } | ||||

The associated parameters for id-kts2-basic have type KTS2-Parms: | ||||

KTS2-Parms ::= SEQUENCE { | id-ac-generic-hybrid OID ::= { | |||

kas [0] KTS2-KeyAgreementScheme, | is18033-2 asymmetric-cipher(1) generic-hybrid(2) | |||

kws [1] KTS2-SymmetricKeyWrappingScheme, | ||||

labelMethod [2] KTS2-LabelMethod | ||||

} | } | |||

The fields of type KTS2-Parms have the following meanings: | The associated parameters for id-ac-generic-hybrid have type | |||

GenericHybridParameters: | ||||

* kas identifies the underlying key agreement scheme. For the | ||||

RSA-KEM Key Transport Algorithm, the scheme is the basic Key | ||||

Agreement Scheme 1 (KAS1) from the draft ANSI X9.44. | ||||

The object identifier for the basic KAS1 is id-kas1-basic, | ||||

which is defined in the draft ANSI X9.44 as | ||||

id-kas1-basic OID ::= { x9-44 schemes(2) kas1-basic(1) } | ||||

The associated parameters for id-kas1-basic have type KAS1- | ||||

Parms: | ||||

KAS1-Parms ::= SEQUENCE { | GenericHybridParameters ::= { | |||

sves [0] KAS1-SecretValueEncapsulationScheme, | kem KeyEncapsulationMechanism, | |||

kdf [1] KAS1-KeyDerivationFunction, | dem DataEncapsulationMechanism | |||

otherInfoMethod [2] KAS1-OtherInfoMethod | ||||

} | } | |||

The fields of type KAS1-Parms have the following meanings: | The fields of type GenericHybridParameters have the following | |||

meanings: | ||||

* sves identifies the underlying secret-value | * kem identifies the underlying key encapsulation mechanism. For | |||

encapsulation mechanism. (In the draft ANSI X9.44, the | the RSA-KEM Key Transport Algorithm, the scheme is RSA-KEM from | |||

term "Secret Value Encapsulation Scheme" refers to the | the draft ISO/IEC 18033-2. | |||

first _two_ steps of the RSA-KEM Key Transport | ||||

Algorithm, which are separated from the key derivation | ||||

function for architectural reasons.) For the RSA-KEM Key | ||||

Transport Algorithm, the mechanism is RSASVES1 from the | ||||

draft ANSI X9.44. | ||||

The object identifier for RSASVES1 is id-rsasves1, which | The object identifier for RSA-KEM (as a key encapsulation | |||

is defined in the draft ANSI X9.44 as | mechanism) is id-kem-rsa, which is defined in the draft ISO/IEC | |||

18033-2 as | ||||

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

x9-44 components(1) rsasves1(2) | is18033-2 key-encapsulation-mechanism(2) rsa(4) | |||

} | } | |||

This object identifier has no associated parameters. | The associated parameters for id-kem-rsa have type | |||

RsaKemParameters: | ||||

* kdf identifies the underlying key derivation function. | ||||

For alignment with the draft ANSI X9.44, it MUST be | ||||

KDF2. However, other key derivation functions MAY be | ||||

used with CMS. Please see B.2.1 for the syntax for KDF2. | ||||

KAS1-KeyDerivationFunction ::= AlgorithmIdentifier | ||||

* otherInfoMethod specifies the method for formatting | RsaKemParameters ::= { | |||

other information to be included in the input to the key | keyDerivationFunction KeyDerivationFunction, | |||

derivation function. For this version of the document, | keyLength KeyLength | |||

the method MUST be the "specified other information" | } | |||

method. | ||||

KAS1-OtherInfoMethod ::= AlgorithmIdentifier | The fields of type RsaKemParameters have the following | |||

meanings: | ||||

The object identifier for the "specified other | * keyDerivationFunction identifies the underlying key | |||

information" method is id-specifiedOtherInfo: | derivation function. For alignment with the draft ANS | |||

X9.44, it MUST be KDF2. However, other key derivation | ||||

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

syntax for KDF2. | ||||

id-specifiedOtherInfo OID ::= [[to be defined]] | KeyDerivationFunction ::= | |||

AlgorithmIdentifier {{KDFAlgorithms}} | ||||

The associated parameters for id-specifiedOtherInfo have | KDFAlgorithms ALGORITHMS ::= { | |||

type SpecifiedOtherInfo: | kdf2, | |||

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

} | ||||

SpecifiedOtherInfo ::= OCTET STRING SIZE((0..MAX)) | * keyLength is the length in bytes of the key-encrypting | |||

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

wrapping scheme. | ||||

For this version of the document, the value of the other | KeyLength ::= INTEGER (1..MAX) | |||

information MUST be the empty string. | ||||

* kws identifies the underlying symmetric key-wrapping scheme. | * dem identifies the underlying data encapsulation mechanism. | |||

For alignment with the draft ANSI X9.44, it MUST be an X9- | For alignment with the draft ANS X9.44, it MUST be an X9- | |||

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

other schemes MAY be used with CMS. Please see B.2.2 for the | other symmetric key-wrapping schemes MAY be used with CMS. | |||

syntax for the AES and Triple-DES Key Wraps. | Please see B.2.2 for the syntax for the AES and Triple-DES Key | |||

Wraps. | ||||

KTS2-SymmetricKeyWrappingScheme ::= AlgorithmIdentifier | ||||

* labelMethod specifies the method for formatting a label to be | ||||

associated with the keying data. For this version of the | ||||

document, the method MUST be the "specified label" method. | ||||

KTS2-LabelMethod ::= AlgorithmIdentifier | ||||

The object identifier for the "specified label" method is id- | ||||

specifiedLabel, which is defined in the draft ANSI X9.44 as | ||||

id-specifiedLabel OID ::= { pkcs-1 specifiedLabel(9) } | ||||

The associated parameters for id-specifiedLabel have type | ||||

SpecifiedLabel: | ||||

SpecifiedLabel ::= OCTET STRING SIZE((0..MAX)) | ||||

For this version of the document, the value of the label MUST | DataEncapsulationMechanism ::= | |||

be the empty string. | AlgorithmIdentifier {{DEMAlgorithms}} | |||

NOTE: As of this writing, the AES Key Wrap and the Triple-DES Key | DEMAlgorithms ALGORITHM ::= { | |||

Wrap are in the process of being approved by X9. | X9-SymmetricKeyWrappingSchemes, | |||

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

} | ||||

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

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

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

} | ||||

DISCUSSION TOPIC: In NIST's key establishment schemes recommendation | NOTE: The generic hybrid cipher in the draft ISO/IEC 18033-2 can | |||

[NIST-SCHEMES], the parties' names are included in the "other | encrypt arbitrary data, hence the term "data encapsulation | |||

information" for key derivation. Should they be included here as | mechanism". The symmetric key-wrapping schemes take the role of data | |||

well? | encapsulation mechanisms in the RSA-KEM Key Transport Algorithm. The | |||

draft ISO/IEC 18033-2 currently allows only three particular data | ||||

encapsulation mechanisms, not including any of these symmetric key- | ||||

wrapping schemes. However, the ASN.1 syntax in that document expects | ||||

that additional algorithms will be allowed. | ||||

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

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

The object identifier for KDF2 (see [ANSI-X9.44]) is | The object identifier for KDF2 (see [ISO-IEC-18033-2]) is | |||

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

is18033-2 key-derivation-functions(5) kdf2(2) | ||||

} | ||||

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

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

X9-approved hash function. (See Note.) However, other hash functions | X9-approved hash function. (See Note.) However, other hash functions | |||

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

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

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

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

X9-HashFunctions, | ||||

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

} | ||||

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

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-256, SHA-384 and SHA-512 are | The object identifiers for SHA-256, SHA-384 and SHA-512 are | |||

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 without parameters, and MUST accept algorithm identifiers | |||

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

NOTE: As of this writing, only SHA-1 is an X9-approved hash | sha1 ALGORITHM ::= {{ OID id-sha1 }} -- NULLParms MUST be | |||

function; SHA-224 and above are in the process of being approved. | sha224 ALGORITHM ::= {{ OID id-sha224 }} -- accepted for these | |||

The object identifier for SHA-224 has not yet been assigned. | sha256 ALGORITHM ::= {{ OID id-sha256 }} -- OIDs | |||

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

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

B.2.2 Symmetric Key Wrapping Schemes | NOTE: As of this writing, only SHA-1 is an ASC X9-approved hash | |||

function; SHA-224 and above are in the process of being approved. The | ||||

object identifier for SHA-224 has not yet been assigned. | ||||

The object identifier for the AES Key Wrap depends on the size of | B.2.2 Symmetric Key-Wrapping Schemes | |||

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

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

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

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

aes192-Wrap ALGORITHM ::= {{ OID id-aes192-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 [3DES-WRAP]) | |||

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

B.3 Example | tdes-Wrap ALGORITHM ::= | |||

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

As an example, if the key derivation function is KDF2 based on SHA-1 | NOTE: As of this writing, the AES Key Wrap and the Triple-DES Key | |||

and the symmetric key wrapping scheme is the AES Key Wrap with a | Wrap are in the process of being approved by ASC X9. | |||

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

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

SEQUENCE { | B.3 ASN.1 module | |||

id-kts2-basic, -- basic KTS2 | ||||

SEQUENCE { -- KTS2-Parms | CMS-RSA-KEM | |||

[0] SEQUENCE { -- key agreement scheme | { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) | |||

id-kas1-basic, -- basic KAS1 | pkcs-9(9) smime(16) modules(0) cms-rsa-kem(21) } [[check]] | |||

SEQUENCE { -- KAS1-Parms | ||||

[0] SEQUENCE { -- secret value encapsulation scheme | BEGIN | |||

id-rsasves1 -- RSASVES1; no parameters | ||||

}, | -- EXPORTS ALL | |||

[1] SEQUENCE { -- key derivation function | ||||

id-kdf2, -- KDF2 | -- IMPORTS None | |||

SEQUENCE { -- KDF2-Parms | ||||

id-sha1 -- no parameters (preferred) | -- Useful types and definitions | |||

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

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

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

-- field shall be included in algorithm identifier values. The | ||||

-- parameters field shall be omitted if and only if the object | ||||

-- identifier does not have associated parameters (i.e., the PARMS | ||||

-- element is omitted), unless otherwise stated. | ||||

ALGORITHM ::= CLASS { | ||||

&id OBJECT IDENTIFIER UNIQUE, | ||||

&Type OPTIONAL | ||||

} | } | |||

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

[2] SEQUENCE { -- other information method | ||||

id-specifiedOtherInfo, -- specified other info. | AlgorithmIdentifier { ALGORITHM:IOSet } ::= SEQUENCE { | |||

''H -- empty string | algorithm ALGORITHM.&id( {IOSet} ), | |||

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

} | } | |||

NullParms ::= NULL | ||||

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

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

-- NIST algorithm arc | ||||

nistAlgorithm OID ::= { | ||||

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

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

} | ||||

-- PKCS #1 arc | ||||

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

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

} | ||||

-- RSA-KEM Key Transport Algorithm, based on Generic Hybrid Cipher | ||||

id-ac-generic-hybrid OID ::= { | ||||

is18033-2 asymmetric-cipher(1) generic-hybrid(2) | ||||

} | ||||

GenericHybridParameters ::= { | ||||

kem KeyEncapsulationMechanism, | ||||

dem DataEncapsulationMechanism | ||||

} | ||||

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

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

} | ||||

RsaKemParameters ::= { | ||||

keyDerivationFunction KeyDerivationFunction, | ||||

keyLength KeyLength | ||||

} | ||||

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

KDFAlgorithms ALGORITHMS ::= { | ||||

kdf2, | ||||

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

} | ||||

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

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

DEMAlgorithms ALGORITHM ::= { | ||||

X9-SymmetricKeyWrappingSchemes, | ||||

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

} | ||||

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

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

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

} | ||||

-- Key Derivation Functions | ||||

id-kdf-kdf2 OID ::= { is18033-2 key-derivation-functions(5) kdf2(2) } | ||||

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

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

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

X9-HashFunctions, | ||||

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

} | ||||

-- Hash Functions | ||||

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

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

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

} | ||||

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

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

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

} | ||||

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

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

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

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

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

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

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

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

-- Symmetric Key-Wrapping Schemes | ||||

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

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

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

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

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

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

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

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

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

} | } | |||

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

B.4 Examples | ||||

As an example, if the key derivation function is KDF2 based on | ||||

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

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

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

SEQUENCE { | ||||

id-ac-generic-hybrid, -- generic cipher | ||||

SEQUENCE { -- GenericHybridParameters | ||||

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

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

SEQUENCE { -- RsaKemParameters | ||||

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

id-kdf-kdf2, -- KDF2 | ||||

SEQUENCE { -- KDF2-HashFunction | ||||

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

}, | }, | |||

[1] SEQUENCE { -- symmetric key wrapping scheme | 16 -- KEK length in bytes | |||

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

}, | }, | |||

[2] SEQUENCE { -- label method | SEQUENCE { -- data encapsulation mechanism | |||

id-specifiedLabel, -- specified label | id-aes128-Wrap -- AES-128 Wrap; no parameters | |||

''H -- empty string | ||||

} | } | |||

} | } | |||

} | } | |||

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

30 4f | ||||

06 07 28 81 8c 71 02 01 02 -- id-ac-generic-hybrid | ||||

30 44 | ||||

30 25 | ||||

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

30 1a | ||||

30 16 | ||||

06 07 28 81 8c 71 02 05 02 -- id-kdf-kdf2 | ||||

30 0b | ||||

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

02 10 -- 16 bytes | ||||

30 0b | ||||

06 09 60 86 48 01 65 03 04 01 05 -- id-aes128-Wrap | ||||

The DER encodings for other typical sets of underlying components are | ||||

as follows: | ||||

* KDF2 based on SHA-384, AES Key Wrap with a 192-bit KEK | ||||

30 4f 06 07 28 81 8c 71 02 01 02 30 44 30 25 06 | ||||

07 28 81 8c 71 02 02 04 30 1a 30 16 06 07 28 81 | ||||

8c 71 02 05 02 30 0b 06 09 60 86 48 01 65 03 04 | ||||

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

19 | ||||

* KDF2 based on SHA-512, AES Key Wrap with a 256-bit KEK | ||||

30 4f 06 07 28 81 8c 71 02 01 02 30 44 30 25 06 | ||||

07 28 81 8c 71 02 02 04 30 1a 30 16 06 07 28 81 | ||||

8c 71 02 05 02 30 0b 06 09 60 86 48 01 65 03 04 | ||||

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

2d | ||||

* KDF2 based on SHA-1, Triple-DES Key Wrap with a 128-bit KEK | ||||

(two-key triple-DES) | ||||

30 4f 06 07 28 81 8c 71 02 01 02 30 44 30 21 06 | ||||

07 28 81 8c 71 02 02 04 30 16 30 12 06 07 28 81 | ||||

8c 71 02 05 02 30 07 06 05 2b 0e 03 02 1a 02 10 | ||||

30 0f 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06 05 | ||||

00 | ||||

* KDF2 based on SHA-224, Triple-DES Key Wrap with a 192-bit | ||||

KEK (three-key triple-DES) | ||||

[[to be defined, awaiting OID for SHA-224]] | ||||

Full Copyright Statement | Full Copyright Statement | |||

Copyright (C) The Internet Society (2003). All Rights Reserved. | Copyright (C) The Internet Society (2003). All Rights Reserved. | |||

This document and translations of it may be copied and furnished to | This document and translations of it may be copied and furnished to | |||

others, and derivative works that comment on or otherwise explain it | others, and derivative works that comment on or otherwise explain it | |||

or assist in its implementation may be prepared, copied, published | or assist in its implementation may be prepared, copied, published | |||

and distributed, in whole or in part, without restriction of any | and distributed, in whole or in part, without restriction of any | |||

kind, provided that the above copyright notice and this paragraph | kind, provided that the above copyright notice and this paragraph | |||

End of changes. | ||||

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |