draft-ietf-smime-cms-rsa-kem-11.txt | draft-ietf-smime-cms-rsa-kem-12.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: August 19, 2010 February 19, 2010 | Expires: September 8, 2010 March 8, 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-11.txt> | <draft-ietf-smime-cms-rsa-kem-12.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 ANS X9.44 and | |||

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

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 August 19, 2010. | This Internet-Draft will expire on September 8, 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 4, line 35 | skipping to change at page 4, line 35 | |||

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

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

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

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

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

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

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

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

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

chosen-ciphertext attacks. The RSAES-OAEP Key Transport Algorithm has | ||||

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

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

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-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 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 if Camellia is supported as a content-encryption | |||

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

SHOULD also be supported. | 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 | |||

skipping to change at page 6, line 10 | skipping to change at page 5, line 46 | |||

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 signalled 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-kta-rsa-kem algorithm identifier | (see Appendix B). When the id-rsa-kem algorithm identifier appears in | |||

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

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

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

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

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

encoded in the same manner in the subject public key information. The | encoded in the same manner in the subject public key information. 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 7, line 21 | skipping to change at page 7, line 11 | |||

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

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

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

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

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

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

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

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

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

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

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

chosen-ciphertext attacks. The RSAES-OAEP Key Transport Algorithm | ||||

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

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

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

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

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

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

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

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

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

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

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

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

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

skipping to change at page 26, line 4 | 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): | ||||

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

22 lines changed or deleted | | 21 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/ |