RFC 2984

RFC 2984: Use of the CAST-128 Encryption Algorithm in CMS 🎀

okay bestie, this one is all about CAST-128 getting a seat at the table in S/MIME's CMS. It's a Standards Track doc from October 2000, written by C. Adams at Entrust Technologies 💅. The header doesn't list any RFCs it obsoletes or updates, so it's just vibing on its own ✨.

---

Status of this Memo 📜

This doc is an Internet standards track protocol for the Internet community, and it's basically asking for your thoughts and suggestions 💬. If you want to know where this protocol stands in the standardization process, check the current edition of "Internet Official Protocol Standards" (STD 1). Distribution is unlimited, so share away 🦋.

Copyright Notice ©

Copyright (C) The Internet Society (2000). All Rights Reserved. 🌸

Abstract 🔮

So this doc explains how to add CAST-128 (RFC2144) to the S/MIME Cryptographic Message Syntax (CMS) as an extra algorithm for symmetric encryption 🔐. It gives you the OIDs and processing steps so CAST-128 can show up in the CMS spec (RFC2630) for both content and key encryption, no cap 💜.

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 ✨

Okay so S/MIME (Secure/Multipurpose Internet Mail Extensions) [SMIME2, SMIME3] is a set of specs for securely transporting MIME objects 📬. In the current S/MIME v3 specs, the mandatory-to-implement symmetric algorithm for content and key encryption is triple-DES (3DES) 🍓. Honestly 3DES is totally fine in lots of cases, since it's generally considered to be high security. But in some environments it may be seen as too slow 🐢. To help with those performance worries, S/MIME has allowed any number of (optional) extra algorithms for symmetric content and key encryption 🌈.

CAST-128 [RFC2144, Adams] is a well-studied symmetric cipher with some seriously appealing features, like pretty high performance and a variable key size (anywhere from 40 bits to 128 bits) 🔥. It's royalty-free and license-free for commercial and non-commercial uses worldwide [IPR], so it's already all over the place in lots of Internet applications 🌍. That makes it a suitable optional encryption algorithm for S/MIME, and honestly it's giving main character energy 👑.

This document describes how to use CAST-128 within the S/MIME CMS specification 🧚.

2. Specification 💅

This section gives you the OIDs and processing info you need for CAST-128 to be used for content and key encryption in CMS 💖.

2.1 OIDs for Content and Key Encryption 🦋

CAST-128 joins the set of optional symmetric encryption algorithms in CMS by getting two unique object identifiers (OIDs) 🪪. One OID is for the content encryption algorithm and the other is for the key encryption algorithm. So a CMS agent can use CAST-128 for content or key encryption just by picking the right object identifier, supplying the required parameter, and starting the program code 💜.

For content encryption, using 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 this object identifier:

  cast5CBC OBJECT IDENTIFIER ::= {iso(1) member-body(2)
      us(840) nt(113533) nsn(7) algorithms(66) 10}

The parameter tied to this OID holds the initial vector IV and the key length:

  cast5CBCParameters ::= SEQUENCE {
      iv         OCTET STRING DEFAULT 0,
      -- Initialization vector
      keyLength  INTEGER
      -- Key length, in bits
  }

If you want the tea on how to handle the IV, check out [RFC2144] 🫶.

The key-wrap and unwrap procedures for encrypting and decrypting a CAST-128 content-encryption key with a CAST-128 key-encryption key are in Section 2.2 😤. How key-encryption keys get generated and distributed is out of scope for this doc 🙈.

The CAST-128 key-encryption algorithm has this object identifier:

  cast5CMSkeywrap OBJECT IDENTIFIER ::= { iso(1)
      member-body(2) us(840) nt(113533) nsn(7)
      algorithms(66) 15}

This parameter only carries the key length, since the key wrapping procedure itself decides 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 follows CMS [RFC2630], period 💅.

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" swapped for "CAST-128" in the intro 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 content-encryption key and the key-encryption key be the same size, since the security of the content will be at most the smaller of those 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" swapped for "CAST-128" in the intro 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 gives a partial list of OIDs of cryptographic functions, and it MUST be signed by the client ✍️. The functions' OIDs SHOULD be logically separated into functional categories, and they MUST be ordered by preference 🗂️.

If an S/MIME client is required to support symmetric encryption with CAST-128, the capabilities attribute MUST contain the cast5CBC OID from above in the category of symmetric algorithms 🔑. The parameter tied to this OID (see above) MUST be used to indicate the supported key length 📏. For example, when the supported key length is 128 bits, the SMIMECapability SEQUENCE representing CAST-128 MUST be DER-encoded as this hexadecimal string:

    301106092A864886F67D07420A300402020080

When a sending agent creates an encrypted message, it has to decide which encryption algorithm to use 🤔. The decision usually pulls from the capabilities lists in messages received from the recipient, plus other stuff like 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 doc specifies using the CAST-128 symmetric cipher to encrypt the content of a CMS message and to encrypt the symmetric key used for that content 🫣. CAST-128 allows variable-length keys, but you have to recognize that smaller key sizes (e.g., 40, 56, or 64 bits) may be unacceptably weak for some environments 😱. Using larger key sizes (e.g., 128 bits) is always RECOMMENDED, when relevant import, export, or other laws permit 🛡️. It is also RECOMMENDED that the content-encryption key and the key-encryption key be the same size, since the security of the content will be at most the smaller of those 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.

[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

Full Copyright Statement ⚖️

Copyright (C) The Internet Society (2000). All Rights Reserved. 🌷

This document, and translations of it, may be copied and handed out to others 📄. Derivative works that comment on or explain it, or help with implementing it, may be prepared, copied, published, and distributed, in whole or in part, with no restrictions at all 🎉, as long as the above copyright notice and this paragraph are on all those copies and derivative works 🫶. The document itself may not be modified in any way, such as by removing the copyright notice or the references to the Internet Society or other Internet organizations 🚫. The exception is when it's needed for developing Internet standards, in which case the copyright procedures in the Internet Standards process must be followed, or when it's being translated into languages other than English 🌍.

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

This document and the information in it is provided "AS IS", and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED 😬. That includes, but isn't limited to, any warranty that using the information here won't infringe any rights, and 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 💜.