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

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

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

Document: draft-ietf-smime-cms-rsa-kem-01.txt October 2003 | Document: draft-ietf-smime-cms-rsa-kem-02.txt March 2006 | |||

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-01.txt> | <draft-ietf-smime-cms-rsa-kem-02.txt> | |||

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

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

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

Internet-Drafts are draft documents valid for a maximum of six | By submitting this Internet-Draft, each author represents that any | |||

months and may be updated, replaced, or obsoleted by other documents | applicable patent or other IPR claims of which he or she is aware | |||

at any time. It is inappropriate to use Internet-Drafts as | have been or will be disclosed, and any of which he or she becomes | |||

reference material or to cite them other than as "work in progress." | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||

The list of current Internet-Drafts can be accessed at | Copyright (C) The Internet Society (2006). | |||

This document is subject to the rights, licenses and restrictions | ||||

contained in BCP 78, and except as set forth therein, the authors | ||||

retain all their rights. | ||||

This document and the information contained herein are provided on an | ||||

"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | ||||

OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | ||||

ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | ||||

INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | ||||

INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | ||||

WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||||

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

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

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

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

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

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

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

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

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

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

Abstract | Abstract | |||

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

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

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

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

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

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

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

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

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

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

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

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

1. Introduction | 1. Introduction | |||

skipping to change at page 2, line 53 | skipping to change at page 3, line 22 | |||

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

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

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

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

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

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

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

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

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

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

recommended by the NESSIE project [NESSIE]. Although the other | project [NESSIE]. For completeness, a specification of the algorithm | |||

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

the drafts. For completeness, a specification of the algorithm is | is given in Appendix A of this document; ASN.1 syntax is given in | |||

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

Appendix B. | Appendix B. | |||

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

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

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

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

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

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

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

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

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 [ANS-X9.44][IEEE- | * For the key derivation function, KDF2 or KDF3 (see [ANS-X9.44] | |||

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

also specified as the key derivation function in [ANS-X9.63]) | is 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 and KDF3 based on SHA-256 | |||

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

support other underlying components. | Camillia key wrap algorithm (see [Camillia]). It MAY support other | |||

underlying components. When AES or Camilla are used the data block | ||||

size is 128 bits while the key size can be 128, 192, or 256 bits | ||||

while Triple DES requires a data block size of 64 bits and a key size | ||||

of 112 or 168 bits. | ||||

2.2 RecipientInfo Conventions | 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, | |||

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

* keyEncryptionAlgorithm.algorithm MUST be id-ac-generic-hybrid | * keyEncryptionAlgorithm.algorithm MUST be id-ac-generic-hybrid | |||

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

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

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

encapsulation mechanism (see Appendix B) | 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, where the keying data is the content-encryption key. | |||

(see Appendix A) | ||||

2.3 Certificate Conventions | 2.3 Certificate Conventions | |||

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

skipping to change at page 4, line 54 | skipping to change at page 5, line 30 | |||

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-ac-generic-hybrid object identifier as | public key with the id-ac-generic-hybrid object identifier as | |||

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

following value: | 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 be | |||

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

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

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

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

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

essential to maintain provable security. | ||||

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

RFC 2633 [MSG], Section 2.5.2 defines the SMIMECapabilities signed | RFC 2633 [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. | |||

skipping to change at page 5, line 43 | skipping to change at page 6, line 23 | |||

encapsulation mechanism [SHOUP]. While in practice a random-oracle | encapsulation mechanism [SHOUP]. While in practice a random-oracle | |||

result does not provide an actual security proof for any particular | result does not provide an actual security proof for any particular | |||

key derivation function, the result does provide assurance that the | key derivation function, the result does provide assurance that the | |||

general construction is reasonable; a key derivation function would | general construction is reasonable; a key derivation function would | |||

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

possible in the random oracle model. | 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- | |||

GUIDELINE]. For brevity, the first three levels are mentioned here: | FIPS PUB 800-57]. For brevity, the first three levels are mentioned | |||

here: | ||||

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

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

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

Triple-DES Key Wrap. | Triple-DES Key Wrap, or Camillia 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 the KDF 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, Triple-DES Key Wrap, or Camillia 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 the KDF 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 or Camillia Key Wrap. | |||

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

the use of AES does not require a 128-bit security level for other | three of these levels; the use of AES or Camillia does not require a | |||

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

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

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

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

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

encrypted content. | encrypted content. | |||

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

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

skipping to change at page 6, line 53 | skipping to change at page 7, line 33 | |||

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 | ASC X9 requires such a separation between key establishment key pairs | |||

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

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

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

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

components. | components. | |||

Parties MAY wish to 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. 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. | |||

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

CAMILLIA Kato, A., Moriai, S., and Kanda, M.: The Camellia | ||||

Cipher Algorithm and Its Use With IPsec. RFC 4312. | ||||

December 2005 | ||||

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

FIPS-180-2 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. | |||

skipping to change at page 7, line 47 | skipping to change at page 8, line 30 | |||

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

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

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

4.2 Informative References | 4.2 Informative References | |||

ANS-X9.44 ASC X9F1 Working Group. Draft American National | ANS-X9.44 ASC X9F1 Working Group. Draft American National | |||

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

Financial Services Industry -- Key Establishment | Financial Services Industry -- Key Establishment | |||

Using Integer Factorization Cryptography. Draft D6, | Using Integer Factorization Cryptography. Draft | |||

October 15, 2003. | D11, January 2006. | |||

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

Algorithm in the Cryptographic Message Syntax | Algorithm in the Cryptographic Message Syntax | |||

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

IEEE-P1363a IEEE P1363 Working Group. IEEE P1363a: Standard | IEEE-P1363a IEEE Std 1363a-2004: Standard Specifications for | |||

Specifications for Public Key Cryptography: | Public Key Cryptography: Additional Techniques. | |||

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

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

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

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

Asymmetric Ciphers. 2nd Committee Draft, July 10, | Part 2: Asymmetric Ciphers. ISO/IEC, 2005. | |||

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-GUIDELINE National Institute of Standards and Technology. | NIST-GUIDELINE National Institute of Standards and Technology. | |||

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

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

January 2003. Available via | Available via http://csrc.nist.gov/publications/index.html. | |||

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

skipping to change at page 8, line 46 | skipping to change at page 9, line 27 | |||

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

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

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

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

fruition. | to fruition. | |||

7. Author's Address | 7. Authors' Addresses | |||

James Randall | ||||

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 | {jrandall, 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-forward) | The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) | |||

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

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

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

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

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

skipping to change at page 9, line 40 | skipping to change at page 10, line 20 | |||

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 length | wrapping scheme. (Bothe the AES and Camillia Key Wraps, for instance, | |||

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

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

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

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

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

With some key derivation functions, it is possible to include other | input to the function. Also, with some symmetric key-wrapping | |||

information besides the shared secret value in the input to the | schemes, it is possible to associate a label with the keying data. | |||

function. Also, with some symmetric key-wrapping schemes, it is | Such uses are outside the scope of this document, as they are not | |||

possible to associate a label with the keying data. Such uses are | directly supported by CMS. | |||

outside the scope of this document, as they are not 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 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 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: | |||

skipping to change at page 11, line 56 | skipping to change at page 12, line 36 | |||

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

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

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

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

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

needed. | needed. | |||

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

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

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

draft ISO/IEC 18033-2 [ISO-IEC-18033-2], and is the same as employed | ISO/IEC 18033-2 [ISO-IEC-18033-2], and is the same as employed in the | |||

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

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

including those mentioned above is given in B.2. | 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: | |||

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

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

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

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

} | } | |||

skipping to change at page 12, line 18 | skipping to change at page 13, line 4 | |||

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

below: | below: | |||

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

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

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

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

} | } | |||

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

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

} | } | |||

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

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

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

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

SUBJECT TO CHANGE as that standard is developed. | X9.44, and is SUBJECT TO CHANGE as that standard is developed. | |||

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

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

same as for the "generic hybrid cipher" in the draft ANS ISO/IEC | same as for the "generic hybrid cipher" in the draft ANS ISO/IEC | |||

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

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

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

} | } | |||

skipping to change at page 12, line 54 | skipping to change at page 13, line 39 | |||

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

* kem identifies the underlying key encapsulation mechanism. For | * kem identifies the underlying key encapsulation mechanism. For | |||

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

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

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

mechanism) is id-kem-rsa, which is defined in the draft ISO/IEC | mechanism) is id-kem-rsa, which is defined in ISO/IEC 18033-2 | |||

18033-2 as | 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 | The fields of type RsaKemParameters have the following | |||

meanings: | meanings: | |||

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

derivation function. For alignment with the draft ANS | derivation function. For alignment with the draft ANS | |||

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

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

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

KeyDerivationFunction ::= | KeyDerivationFunction ::= | |||

AlgorithmIdentifier {{KDFAlgorithms}} | AlgorithmIdentifier {{KDFAlgorithms}} | |||

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

kdf2, | kdf2 | kdf3, | |||

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

} | } | |||

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

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

wrapping scheme. | wrapping scheme. | |||

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

* dem identifies the underlying data encapsulation mechanism. | * dem identifies the underlying data encapsulation mechanism. | |||

For alignment with the draft ANS X9.44, it MUST be an X9- | For alignment with 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 symmetric key-wrapping schemes MAY be used with CMS. | other symmetric key-wrapping schemes MAY be used with CMS. | |||

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

Wraps. | Camillia Key Wraps. | |||

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

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

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

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

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

} | } | |||

Camillia-KeyWrappingSchemes ALGORITHM ::= { | ||||

camillia128-Wrap | camillia192-Wrap | camillia256-Wrap | ||||

} | ||||

NOTE: The generic hybrid cipher in the draft ISO/IEC 18033-2 can | NOTE: The generic hybrid cipher in ISO/IEC 18033-2 can encrypt | |||

encrypt arbitrary data, hence the term "data encapsulation | arbitrary data, hence the term "data encapsulation mechanism". The | |||

mechanism". The symmetric key-wrapping schemes take the role of data | symmetric key-wrapping schemes take the role of data encapsulation | |||

encapsulation mechanisms in the RSA-KEM Key Transport Algorithm. The | mechanisms in the RSA-KEM Key Transport Algorithm. ISO/IEC 18033-2 | |||

draft ISO/IEC 18033-2 currently allows only three particular data | allows only three specific data encapsulation mechanisms, not | |||

encapsulation mechanisms, not including any of these symmetric key- | including any of these symmetric key-wrapping schemes. However, the | |||

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

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

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

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

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

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 ANS X9.44, the hash function MUST be an ASC | alignment with the draft ANS X9.44, the hash function MUST be an ASC | |||

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

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

} | } | |||

skipping to change at page 14, line 53 | skipping to change at page 16, line 4 | |||

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

... -- allows for future expansion | ... -- 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-256, SHA-384 and SHA-512 are | 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 }} –- "" | |||

NOTE: As of this writing, only SHA-1 is an ASC X9-approved hash | The object identifier for KDF3 is: | |||

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

object identifier for SHA-224 has not yet been assigned. | id-kdf-kdf3 OID ::= { | |||

to be assigned | ||||

} | ||||

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

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

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

MAY be used with CMS. | ||||

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

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

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

X9-HashFunctions, | ||||

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

} | ||||

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

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

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

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

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

skipping to change at page 16, line 5 | skipping to change at page 17, line 26 | |||

} | } | |||

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: As of this writing, the AES Key Wrap and the Triple-DES Key | NOTE: As of this writing, the AES Key Wrap and the Triple-DES Key | |||

Wrap are in the process of being approved by ASC X9. | Wrap are in the process of being approved by ASC X9. | |||

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

camellia192-Wrap ALGORITHM ::= {{ OID id-camellia192-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) } [[check]] | pkcs-9(9) smime(16) modules(0) cms-rsa-kem(21) } [[check]] | |||

BEGIN | BEGIN | |||

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

skipping to change at page 17, line 27 | skipping to change at page 19, line 27 | |||

} | } | |||

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

keyDerivationFunction KeyDerivationFunction, | keyDerivationFunction KeyDerivationFunction, | |||

keyLength KeyLength | keyLength KeyLength | |||

} | } | |||

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

KDFAlgorithms ALGORITHMS ::= { | KDFAlgorithms ALGORITHMS ::= { | |||

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

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

} | } | |||

Camillia-KeyWrappingSchemes ALGORITHM ::= { | ||||

camillia128-Wrap | camillia192-Wrap | camillia128-Wrap | ||||

} | ||||

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

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

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

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

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

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

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

} | } | |||

-- id-kdf-kdf3 OID ::= (to be assigned) | ||||

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

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

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

X9-HashFunctions, | ||||

... -- 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-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 }} –- "" | |||

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

skipping to change at page 18, line 43 | skipping to change at page 21, line 15 | |||

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

As an example, if the key derivation function is KDF2 based on | 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 | 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 | with a 128-bit KEK, the AlgorithmIdentifier for the RSA-KEM Key | |||

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

SEQUENCE { | SEQUENCE { | |||

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

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

skipping to change at page 20, line 11 | skipping to change at page 23, line 33 | |||

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

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

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

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

00 | 00 | |||

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

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

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

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. 61 change blocks. | ||||

114 lines changed or deleted | | 216 lines changed or added | ||

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