draft-ietf-smime-cms-rsa-kem-10.txt | draft-ietf-smime-cms-rsa-kem-11.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: June 8, 2010 December 8, 2009 | Expires: August 19, 2010 February 19, 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-10.txt> | <draft-ietf-smime-cms-rsa-kem-11.txt> | |||

Abstract | ||||

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

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

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

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

Message Syntax (CMS). The ASN.1 syntax is aligned with ANS X9.44 and | ||||

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

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 1, line 38 | skipping to change at page 2, line 4 | |||

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 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 June 8, 2010. | This Internet-Draft will expire on August 19, 2010. | |||

Copyright Notice | Copyright Notice | |||

Copyright (c) 2009 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 in effect on the date of | Provisions Relating to IETF Documents | |||

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

Please review these documents carefully, as they describe your rights | publication of this document. Please review these documents | |||

and restrictions with respect to this document. | carefully, as they describe your rights and restrictions with respect | |||

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

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

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

The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) | described in the Simplified BSD License. | |||

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

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

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

Message Syntax (CMS). The ASN.1 syntax is aligned with ANS X9.44 and | ||||

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

Conventions Used in This Document | 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 this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||

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

Table of Contents | Table of Contents | |||

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

2. Use in CMS.....................................................4 | 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. References.....................................................9 | 4. IANA Considerations............................................9 | |||

4.1. Normative References......................................9 | 5. Acknowledgements...............................................9 | |||

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

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

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

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

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

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

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

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

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

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

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

B.4 Examples..................................................24 | B.3 ASN.1 module..............................................20 | |||

IANA Considerations..............................................25 | B.4 Examples..................................................25 | |||

Acknowledgements.................................................25 | Authors' Addresses...............................................27 | |||

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

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 9 | skipping to change at page 4, line 10 | |||

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

integer between 0 and n-1, where n is the RSA modulus, so it does not | integer between 0 and n-1, where n is the RSA modulus, so it does not | |||

have any structure that could be exploited by an adversary, and (b) | have any structure that could be exploited by an adversary, and (b) | |||

the input is independent of the keying data so the result of the RSA | the input is independent of the keying data so the result of the RSA | |||

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

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. One | 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 and ISO/IEC 18033- | |||

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

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

skipping to change at page 4, line 49 | skipping to change at page 5, line 6 | |||

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

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

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

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 [IEEE-P1363a]) based on | |||

SHA-256 (see [FIPS-180-2]). 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 Wrap | |||

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

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

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

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

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

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

SHOULD also be supported. | SHOULD also be supported. | |||

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

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

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

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

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

Appendix A) | 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 signed by the use of the appropriate | of this identifier. This may be signalled by the use of the | |||

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

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). The parameters are absent. | (see Appendix B). When the id-kta-rsa-kem algorithm identifier | |||

appears in the SubjectPublicKeyInfo algorithm field, the encoding | ||||

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

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

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

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

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

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

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

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

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

} | } | |||

skipping to change at page 9, line 5 | skipping to change at page 9, line 12 | |||

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

4.1. Normative References | Within the CMS, algorithms are identified by object identifiers | |||

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

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

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

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

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

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

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

5. Acknowledgements | ||||

This document is one part of a strategy to align algorithm standards | ||||

produced by ASC X9, ISO/IEC JTC1 SC27, NIST, and the IETF. We would | ||||

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

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

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

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

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

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

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

editorial direction and procedural guidance. | ||||

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

skipping to change at page 9, line 31 | skipping to change at page 10, line 18 | |||

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

5652. September 20009. | 5652. September 20009. | |||

[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-3] National Institute of Standards and Technology | |||

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

2002. | 2008. | |||

[MSG] Ramsdell, B. S/MIME Version 3 Message | [MSG] Ramsdell, B., and S. Turner. S/MIME Version 3.2 | |||

Specification. RFC 3851. July 2004. | Message Specification. RFC 5751. January 2010. | |||

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

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

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

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

5280. May 2008. | 5280. May 2008. | |||

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

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

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

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

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

RFC 5649. August 2009. | ||||

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

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

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

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

[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 | [IEEE-P1363a] IEEE Std 1363a-2004: Standard Specifications for | |||

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

IEEE, 2004. | IEEE, 2004. | |||

[ISO-IEC-18033-2] ISO/IEC 18033-2:2005 Information technology -- | [ISO-IEC-18033-2] ISO/IEC 18033-2:2005 Information technology -- | |||

Security techniques -- Encryption algorithms -- | Security techniques -- Encryption algorithms -- | |||

Part 2: Asymmetric Ciphers. ISO/IEC, 2005. | 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. | |||

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

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

Key Management. Part 1: General Guideline. August | Key Management. Part 1: General Guideline. August | |||

2005. Available via: | 2005. Available via: | |||

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

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

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

skipping to change at page 11, line 21 | skipping to change at page 12, line 6 | |||

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

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

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

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

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

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

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

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

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

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

skipping to change at page 14, line 32 | skipping to change at page 15, line 16 | |||

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 | x9-44 OID ::= { iso(1) identified-organization(3) tc68(133) | |||

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

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

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

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

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

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

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

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

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

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

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

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

} | } | |||

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

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

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

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. For the | o kem identifies the underlying key encapsulation mechanism, which | |||

RSA-KEM Key Transport Algorithm, the scheme is RSA-KEM from | in this case is also denoted as RSA-KEM, per 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 ISO/IEC 18033-2 as: | mechanism) is id-kem-rsa, which is defined in ISO/IEC 18033-2 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: | |||

skipping to change at page 18, line 4 | skipping to change at page 18, line 41 | |||

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

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

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

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

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

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

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

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

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

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

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

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

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

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

} | } | |||

skipping to change at page 18, line 45 | skipping to change at page 19, line 36 | |||

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

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

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

} | } | |||

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

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

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

NOTE: As of this writing, the AES Key Wrap and the Triple-DES Key | NOTE: ASC X9 has not yet incorporated AES Key Wrap with Padding [AES- | |||

Wrap are in the process of being approved by ASC X9. | WRAP-PAD] in to ANS X9.44. When ASC X9.44 adds AES Key Wrap with | |||

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

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

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

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

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

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

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

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

skipping to change at page 20, line 39 | skipping to change at page 21, line 32 | |||

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

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

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

} | } | |||

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

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

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

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

} | } | |||

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

kem KeyEncapsulationMechanism, | kem KeyEncapsulationMechanism, | |||

dem DataEncapsulationMechanism | dem DataEncapsulationMechanism | |||

} | } | |||

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

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

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

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

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

} | } | |||

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

keyDerivationFunction KeyDerivationFunction, | keyDerivationFunction KeyDerivationFunction, | |||

keyLength KeyLength | keyLength KeyLength | |||

} | } | |||

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

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

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

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

skipping to change at page 22, line 22 | skipping to change at page 23, line 22 | |||

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

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

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

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

} | } | |||

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

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

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

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

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

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

} | } | |||

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

skipping to change at page 24, line 35 | skipping to change at page 26, line 4 | |||

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): | indicates the algorithm number which is to be assigned): | |||

30 53 | 30 47 | |||

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

30 44 | 30 38 | |||

30 25 | 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 1a | 30 1e | |||

30 16 | 30 19 | |||

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

30 0b | 30 0b | |||

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

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

30 0b | ||||

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

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

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

as follows: | as follows: | |||

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

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

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

1a 30 16 06 07 28 81 8c 71 02 05 02 30 0b 06 09 | 06 0a 2b 81 05 10 86 48 09 2c 01 02 30 0b 06 09 | |||

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

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

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

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

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

1a 30 16 06 07 28 81 8c 71 02 05 02 30 0b 06 09 | 06 0a 2b 81 05 10 86 48 09 2c 01 02 30 0b 06 09 | |||

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

86 48 01 65 03 04 01 2d | 60 86 48 01 65 03 04 01 2d | |||

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

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

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

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

16 30 12 06 07 28 81 8c 71 02 05 02 30 07 06 05 | 06 0a 2b 81 05 10 86 48 09 2c 01 01 30 07 06 05 | |||

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

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

IANA Considerations | ||||

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

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

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

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

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

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

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

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

Acknowledgements | ||||

This document is one part of a strategy to align algorithm standards | ||||

produced by ASC X9, ISO/IEC JTC1 SC27, NIST, and the IETF. We would | ||||

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

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

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

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

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

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

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

editorial direction and procedural guidance. | ||||

Authors' Addresses | Authors' Addresses | |||

James Randall | James Randall | |||

Randall Consulting | Randall Consulting | |||

55 Sandpiper Drive | 55 Sandpiper Drive | |||

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

USA | USA | |||

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

End of changes. 43 change blocks. | ||||

125 lines changed or deleted | | 141 lines changed or added | ||

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