 1/draftietfsmimecmsrsakem11.txt 20100309 01:11:13.000000000 +0100
+++ 2/draftietfsmimecmsrsakem12.txt 20100309 01:11:13.000000000 +0100
@@ 1,18 +1,18 @@
S/MIME WG James Randall, Randall Consulting
Internet Draft Burt Kaliski, EMC
Intended Status: Standards Track John Brainard, RSA
Sean Turner, IECA
Expires: August 19, 2010 February 19, 2010
+Expires: September 8, 2010 March 8, 2010
Use of the RSAKEM Key Transport Algorithm in CMS

+
Abstract
The RSAKEM Key Transport Algorithm is a onepass (storeandforward)
mechanism for transporting keying data to a recipient using the
recipient's RSA public key. This document specifies the conventions
for using the RSAKEM Key Transport Algorithm with the Cryptographic
Message Syntax (CMS). The ASN.1 syntax is aligned with ANS X9.44 and
ISO/IEC 180332.
@@ 39,21 +39,21 @@
InternetDrafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use InternetDrafts as reference
material or to cite them other than as "work in progress."
The list of current InternetDrafts can be accessed at
http://www.ietf.org/ietf/1idabstracts.txt
The list of InternetDraft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
 This InternetDraft will expire on August 19, 2010.
+ This InternetDraft will expire on September 8, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/licenseinfo) in effect on the date of
publication of this document. Please review these documents
@@ 160,47 +160,38 @@
mechanisms is described further in research by Victor Shoup leading
to the development of the ISO/IEC 180332 standard [SHOUP].
2. Use in CMS
The RSAKEM Key Transport Algorithm MAY be employed for one or more
recipients in the CMS envelopeddata content type (Section 6 of
[CMS]), where the keying data processed by the algorithm is the CMS
contentencryption key.
 The RSAKEM 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
 chosenciphertext attacks. The RSAESOAEP Key Transport Algorithm has
 also been proposed as a replacement (see [PKCS1] and [CMSOAEP]).
 RSAKEM has the advantage over RSAESOAEP of a tighter security
 proof, but the disadvantage of slightly longer encrypted keying data.

2.1. Underlying Components
A CMS implementation that supports the RSAKEM Key Transport
Algorithm MUST support at least the following underlying components:
o For the key derivation function, KDF3 (see [IEEEP1363a]) based on
SHA256 (see [FIPS1803]). KDF3 is an instantiation of the
Concatenation Key Derivation Function defined in [NISTSP80056A].
o For the keywrapping scheme, AESWrap128, i.e., the AES Key Wrap
with a 128bit key encrypting key (see [AESWRAP]).
An implementation SHOULD also support KDF2 (see [ANSX9.44]) based on
SHA1 (this function is also specified as the key derivation function
in [ANSX9.63]). The Camellia key wrap algorithm (see [CAMELLIA])
 SHOULD be supported, and, if 3DES is supported as a content
 encryption cipher, then the TripleDES Key Wrap (see [3DESWRAP])
 SHOULD also be supported.
+ SHOULD be supported if Camellia is supported as a contentencryption
+ cipher. The TripleDES Key Wrap (see [3DESWRAP]) SHOULD also be
+ supported if TripleDES is supported as a contentencryption cipher.
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,
192, or 256 bits, while Triple DES requires a data block size of 64
bits and a key size of 112 or 168 bits.
2.2. RecipientInfo Conventions
When the RSAKEM Key Transport Algorithm is employed for a recipient,
the RecipientInfo alternative for that recipient MUST be
@@ 227,25 +218,25 @@
AlgorithmIdentifier as for the PKCS #1 v1.5 algorithm, i.e., using
the rsaEncryption object identifier [PKCS1]. The fact that the user
will accept RSAKEM with this public key is not indicated by the use
of this identifier. This may be signalled by the use of the
appropriate SMIME Capabilities either in a message or in the
certificate.
If the recipient wishes only to employ the RSAKEM Key Transport
Algorithm with a given public key, the recipient MUST identify the
public key in the certificate using the idrsakem object identifier
 (see Appendix B). When the idktarsakem 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 idrsakem.
+ (see Appendix B). When the idrsakem 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 idrsakem.
Regardless of the AlgorithmIdentifier used, the RSA public key is
encoded in the same manner in the subject public key information. The
RSA public key MUST be encoded using the type RSAPublicKey type:
RSAPublicKey ::= SEQUENCE {
modulus INTEGER,  n
publicExponent INTEGER  e
}
@@ 285,20 +276,29 @@
B) in the capabilityID field and MUST include a
GenericHybridParameters value in the parameters field identifying the
components with which the algorithm is to be employed.
The DER encoding of a SMIMECapability SEQUENCE is the same as the DER
encoding of an AlgorithmIdentifier. Example DER encodings for typical
sets of components are given in Appendix B.4.
3. Security Considerations
+ The RSAKEM 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
+ chosenciphertext attacks. The RSAESOAEP Key Transport Algorithm
+ has also been proposed as a replacement (see [PKCS1] and [CMSOAEP]).
+ RSAKEM has the advantage over RSAESOAEP of a tighter security
+ proof, but the disadvantage of slightly longer encrypted keying data.
+
The security of the RSAKEM Key Transport Algorithm described in this
document can be shown to be tightly related to the difficulty of
either solving the RSA problem or breaking the underlying symmetric
keywrapping scheme, if the underlying key derivation function is
modeled as a random oracle, and assuming that the symmetric key
wrapping scheme satisfies the properties of a data encapsulation
mechanism [SHOUP]. While in practice a randomoracle result does not
provide an actual security proof for any particular key derivation
function, the result does provide assurance that the general
construction is reasonable; a key derivation function would need to
@@ 1131,22 +1130,21 @@
SEQUENCE {  KDF3HashFunction
idsha256  SHA256; no parameters (preferred)
},
16  KEK length in bytes
},
SEQUENCE {  data encapsulation mechanism
idaes128Wrap  AES128 Wrap; no parameters
}
}
}
 This AlgorithmIdentifier value has the following DER encoding (??
 indicates the algorithm number which is to be assigned):
+ This AlgorithmIdentifier value has the following DER encoding:
30 47
06 0b 2a 86 48 86 f7 0d 01 09 10 03 0e  idrsakem
30 38
30 29
06 07 28 81 8c 71 02 02 04  idkemrsa
30 1e
30 19
06 0a 2b 81 05 10 86 48 09 2c 01 02  idkdfkdf3
30 0b