1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc2984.txt b/doc/rfc/rfc2984.txt
new file mode 100644
index 0000000..6ad1024
--- /dev/null
+++ b/doc/rfc/rfc2984.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                           C. Adams
+Request for Comments: 2984                          Entrust Technologies
+Category: Standards Track                                   October 2000
+
+
+            Use of the CAST-128 Encryption Algorithm in CMS
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   This document specifies how to incorporate CAST-128 (RFC2144) into
+   the S/MIME Cryptographic Message Syntax (CMS) as an additional
+   algorithm for symmetric encryption.  The relevant OIDs and processing
+   steps are provided so that CAST-128 may be included in the CMS
+   specification (RFC2630) for symmetric content and key encryption.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
+   "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase,
+   as shown) are to be interpreted as described in [RFC2119].
+
+1. Motivation
+
+   S/MIME (Secure/Multipurpose Internet Mail Extensions) [SMIME2,
+   SMIME3] is a set of specifications for the secure transport of MIME
+   objects.  In the current (S/MIME v3) specifications the mandatory-
+   to-implement symmetric algorithm for content encryption and key
+   encryption is triple-DES (3DES).  While this is perfectly acceptable
+   in many cases because the security of 3DES is generally considered to
+   be high, for some environments 3DES may be seen to be too slow.  In
+   part to help alleviate such performance concerns, S/MIME has allowed
+   any number of (optional) additional algorithms to be used for
+   symmetric content and key encryption.
+
+   The CAST-128 encryption algorithm [RFC2144, Adams] is a well-studied
+   symmetric cipher that has a number of appealing features, including
+   relatively high performance and a variable key size (from 40 bits to
+   128 bits).  It is available royalty-free and license-free for
+
+
+
+Adams                       Standards Track                     [Page 1]
+
+RFC 2984                    CAST-128 in CMS                 October 2000
+
+
+   commercial and non-commercial uses worldwide [IPR], and therefore is
+   widely used in a number of applications around the Internet.  It thus
+   seems to be a suitable optional encryption algorithm for S/MIME.
+
+   This document describes how to use CAST-128 within the S/MIME CMS
+   specification.
+
+2. Specification
+
+   This section provides the OIDs and processing information necessary
+   for CAST-128 to be used for content and key encryption in CMS.
+
+2.1 OIDs for Content and Key Encryption
+
+   CAST-128 is added to the set of optional symmetric encryption
+   algorithms in CMS by providing two unique object identifiers (OIDs).
+   One OID defines the content encryption algorithm and the other
+   defines the key encryption algorithm.  Thus a CMS agent can apply
+   CAST-128 either for content or key encryption by selecting the
+   corresponding object identifier, supplying the required parameter,
+   and starting the program code.
+
+   For content encryption the use of CAST-128 in cipher block chaining
+   (CBC) mode is RECOMMENDED.  The key length is variable (from 40 to
+   128 bits in 1-octet increments).
+
+   The CAST-128 content-encryption algorithm in CBC mode has the
+   following object identifier:
+
+     cast5CBC OBJECT IDENTIFIER ::= {iso(1) member-body(2)
+         us(840) nt(113533) nsn(7) algorithms(66) 10}
+
+   The parameter associated with this object identifier contains the
+   initial vector IV and the key length:
+
+     cast5CBCParameters ::= SEQUENCE {
+         iv         OCTET STRING DEFAULT 0,
+         -- Initialization vector
+         keyLength  INTEGER
+         -- Key length, in bits
+     }
+
+   Comments regarding the use of the IV may be found in [RFC2144].
+
+   The key-wrap/unwrap procedures used to encrypt/decrypt a CAST-128
+   content-encryption key with a CAST-128 key-encryption key are
+   specified in Section 2.2.  Generation and distribution of key-
+   encryption keys are beyond the scope of this document.
+
+
+
+Adams                       Standards Track                     [Page 2]
+
+RFC 2984                    CAST-128 in CMS                 October 2000
+
+
+   The CAST-128 key-encryption algorithm has the following object
+   identifier:
+
+     cast5CMSkeywrap OBJECT IDENTIFIER ::= { iso(1)
+         member-body(2) us(840) nt(113533) nsn(7)
+         algorithms(66) 15}
+
+   The parameter associated with this object identifier contains only
+   the key length (because the key wrapping procedure itself defines how
+   and when to use an IV):
+
+     cast5CMSkeywrapParameter ::= INTEGER
+       -- key length, in bits
+
+2.2 Key Wrapping and Unwrapping
+
+   CAST-128 key wrapping and unwrapping is done in conformance with CMS
+   [RFC2630].
+
+2.2.1 CAST-128 Key Wrap
+
+   Key wrapping with CAST-128 is identical to [RFC2630], Sections 12.6.1
+   and 12.6.4, with "RC2" replaced by "CAST-128" in the introduction to
+   12.6.4.  Only 128-bit CAST-128 keys may be used as key-encryption
+   keys, and they MUST be used with the cast5CMSkeywrapParameter set to
+   128.  It is RECOMMENDED that the size of the content-encryption key
+   and the size of the key-encryption key be equal (since the security
+   of the content will be at most the smaller of these two values).
+
+2.2.2 CAST-128 Key Unwrap
+
+   Key unwrapping with CAST-128 is identical to [RFC2630], Sections
+   12.6.1 and 12.6.5, with "RC2" replaced by "CAST-128" in the
+   introduction to 12.6.5.
+
+3. Using CAST-128 in S/MIME Clients
+
+   An S/MIME client SHOULD announce the set of cryptographic functions
+   it supports by using the S/MIME capabilities attribute.  This
+   attribute provides a partial list of OIDs of cryptographic functions
+   and MUST be signed by the client.  The functions' OIDs SHOULD be
+   logically separated in functional categories and MUST be ordered with
+   respect to their preference.  If an S/MIME client is required to
+   support symmetric encryption with CAST-128, the capabilities
+   attribute MUST contain the cast5CBC OID specified above in the
+   category of symmetric algorithms.  The parameter associated with this
+   OID (see above) MUST be used to indicate supported key length.  For
+   example, when the supported key length is 128 bits, the
+
+
+
+Adams                       Standards Track                     [Page 3]
+
+RFC 2984                    CAST-128 in CMS                 October 2000
+
+
+   SMIMECapability SEQUENCE representing CAST-128 MUST be DER-encoded as
+   the following hexadecimal string:
+       301106092A864886F67D07420A300402020080.
+
+   When a sending agent creates an encrypted message, it has to decide
+   which type of encryption algorithm to use.  In general the decision
+   process involves information obtained from the capabilities lists
+   included in messages received from the recipient, as well as other
+   information such as private agreements, user preferences, legal
+   restrictions, and so on. If users require CAST-128 for symmetric
+   encryption, it MUST be supported by the S/MIME clients on both the
+   sending and receiving side, and it MUST be set in the user
+   preferences.
+
+4. Security Considerations
+
+   This document specifies the use of the CAST-128 symmetric cipher for
+   encrypting the content of a CMS message and for encrypting the
+   symmetric key used to encrypt the content of a CMS message. Although
+   CAST-128 allows keys of variable length to be used, it must be
+   recognized that smaller key sizes (e.g., 40, 56, or 64 bits) may be
+   unacceptably weak for some environments.  The use of larger key sizes
+   (e.g., 128 bits) is always RECOMMENDED (when relevant import, export,
+   or other laws permit).  It is also RECOMMENDED that the size of the
+   content-encryption key and the size of the key-encryption key be
+   equal (since the security of the content will be at most the smaller
+   of these two values).
+
+References
+
+   [Adams]   C. Adams, "Constructing Symmetric Ciphers using the CAST
+             Design Procedure", Designs, Codes, and Cryptography,
+             vol.12, no.3, November 1997, pp.71-104.
+
+   [IPR]     See the "IETF Page of Intellectual Property Rights
+             Notices", http://www.ietf.cnri.reston.va.us/ipr.html
+
+   [RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144,
+             May 1997.
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630, June
+             1999.
+
+
+
+
+
+
+Adams                       Standards Track                     [Page 4]
+
+RFC 2984                    CAST-128 in CMS                 October 2000
+
+
+   [SMIME2]  Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L. and L.
+             Repka, "S/MIME Version 2 Message Specification", RFC 2311,
+             March 1998.
+
+             Dusse, S., Hoffman, P., Ramsdell, B. and J. Weinstein,
+             "S/MIME Version 2 Certificate Handling", RFC 2312, March
+             1998.
+
+   [SMIME3]  Ramsdell, B., "S/MIME Version 3 Certificate Handling", RFC
+             2632, June 1999.
+
+             Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
+             2633, June 1999.
+
+Author's Address
+
+   Carlisle Adams
+   Entrust Technologies
+   1000 Innovation Drive,
+   Kanata, Ontario, Canada K2K 3E7
+
+   EMail: cadams@entrust.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Adams                       Standards Track                     [Page 5]
+
+RFC 2984                    CAST-128 in CMS                 October 2000
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Adams                       Standards Track                     [Page 6]
+