 1/draftietfsmimecmsrsakem05.txt 20081110 20:12:03.000000000 +0100
+++ 2/draftietfsmimecmsrsakem06.txt 20081110 20:12:03.000000000 +0100
@@ 1,19 +1,19 @@
S/MIME Working Group J. Randall
Internet Draft RSA
Document: draftietfsmimecmsrsakem05.txt B.Kaliski
+Document: draftietfsmimecmsrsakem06.txt B.Kaliski
Category: Standards EMC Corp.
Expires: March 2008 September 2007
+Expires: March 2009 September 2008
Use of the RSAKEM Key Transport Algorithm in CMS

+
Intellectual Property
By submitting this InternetDraft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
@@ 30,21 +30,21 @@
such proprietary rights by implementers or users of this
specification can be obtained from the IETF online IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietfipr@ietf.org.
 Copyright (C) The IETF Trust (2007).
+ Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
InternetDrafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as InternetDrafts.
InternetDrafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
@@ 104,28 +104,34 @@
c = z^e mod n.
3. Derive a keyencrypting key KEK from the integer z.
4. Wrap the keying data using KEK to obtain wrapped keying data
WK.
5. Output c and WK as the encrypted keying data.
This different approach provides higher security assurance because
 the input to the underlying RSA operation is random and independent
 of the message, and the keyencrypting key KEK is derived from it in
 a strong way. As a result, the algorithm enjoys a "tight" security
 proof in the random oracle model. It is also architecturally
 convenient because the publickey operations are separate from the
 symmetric operations on the keying data. One 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.
+ (a) the input to the underlying RSA operation is effectively a
+ random integer between 0 and n1, where n is the RSA modulus, so it
+ does not 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 decryption operation is not directly available to an
+ adversary. As a result, the algorithm enjoys a "tight" security
+ proof in the random 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 provable security assurances are not as
+ strong.) The approach is also architecturally convenient because the
+ publickey operations are separate from the symmetric operations on
+ the keying data. One benefit is that the length of the keying data
+ is bounded only by the symmetric keywrapping scheme, not the size
+ of the RSA modulus.
The RSAKEM Key Transport Algorithm in various forms is being adopted
in several draft standards as well as in ANSX9.44 and ISO/IEC
180332. It has also been recommended by the NESSIE project [NESSIE].
For completeness, a specification of the algorithm is given in
Appendix A of this document; ASN.1 syntax is given in Appendix B.
NOTE: The term KEM stands for "key encapsulation mechanism" and
refers to the first three steps of the process above. The
formalization of key transport algorithms (or more generally,
@@ 354,26 +360,28 @@
[3DESWRAP] Housley, R. TripleDES and RC2 Key Wrapping. RFC
3217. December 2001.
[AESWRAP] Schaad, J. and R. Housley. Advanced Encryption
Standard (AES) Key Wrap Algorithm. RFC 3394.
September 2002.
[ANSX9.63] American National Standard X9.632002: Public Key
Cryptography for the Financial Services Industry:
+
Key Agreement and Key Transport Using Elliptic
Curve Cryptography.
[CAMILLIA] Kato, A., Moriai, S., and Kanda, M.: The Camellia
 Cipher Algorithm and Its Use With IPsec. RFC 4312.
 December 2005
+ Cipher Algorithm and Its Use With IPsec. RFC 3657.
+ December 2005.
+
[CMS] Housley, R. Cryptographic Message Syntax. RFC
3852. July 2004.
[CMSALGS] Housley, R. Cryptographic Message Syntax (CMS)
Algorithms. RFC 3370. August 2002.
[FIPS1802] National Institute of Standards and Technology
(NIST). FIPS 1802: Secure Hash Standard. August
2002.
@@ 1129,21 +1139,21 @@
(twokey tripleDES)
30 4f 06 07 28 81 8c 71 02 01 02 30 44 30 21 06
07 28 81 8c 71 02 02 04 30 16 30 12 06 07 28 81
8c 71 02 05 02 30 07 06 05 2b 0e 03 02 1a 02 10
30 0f 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06 05
00
Full Copyright Statement
 Copyright (C) The IETF Trust (2007).
+ Copyright (C) The IETF Trust (2008).
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of