Network Working Group                                           C. Adams
Request for Comments: 2984                          Entrust Technologies
Category: Standards Track                                   October 2000
        
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

CAST-128加密算法在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.

本文件规定了互联网社区的互联网标准跟踪协议,并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态,请参考当前版本的“互联网官方协议标准”(STD 1)。本备忘录的分发不受限制。

Copyright Notice

版权公告

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

版权所有(C)互联网协会(2000年)。版权所有。

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.

本文档指定如何将CAST-128(RFC2144)作为对称加密的附加算法合并到S/MIME加密消息语法(CMS)中。提供了相关的OID和处理步骤,以便CAST-128可以包括在CMS规范(RFC2630)中,用于对称内容和密钥加密。

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].

本文件中的关键词“必须”、“不得”、“必需”、“应该”、“不应该”、“建议”、“可以”和“可选”(大写,如图所示)应按照[RFC2119]中所述进行解释。

1. Motivation
1. 动机

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.

S/MIME(安全/多用途Internet邮件扩展)[SMIME2,SMIME3]是一组安全传输MIME对象的规范。在当前(S/MIME v3)规范中,强制实现内容加密和密钥加密的对称算法是三重DES(3DES)。虽然这在许多情况下是完全可以接受的,因为3DES的安全性通常被认为很高,但对于某些环境,3DES可能会被认为太慢。在一定程度上,为了帮助缓解此类性能问题,S/MIME允许使用任意数量的(可选)附加算法进行对称内容和密钥加密。

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

CAST-128加密算法[RFC2144,Adams]是一种经过充分研究的对称密码,具有许多吸引人的特性,包括相对较高的性能和可变的密钥大小(从40位到128位)。这是免费的版税和许可证免费的

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.

世界范围内的商业和非商业用途[IPR],因此广泛应用于互联网上的许多应用中。因此,它似乎是一种适用于S/MIME的可选加密算法。

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

本文档描述了如何在S/MIME CMS规范中使用CAST-128。

2. Specification
2. 规格

This section provides the OIDs and processing information necessary for CAST-128 to be used for content and key encryption in CMS.

本节提供了在CMS中用于内容和密钥加密的CAST-128所需的OID和处理信息。

2.1 OIDs for Content and Key Encryption
2.1 用于内容和密钥加密的OID

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.

CAST-128通过提供两个唯一的对象标识符(OID)添加到CMS中的可选对称加密算法集中。一个OID定义内容加密算法,另一个定义密钥加密算法。因此,CMS代理可以通过选择相应的对象标识符、提供所需参数并启动程序代码,将CAST-128应用于内容或密钥加密。

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).

对于内容加密,建议在密码块链接(CBC)模式下使用CAST-128。密钥长度是可变的(以1个八位字节为增量,从40位到128位)。

The CAST-128 content-encryption algorithm in CBC mode has the following object identifier:

CBC模式下的CAST-128内容加密算法具有以下对象标识符:

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

与此对象标识符关联的参数包含初始向量IV和密钥长度:

     cast5CBCParameters ::= SEQUENCE {
         iv         OCTET STRING DEFAULT 0,
         -- Initialization vector
         keyLength  INTEGER
         -- Key length, in bits
     }
        
     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].

有关IV使用的意见,请参见[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.

第2.2节规定了用于使用CAST-128密钥加密密钥加密/解密CAST-128内容加密密钥的密钥包装/展开过程。密钥加密密钥的生成和分发超出了本文档的范围。

The CAST-128 key-encryption algorithm has the following object identifier:

CAST-128密钥加密算法具有以下对象标识符:

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

与此对象标识符关联的参数仅包含密钥长度(因为密钥包装过程本身定义了如何以及何时使用IV):

     cast5CMSkeywrapParameter ::= INTEGER
       -- key length, in bits
        
     cast5CMSkeywrapParameter ::= INTEGER
       -- key length, in bits
        
2.2 Key Wrapping and Unwrapping
2.2 键的包装和展开

CAST-128 key wrapping and unwrapping is done in conformance with CMS [RFC2630].

CAST-128密钥包装和解包按照CMS[RFC2630]进行。

2.2.1 CAST-128 Key Wrap
2.2.1 CAST-128密钥包

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).

带CAST-128的钥匙包装与[RFC2630]第12.6.1节和第12.6.4节相同,在第12.6.4节的引言中,“RC2”替换为“CAST-128”。只有128位CAST-128密钥可以用作密钥加密密钥,并且必须在CAST5CMSKEWrapparameter设置为128的情况下使用。建议内容加密密钥的大小和密钥加密密钥的大小相等(因为内容的安全性最多为这两个值中的较小值)。

2.2.2 CAST-128 Key Unwrap
2.2.2 CAST-128密钥展开

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.

使用CAST-128展开钥匙与[RFC2630]第12.6.1节和第12.6.5节相同,在第12.6.5节的引言中,“RC2”替换为“CAST-128”。

3. Using CAST-128 in S/MIME Clients
3. 在S/MIME客户端中使用CAST-128

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

S/MIME客户端应通过使用S/MIME capabilities属性来宣布其支持的加密函数集。此属性提供加密函数OID的部分列表,必须由客户端签名。函数的OID应按功能类别进行逻辑分隔,并且必须根据其偏好进行排序。如果要求S/MIME客户端支持使用CAST-128的对称加密,则“能力”属性必须包含上述对称算法类别中指定的cast5CBC OID。必须使用与此OID关联的参数(参见上文)来指示支持的密钥长度。例如,当支持的密钥长度为128位时

SMIMECapability SEQUENCE representing CAST-128 MUST be DER-encoded as the following hexadecimal string: 301106092A864886F67D07420A300402020080.

表示CAST-128的SMIMECapability序列必须按以下十六进制字符串进行DER编码:301106092A864886F67D07420A300402020800。

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.

当发送代理创建加密消息时,它必须决定使用哪种类型的加密算法。一般来说,决策过程涉及从收件人收到的消息中包含的功能列表中获得的信息,以及其他信息,如私人协议、用户偏好、法律限制等。如果用户需要CAST-128进行对称加密,则发送端和接收端的S/MIME客户端都必须支持CAST-128,并且必须在用户首选项中进行设置。

4. Security Considerations
4. 安全考虑

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).

本文件规定使用CAST-128对称密码加密CMS消息的内容,并加密用于加密CMS消息内容的对称密钥。尽管CAST-128允许使用可变长度的密钥,但必须认识到,较小的密钥大小(例如,40、56或64位)对于某些环境来说可能是不可接受的弱密钥。始终建议使用较大的密钥大小(例如128位)(在相关导入、导出或其他法律允许的情况下)。还建议内容加密密钥的大小和密钥加密密钥的大小相等(因为内容的安全性最多为这两个值中的较小值)。

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.

[Adams]C.Adams,“使用CAST设计程序构造对称密码”,《设计、代码和密码学》,第12卷,第3期,1997年11月,第71-104页。

   [IPR]     See the "IETF Page of Intellectual Property Rights
             Notices", http://www.ietf.cnri.reston.va.us/ipr.html
        
   [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.

[RFC2144]Adams,C.,“CAST-128加密算法”,RFC2144,1997年5月。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,1997年3月。

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

[RFC2630]Housley,R.,“加密消息语法”,RFC2630,1999年6月。

[SMIME2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L. and L. Repka, "S/MIME Version 2 Message Specification", RFC 2311, March 1998.

[SMIME2]Dusse,S.,Hoffman,P.,Ramsdell,B.,Lundblade,L.和L.Repka,“S/MIME版本2消息规范”,RFC 23111998年3月。

Dusse, S., Hoffman, P., Ramsdell, B. and J. Weinstein, "S/MIME Version 2 Certificate Handling", RFC 2312, March 1998.

Dusse,S.,Hoffman,P.,Ramsdell,B.和J.Weinstein,“S/MIME版本2证书处理”,RFC 2312,1998年3月。

[SMIME3] Ramsdell, B., "S/MIME Version 3 Certificate Handling", RFC 2632, June 1999.

[SMIME3]Ramsdell,B.,“S/MIME版本3证书处理”,RFC 2632,1999年6月。

Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.

Ramsdell,B.,“S/MIME版本3消息规范”,RFC 2633,1999年6月。

Author's Address

作者地址

Carlisle Adams Entrust Technologies 1000 Innovation Drive, Kanata, Ontario, Canada K2K 3E7

加拿大安大略省卡纳塔市卡莱尔·亚当斯委托技术1000创新大道K2K 3E7

   EMail: cadams@entrust.com
        
   EMail: cadams@entrust.com
        

Full Copyright Statement

完整版权声明

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

版权所有(C)互联网协会(2000年)。版权所有。

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.

RFC编辑功能的资金目前由互联网协会提供。