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