draft-ietf-smime-cast-128-01.txt   rfc2984.txt 
Internet Draft Carlisle Adams (Entrust Technologies) Network Working Group C. Adams
S/MIME Working Group Request for Comments: 2984 Entrust Technologies
Expires in 6 months March 2000 Category: Standards Track October 2000
Use of the CAST-128 Encryption Algorithm in CMS Use of the CAST-128 Encryption Algorithm in CMS
<draft-ietf-smime-cast-128-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document specifies an Internet standards track protocol for the
all provisions of Section 10 of RFC2026. Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Internet-Drafts are working documents of the Internet Engineering Official Protocol Standards" (STD 1) for the standardization state
Task Force (IETF), its areas, and its working groups. Note that other and status of this protocol. Distribution of this memo is unlimited.
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts 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 Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire in September, 2000. Comments or
suggestions for improvement may be made on the "ietf-smime" mailing
list, or directly to the author.
Copyright Notice Copyright Notice
Copyright (C)The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract Abstract
This document specifies how to incorporate CAST-128 [RFC2144] into This document specifies how to incorporate CAST-128 (RFC2144) into
the S/MIME Cryptographic Message Syntax (CMS) as an additional the S/MIME Cryptographic Message Syntax (CMS) as an additional
algorithm for symmetric encryption. The relevant OIDs and processing algorithm for symmetric encryption. The relevant OIDs and processing
steps are provided so that CAST-128 may be included in the CMS steps are provided so that CAST-128 may be included in the CMS
specification [RFC2630] for symmetric content and key encryption. specification (RFC2630) for symmetric content and key encryption.
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase,
as shown) are to be interpreted as described in [RFC2119]. as shown) are to be interpreted as described in [RFC2119].
1. Motivation 1. Motivation
S/MIME (Secure/Multipurpose Internet Mail Extensions) [SMIME2, S/MIME (Secure/Multipurpose Internet Mail Extensions) [SMIME2,
SMIME3] is a set of specifications for the secure transport of MIME SMIME3] is a set of specifications for the secure transport of MIME
objects. In the current (S/MIME v3) specifications the mandatory- objects. In the current (S/MIME v3) specifications the mandatory-
to-implement symmetric algorithm for content encryption and key to-implement symmetric algorithm for content encryption and key
encryption is triple-DES (3DES). While this is perfectly acceptable encryption is triple-DES (3DES). While this is perfectly acceptable
in many cases because the security of 3DES is generally considered to 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 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 part to help alleviate such performance concerns, S/MIME has allowed
any number of (optional) additional algorithms to be used for any number of (optional) additional algorithms to be used for
symmetric content and key encryption. symmetric content and key encryption.
The CAST-128 encryption algorithm [RFC2144, Adams] is a well-studied The CAST-128 encryption algorithm [RFC2144, Adams] is a well-studied
symmetric cipher that has a number of appealing features, including symmetric cipher that has a number of appealing features, including
relatively high performance and a variable key size (from 40 bits relatively high performance and a variable key size (from 40 bits to
to 128 bits). It is available royalty-free and license-free for 128 bits). It is available royalty-free and license-free for
commercial and non-commercial uses worldwide [IPR], and therefore commercial and non-commercial uses worldwide [IPR], and therefore is
is widely used in a number of applications around the Internet. It widely used in a number of applications around the Internet. It thus
thus seems to be a suitable optional encryption algorithm for S/MIME. seems to be a suitable optional encryption algorithm for S/MIME.
This document describes how to use CAST-128 within the S/MIME CMS This document describes how to use CAST-128 within the S/MIME CMS
specification. specification.
2. Specification 2. Specification
This section provides the OIDs and processing information necessary This section provides the OIDs and processing information necessary
for CAST-128 to be used for content and key encryption in CMS. for CAST-128 to be used for content and key encryption in CMS.
2.1 OIDs for Content and Key Encryption 2.1 OIDs for Content and Key Encryption
CAST-128 is added to the set of optional symmetric encryption CAST-128 is added to the set of optional symmetric encryption
algorithms in CMS by providing two unique object identifiers algorithms in CMS by providing two unique object identifiers (OIDs).
(OIDs). One OID defines the content encryption algorithm and the One OID defines the content encryption algorithm and the other
other defines the key encryption algorithm. Thus a CMS agent can defines the key encryption algorithm. Thus a CMS agent can apply
apply CAST-128 either for content or key encryption by selecting the CAST-128 either for content or key encryption by selecting the
corresponding object identifier, supplying the required parameter, and corresponding object identifier, supplying the required parameter,
starting the program code. and starting the program code.
For content encryption the use of CAST-128 in cipher block chaining 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 (CBC) mode is RECOMMENDED. The key length is variable (from 40 to
bits in 1-octet increments). 128 bits in 1-octet increments).
The CAST-128 content-encryption algorithm in CBC mode has the The CAST-128 content-encryption algorithm in CBC mode has the
following object identifier: following object identifier:
cast5CBC OBJECT IDENTIFIER ::= {iso(1) member-body(2) cast5CBC OBJECT IDENTIFIER ::= {iso(1) member-body(2)
us(840) nt(113533) nsn(7) algorithms(66) 10} us(840) nt(113533) nsn(7) algorithms(66) 10}
The parameter associated with this object identifier contains the The parameter associated with this object identifier contains the
initial vector IV and the key length: initial vector IV and the key length:
cast5CBCParameters ::= SEQUENCE { cast5CBCParameters ::= SEQUENCE {
iv OCTET STRING DEFAULT 0, iv OCTET STRING DEFAULT 0,
-- Initialization vector -- Initialization vector
keyLength INTEGER keyLength INTEGER
-- Key length, in bits -- Key length, in bits
} }
Comments regarding the use of the IV may be found in [RFC2144]. Comments regarding the use of the IV may be found in [RFC2144].
The key-wrap/unwrap procedures used to encrypt/decrypt a CAST-128 The key-wrap/unwrap procedures used to encrypt/decrypt a CAST-128
content-encryption key with a CAST-128 key-encryption key are content-encryption key with a CAST-128 key-encryption key are
specified in the Section 2.2. Generation and distribution of specified in Section 2.2. Generation and distribution of key-
key-encryption keys are beyond the scope of this document. encryption keys are beyond the scope of this document.
The CAST-128 key-encryption algorithm has the following object The CAST-128 key-encryption algorithm has the following object
identifier: identifier:
cast5CMSkeywrap OBJECT IDENTIFIER ::= { iso(1) cast5CMSkeywrap OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) nt(113533) nsn(7) member-body(2) us(840) nt(113533) nsn(7)
algorithms(66) 15} algorithms(66) 15}
The parameter associated with this object identifier contains only The parameter associated with this object identifier contains only
the key length (because the key wrapping procedure itself defines the key length (because the key wrapping procedure itself defines how
how and when to use an IV): and when to use an IV):
cast5CMSkeywrapParameter ::= INTEGER cast5CMSkeywrapParameter ::= INTEGER
-- key length, in bits -- key length, in bits
2.2 Key Wrapping and Unwrapping 2.2 Key Wrapping and Unwrapping
CAST-128 key wrapping and unwrapping is done in conformance with CMS CAST-128 key wrapping and unwrapping is done in conformance with CMS
[RFC2630]. [RFC2630].
2.2.1 CAST-128 Key Wrap 2.2.1 CAST-128 Key Wrap
Key wrapping with CAST-128 is identical to [RFC2630], Sections 12.6.1 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 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 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 keys, and they MUST be used with the cast5CMSkeywrapParameter set to
128. It is RECOMMENDED that the size of the content-encryption key 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 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). of the content will be at most the smaller of these two values).
2.2.2 CAST-128 Key Unwrap 2.2.2 CAST-128 Key Unwrap
Key unwrapping with CAST-128 is identical to [RFC2630], Sections 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 12.6.1 and 12.6.5, with "RC2" replaced by "CAST-128" in the
introduction to 12.6.5. introduction to 12.6.5.
3. Using CAST-128 in S/MIME Clients 3. Using CAST-128 in S/MIME Clients
An S/MIME client SHOULD announce the set of cryptographic functions An S/MIME client SHOULD announce the set of cryptographic functions
it supports by using the S/MIME capabilities attribute. This it supports by using the S/MIME capabilities attribute. This
attribute provides a partial list of OIDs of cryptographic functions attribute provides a partial list of OIDs of cryptographic functions
and MUST be signed by the client. The functions' OIDs SHOULD be and MUST be signed by the client. The functions' OIDs SHOULD be
logically separated in functional categories and MUST be ordered with logically separated in functional categories and MUST be ordered with
respect to their preference. If an S/MIME client is required to respect to their preference. If an S/MIME client is required to
support symmetric encryption with CAST-128, the capabilities attribute support symmetric encryption with CAST-128, the capabilities
MUST contain the cast5cbc OID specified above in the category of attribute MUST contain the cast5CBC OID specified above in the
symmetric algorithms. The parameter associated with this OID (see category of symmetric algorithms. The parameter associated with this
above) MAY be used to indicate supported key length. OID (see above) MUST be used to indicate supported key length. For
example, when the supported key length is 128 bits, the
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 When a sending agent creates an encrypted message, it has to decide
which type of encryption algorithm to use. In general the decision which type of encryption algorithm to use. In general the decision
process involves information obtained from the capabilities lists process involves information obtained from the capabilities lists
included in messages received from the recipient, as well as other included in messages received from the recipient, as well as other
information such as private agreements, user preferences, legal information such as private agreements, user preferences, legal
restrictions, and so on. If users require CAST-128 for symmetric restrictions, and so on. If users require CAST-128 for symmetric
encryption, it MUST be supported by the S/MIME clients on both the 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 sending and receiving side, and it MUST be set in the user
preferences. preferences.
4. Security Considerations 4. Security Considerations
This document specifies the use of the CAST-128 symmetric cipher for This document specifies the use of the CAST-128 symmetric cipher for
encrypting the content of a CMS message and for encrypting the encrypting the content of a CMS message and for encrypting the
symmetric key used to encrypt the content of a CMS message. symmetric key used to encrypt the content of a CMS message. Although
Although CAST-128 allows keys of variable length to be used, it must CAST-128 allows keys of variable length to be used, it must be
be recognized that smaller key sizes (e.g., 40, 56, or 64 bits) may 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 unacceptably weak for some environments. The use of larger key sizes
(e.g., 128 bits) is always RECOMMENDED (when relevant import, export, (e.g., 128 bits) is always RECOMMENDED (when relevant import, export,
or other laws permit). It is also RECOMMENDED that the size of the 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 content-encryption key and the size of the key-encryption key be
(since the security of the content will be at most the smaller of equal (since the security of the content will be at most the smaller
these two values). of these two values).
References References
[Adams] C. Adams, "Constructing Symmetric Ciphers using the CAST [Adams] C. Adams, "Constructing Symmetric Ciphers using the CAST
Design Procedure", Designs, Codes, and Cryptography, vol.12, Design Procedure", Designs, Codes, and Cryptography,
no.3, November 1997, pp.71-104. vol.12, no.3, November 1997, pp.71-104.
[IPR] See the "IETF Page of Intellectual Property Rights Notices", [IPR] See the "IETF Page of Intellectual Property Rights
http://www.ietf.cnri.reston.va.us/ipr.html Notices", http://www.ietf.cnri.reston.va.us/ipr.html
[RFC2144] C. Adams, "The CAST-128 Encryption Algorithm", Internet [RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144,
Request for Comments RFC 2144, May 1997. May 1997.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", Internet Request for Comments RFC 2119, Requirement Levels", BCP 14, RFC 2119, March 1997.
March 1997.
[RFC2630] R. Housley, "Cryptographic Message Syntax", Internet [RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630, June
Request for Comments RFC 2630, June 1999. 1999.
[SMIME2] S. Dusse, P. Hoffman, B. Ramsdell, L. Lundblade, L. Repka, [SMIME2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L. and L.
"S/MIME Version 2 Message Specification", Internet Request Repka, "S/MIME Version 2 Message Specification", RFC 2311,
for Comments RFC 2311, March 1998. March 1998.
S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein, "S/MIME
Version 2 Certificate Handling", Internet Request for
Comments RFC 2312, March 1998.
[SMIME3] B. Ramsdell, "S/MIME Version 3 Certificate Handling", Dusse, S., Hoffman, P., Ramsdell, B. and J. Weinstein,
Internet Request for Comments RFC 2632, June 1999. "S/MIME Version 2 Certificate Handling", RFC 2312, March
B. Ramsdell, "S/MIME Version 3 Message Specification", 1998.
Internet Request for Comments RFC 2633, June 1999.
[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 Author's Address
Carlisle Adams Carlisle Adams
Entrust Technologies Entrust Technologies
750 Heron Road, Suite E08, 1000 Innovation Drive,
Ottawa, Ontario, Canada K1V 1A7 Kanata, Ontario, Canada K2K 3E7
E-Mail: cadams@entrust.com
EMail: cadams@entrust.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
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 are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this 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
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 40 change blocks. 
178 lines changed or deleted 167 lines changed or added

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