draft-ietf-smime-cms-rsa-kem-05.txt   draft-ietf-smime-cms-rsa-kem-06.txt 
S/MIME Working Group J. Randall S/MIME Working Group J. Randall
Internet Draft RSA Internet Draft RSA
Document: draft-ietf-smime-cms-rsa-kem-05.txt B.Kaliski Document: draft-ietf-smime-cms-rsa-kem-06.txt B.Kaliski
Category: Standards EMC Corp. Category: Standards EMC Corp.
Expires: March 2008 September 2007 Expires: March 2009 September 2008
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-04.txt> <draft-ietf-smime-cms-rsa-kem-06.txt>
Intellectual Property Intellectual Property
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
skipping to change at page 1, line 41 skipping to change at page 1, line 41
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-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
skipping to change at page 3, line 11 skipping to change at page 3, line 11
c = z^e mod n. c = z^e mod n.
3. Derive a key-encrypting key KEK from the integer z. 3. Derive a key-encrypting key KEK from the integer z.
4. Wrap the keying data using KEK to obtain wrapped keying data 4. Wrap the keying data using KEK to obtain wrapped keying data
WK. WK.
5. Output c and WK as the encrypted keying data. 5. Output c and WK as the encrypted keying data.
This different approach provides higher security assurance because This different approach provides higher security assurance because
the input to the underlying RSA operation is random and independent (a) the input to the underlying RSA operation is effectively a
of the message, and the key-encrypting key KEK is derived from it in random integer between 0 and n-1, where n is the RSA modulus, so it
a strong way. As a result, the algorithm enjoys a "tight" security does not have any structure that could be exploited by an adversary,
proof in the random oracle model. It is also architecturally and (b) the input is independent of the keying data so the result of
convenient because the public-key operations are separate from the the RSA decryption operation is not directly available to an
symmetric operations on the keying data. One benefit is that the adversary. As a result, the algorithm enjoys a "tight" security
length of the keying data is bounded only by the symmetric key- proof in the random oracle model. (In other padding schemes, such
wrapping scheme, not the size of the RSA modulus. 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
public-key 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.
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 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]. 18033-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.
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,
skipping to change at page 7, line 50 skipping to change at page 8, line 4
[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:
Key Agreement and Key Transport Using Elliptic Key Agreement and Key Transport Using Elliptic
Curve Cryptography. Curve Cryptography.
[CAMILLIA] Kato, A., Moriai, S., and Kanda, M.: The Camellia [CAMILLIA] Kato, A., Moriai, S., and Kanda, M.: The Camellia
Cipher Algorithm and Its Use With IPsec. RFC 4312. Cipher Algorithm and Its Use With IPsec. RFC 3657.
December 2005 December 2005.
[CMS] Housley, R. Cryptographic Message Syntax. RFC [CMS] Housley, R. Cryptographic Message Syntax. RFC
3852. July 2004. 3852. July 2004.
[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-2] National Institute of Standards and Technology
(NIST). FIPS 180-2: Secure Hash Standard. August (NIST). FIPS 180-2: Secure Hash Standard. August
2002. 2002.
skipping to change at page 22, line 50 skipping to change at page 22, line 50
(two-key triple-DES) (two-key triple-DES)
30 4f 06 07 28 81 8c 71 02 01 02 30 44 30 21 06 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 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 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 30 0f 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06 05
00 00
Full Copyright Statement 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 This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 8 change blocks. 
15 lines changed or deleted 23 lines changed or added

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