rfc3370.txt

RFC 的详细文档！

RFC 3370                     CMS Algorithms                  August 2002


   [CMS]       Housley, R., "Cryptographic Message Syntax", RFC 3269,
               August 2002.

   [DES]       American National Standards Institute.  ANSI X3.106,
               "American National Standard for Information Systems -
               Data Link Encryption".  1983.

   [DH-X9.42]  Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC
               2631, June 1999.

   [DSS]       National Institute of Standards and Technology.  FIPS Pub
               186: Digital Signature Standard.  19 May 1994.

   [HMAC]      Krawczyk, H., "HMAC: Keyed-Hashing for Message
               Authentication", RFC 2104, February 1997.

   [MD5]       Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
               April 1992.

   [MMA]       Rescorla, E., "Preventing the Million Message Attack on
               CMS", RFC 3218, January 2002.

   [MODES]     National Institute of Standards and Technology.  FIPS Pub
               81: DES Modes of Operation.  2 December 1980.

   [NEWPKCS#1] Kaliski, B. and J. Staddon, "PKCS #1: RSA Encryption,
               Version 2.0, RFC 2437, October 1998.

   [OLDCMS]    Housley, R., "Cryptographic Message Syntax", RFC 2630,
               June 1999.

   [PKCS#1]    Kaliski, B, "PKCS #1: RSA Encryption, Version 2.0", RFC
               2437, October, 1998.

   [PKCS#5]    Kaliski, B., "PKCS #5: Password-Based Cryptography
               Specification", RFC 2898, September 2000.

   [PROFILE]   Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
               X.509 Public Key Infrastructure Certificate and
               Certificate Revocation List (CRL) Profile", RFC 3280,
               April 2002.

   [RANDOM]    Eastlake, D., Crocker, S. and J. Schiller, "Randomness
               Recommendations for Security, RFC 1750, December 1994.

   [RC2]       Rivest, R., "A Description of the RC2 (r) Encryption
               Algorithm", RFC 2268, March 1998.




Housley                     Standards Track                    [Page 19]

RFC 3370                     CMS Algorithms                  August 2002


   [SHA1]      National Institute of Standards and Technology.  FIPS Pub
               180-1: Secure Hash Standard.  17 April 1995.

   [STDWORDS]  Bradner, S., "Key Words for Use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [WRAP]      Housley, R., "Triple-DES and RC2 Key Wrapping", RFC 3217,
               December 2001.

   [X.208-88]  CCITT.  Recommendation X.208: Specification of Abstract
               Syntax Notation One (ASN.1).  1988.

   [X.209-88]  CCITT.  Recommendation X.209: Specification of Basic
               Encoding Rules for Abstract Syntax Notation One (ASN.1).
               1988.

9  Security Considerations

   The CMS provides a method for digitally signing data, digesting data,
   encrypting data, and authenticating data.  This document identifies
   the conventions for using several cryptographic algorithms for use
   with the CMS.

   Implementations must protect the signer's private key.  Compromise of
   the signer's private key permits masquerade.

   Implementations must protect the key management private key, the
   key-encryption key, and the content-encryption key.  Compromise of
   the key management private key or the key-encryption key may result
   in the disclosure of all contents protected with that key.
   Similarly, compromise of the content-encryption key may result in
   disclosure of the associated encrypted content.

   Implementations must protect the key management private key and the
   message-authentication key.  Compromise of the key management private
   key permits masquerade of authenticated data.  Similarly, compromise
   of the message-authentication key may result in undetectable
   modification of the authenticated content.

   The key management technique employed to distribute message-
   authentication keys must itself provide authentication, otherwise the
   content is delivered with integrity from an unknown source.  Neither
   RSA [PKCS#1, NEWPKCS#1] nor Ephemeral-Static Diffie-Hellman [DH-
   X9.42] provide the necessary data origin authentication.  Static-
   Static Diffie-Hellman [DH-X9.42] does provide the necessary data
   origin authentication when both the originator and recipient public
   keys are bound to appropriate identities in X.509 certificates
   [PROFILE].



Housley                     Standards Track                    [Page 20]

RFC 3370                     CMS Algorithms                  August 2002


   When more than two parties share the same message-authentication key,
   data origin authentication is not provided.  Any party that knows the
   message-authentication key can compute a valid MAC, therefore the
   content could originate from any one of the parties.

   Implementations must randomly generate content-encryption keys,
   message-authentication keys, initialization vectors (IVs), one-time
   values (such as the k value when generating a DSA signature), and
   padding.  Also, the generation of public/private key pairs relies on
   a random numbers.  The use of inadequate pseudo-random number
   generators (PRNGs) to generate cryptographic such values can result
   in little or no security.  An attacker may find it much easier to
   reproduce the PRNG environment that produced the keys, searching the
   resulting small set of possibilities, rather than brute force
   searching the whole key space.  The generation of quality random
   numbers is difficult.  RFC 1750 [RANDOM] offers important guidance in
   this area, and Appendix 3 of FIPS Pub 186 [DSS] provides one quality
   PRNG technique.

   When using key agreement algorithms or previously distributed
   symmetric key-encryption keys, a key-encryption key is used to
   encrypt the content-encryption key.  If the key-encryption and
   content-encryption algorithms are different, the effective security
   is determined by the weaker of the two algorithms.  If, for example,
   content is encrypted with 168-bit Triple-DES and the Triple-DES
   content-encryption key is wrapped with a 40-bit RC2 key, then at most
   40 bits of protection is provided.  A trivial search to determine the
   value of the 40-bit RC2 key can recover Triple-DES key, and then the
   Triple-DES key can be used to decrypt the content.  Therefore,
   implementers must ensure that key-encryption algorithms are as strong
   or stronger than content-encryption algorithms.

   RFC 3217 [WRAP] specifies key wrap algorithms used to encrypt a
   Triple-DES content-encryption key with a Triple-DES key-encryption
   key [3DES] or to encrypt a RC2 content-encryption key with a RC2
   key-encryption key [RC2].  The key wrap algorithms makes use of CBC
   mode [MODES].  These key wrap algorithms have been reviewed for use
   with Triple-DES and RC2.  They have not been reviewed for use with
   other cryptographic modes or other encryption algorithms.  Therefore,
   if a CMS implementation wishes to support ciphers in addition to
   Triple-DES or RC2, then additional key wrap algorithms need to be
   defined to support the additional ciphers.

   Implementers should be aware that cryptographic algorithms become
   weaker with time.  As new cryptanalysis techniques are developed and
   computing performance improves, the work factor to break a particular
   cryptographic algorithm will reduce.  Therefore, cryptographic




Housley                     Standards Track                    [Page 21]

RFC 3370                     CMS Algorithms                  August 2002


   algorithm implementations should be modular allowing new algorithms
   to be readily inserted.  That is, implementers should be prepared to
   regularly update the set of algorithms in their implementations.

   Users of the CMS, particularly those employing the CMS to support
   interactive applications, should be aware that RSA (PKCS #1 v1.5), as
   specified in RFC 2313 [PKCS#1], is vulnerable to adaptive chosen
   ciphertext attacks when applied for encryption purposes.
   Exploitation of this identified vulnerability, revealing the result
   of a particular RSA decryption, requires access to an oracle which
   will respond to a large number of ciphertexts (based on currently
   available results, hundreds of thousands or more), which are
   constructed adaptively in response to previously-received replies
   providing information on the successes or failures of attempted
   decryption operations.  As a result, the attack appears significantly
   less feasible to perpetrate for store-and-forward S/MIME environments
   than for directly interactive protocols.  Where the CMS constructs
   are applied as an intermediate encryption layer within an interactive
   request-response communications environment, exploitation could be
   more feasible.

   An updated version of PKCS #1 has been published, PKCS #1 Version 2.0
   [NEWPKCS#1].  This updated document supersedes RFC 2313.  PKCS #1
   Version 2.0 preserves support for the encryption padding format
   defined in PKCS #1 Version 1.5 [PKCS#1], and it also defines a new
   alternative.  To resolve the adaptive chosen ciphertext
   vulnerability, the PKCS #1 Version 2.0 specifies and recommends use
   of Optimal Asymmetric Encryption Padding (OAEP) when RSA encryption
   is used to provide confidentiality.  Designers of protocols and
   systems employing CMS for interactive environments should either
   consider usage of OAEP, or should ensure that information which could
   reveal the success or failure of attempted PKCS #1 Version 1.5
   decryption operations is not provided.  Support for OAEP will likely
   be added to a future version of the CMS algorithm specification.

   See RFC 3218 [MMA] for more information about thwarting the adaptive
   chosen ciphertext vulnerability in PKCS #1 Version 1.5
   implementations.

10 Acknowledgments

   This document is the result of contributions from many professionals.
   I appreciate the hard work of all members of the IETF S/MIME Working
   Group.  I extend a special thanks to Rich Ankney, Simon Blake-Wilson,
   Tim Dean, Steve Dusse, Carl Ellison, Peter Gutmann, Bob Jueneman,
   Stephen Henson, Paul Hoffman, Scott Hollenbeck, Don Johnson, Burt
   Kaliski, John Linn, John Pawling, Blake Ramsdell, Francois Rousseau,
   Jim Schaad, and Dave Solo for their efforts and support.



Housley                     Standards Track                    [Page 22]

RFC 3370                     CMS Algorithms                  August 2002


11 Author Address

   Russell Housley
   RSA Laboratories
   918 Spring Knoll Drive
   Herndon, VA 20170
   EMail: [e-mail]












































Housley                     Standards Track                    [Page 23]

RFC 3370                     CMS Algorithms                  August 2002


12.  Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   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
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Housley                     Standards Track                    [Page 24]