RFC2984 日本語訳

2984 Use of the CAST-128 Encryption Algorithm in CMS. C. Adams. October 2000. (Format: TXT=11591 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                           C. Adams
Request for Comments: 2984                          Entrust Technologies
Category: Standards Track                                   October 2000

コメントを求めるワーキンググループC.アダムスの要求をネットワークでつないでください: 2984は技術カテゴリをゆだねます: 標準化過程2000年10月

            Use of the CAST-128 Encryption Algorithm in CMS

cmにおけるキャスト-128暗号化アルゴリズムの使用

Status of this Memo

この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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

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

Copyright(C)インターネット協会(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.

このドキュメントは左右対称の暗号化のための追加アルゴリズムとしてS/MIME Cryptographic Message Syntax(CMS)にキャスト-128(RFC2144)を組み入れる方法を指定します。 左右対称の内容と主要な暗号化のためのCMS仕様(RFC2630)にキャスト-128を含むことができるように関連OIDsと処理ステップを提供します。

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

キーワード“MUST"、「必須NOT」が「必要です」、“SHOULD"、「「推薦され」て、このドキュメント(中で大文字してください、示されるように)で「5月」の、そして、「任意」のNOTは[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(安全な/マルチパーパスインターネットメールエクステンション)[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

キャスト-128暗号化アルゴリズム[RFC2144、アダムス]は多くの魅力的な特徴を持っているよく研究された左右対称の暗号です、比較的高い性能と可変主要なサイズ(40ビットから128ビットまでの)を含んでいて。 それはロイヤリティのいらなくて、ライセンスなしで利用可能です。

Adams                       Standards Track                     [Page 1]

RFC 2984                    CAST-128 in CMS                 October 2000

アダムスStandardsはcm2000年10月にRFC2984キャスト-128を追跡します[1ページ]。

   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仕様の中でキャスト-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.

このセクションはキャスト-128が内容とキー暗号化に使用されるのに必要なOIDsと処理情報をCMSに供給します。

2.1 OIDs for Content and Key Encryption

2.1 内容とキー暗号化のためのOIDs

   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.

キャスト-128は、2つのユニークなオブジェクト識別子(OIDs)を提供することによって、CMSの任意の左右対称の暗号化アルゴリズムのセットに追加されます。 1OIDが満足している暗号化アルゴリズムを定義します、そして、もう片方が主要な暗号化アルゴリズムを定義します。 したがって、CMSエージェントは内容かキー暗号化のために対応するオブジェクト識別子を選択することによって、キャスト-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)モードにおけるキャスト-128の使用はRECOMMENDEDです。 キー長は可変です(1八重奏の増分における40〜128ビット)。

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

CBCモードによるキャスト-128満足している暗号化アルゴリズムには、以下のオブジェクト識別子があります:

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

cast5CBCオブジェクト識別子:、:= iso(1)は(2) 私たち(840)nt(113533) nsn(7)アルゴリズム(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:、:= 系列iv OCTET STRING DEFAULT0--初期設定ベクトルkeyLength INTEGER--ビットのキー長

   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.

キャスト-128主要な暗号化キーによって主要なキャスト-128満足している暗号化を暗号化するか、または解読するのにおいて中古の/が開ける主要な包装の手順はセクション2.2で指定されます。 主要な暗号化キーの生成と分配はこのドキュメントの範囲を超えています。

Adams                       Standards Track                     [Page 2]

RFC 2984                    CAST-128 in CMS                 October 2000

アダムスStandardsはcm2000年10月にRFC2984キャスト-128を追跡します[2ページ]。

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

キャスト-128主要な暗号化アルゴリズムには、以下のオブジェクト識別子があります:

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

cast5CMSkeywrapオブジェクト識別子:、:= iso(1)は(2) 私たち(840)nt(113533) nsn(7)アルゴリズム(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--ビットのキー長

2.2 Key Wrapping and Unwrapping

2.2 主要なラッピングと開けること

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

CMS[RFC2630]との順応でキャスト-128の主要なラッピングと開けることをします。

2.2.1 CAST-128 Key Wrap

2.2.1 キャスト-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).

キャスト-128がある主要なラッピングはセクション12.6 [RFC2630]、.1、および12.6と同じです。.4 「12.6への序論における「キャスト-128」.4に取り替えられたRC2"」と共に。 主要な暗号化キーとして128ビットのキャスト-128個のキーだけを使用してもよいです、そして、cast5CMSkeywrapParameterセットと共にそれらを128まで使用しなければなりません。 満足している暗号化キーのサイズと主要な暗号化キーのサイズが等しいのは、RECOMMENDED(内容のセキュリティがこれらの2つの値で高々わずかになるので)です。

2.2.2 CAST-128 Key Unwrap

2.2.2 キャスト-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.

キャスト-128がある主要な開けるのはセクション12.6 [RFC2630]、.1、および12.6と同じです。.5 「12.6への序論における「キャスト-128」.5に取り替えられたRC2"」と共に。

3. Using CAST-128 in S/MIME Clients

3. S/MIMEクライアントでキャスト-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

SHOULDがS/MIME能力属性を使用することでそれがサポートする暗号の機能のセットを発表するS/MIMEクライアント。 この属性を暗号の機能のOIDsの部分的なリストを提供して、クライアントは署名しなければなりません。 機能のOIDs SHOULDを機能的なカテゴリで論理的に切り離して、彼らの好みに関して注文しなければなりません。 S/MIMEクライアントがキャスト-128で左右対称の暗号化をサポートするのに必要であるなら、能力属性は上で左右対称のアルゴリズムのカテゴリで指定されたcast5CBC OIDを含まなければなりません。サポートしているキー長を示すのにこのOID(上を見る)に関連しているパラメタを使用しなければなりません。 サポートしているキー長が例えば128ビットであるときに

Adams                       Standards Track                     [Page 3]

RFC 2984                    CAST-128 in CMS                 October 2000

アダムスStandardsはcm2000年10月にRFC2984キャスト-128を追跡します[3ページ]。

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

キャスト-128を表すSMIMECapability SEQUENCEはDERは以下の16進ストリングとしてコード化していなければなりません: 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.

送付エージェントが暗号化メッセージを作成するとき、それは、どのタイプの暗号化アルゴリズムを使用するかを決めなければなりません。 一般に、決定プロセスは、リストを含んでいて、能力から得られた情報に受取人から受け取られたメッセージにかかわって、個人的な協定、ユーザー選択、法的規制などなどのように他の情報にかかわります。 ユーザが左右対称の暗号化のためにキャスト-128を必要とするなら、発信と受信の両方のクライアントは面があるS/MIMEでそれをサポートしなければなりません、そして、ユーザー選択でそれを設定しなければなりません。

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

このドキュメントはキャスト-128の左右対称の暗号のCMSメッセージの内容を暗号化して、CMSメッセージの内容を暗号化するのに使用される対称鍵を暗号化する使用を指定します。 キャスト-128は、可変長のキーが使用されるのを許容しますが、いくつかの環境には、より小さい主要なサイズ(例えば、40ビットか56ビットか64ビット)が容認できないほど弱いかもしれないと認めなければなりません。 いつもより大きい主要なサイズ(例えば、128ビット)の使用はRECOMMENDED(関連輸入、輸出、または他の法が可能にすると)です。 また、満足している暗号化キーのサイズと主要な暗号化キーのサイズが等しいのは、RECOMMENDED(内容のセキュリティがこれらの2つの値で高々わずかになるので)です。

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.

[アダムス]C.アダムスと「キャスト設計手順を使用することで左右対称の暗号を構成します」とDesigns、CodesとCryptography、vol.12、no.3、1997年11月、pp.71-104。

   [IPR]     See the "IETF Page of Intellectual Property Rights
             Notices", http://www.ietf.cnri.reston.va.us/ipr.html

[IPR]は「知的所有権通知のIETFページ」、 http://www.ietf.cnri.reston.va.us/ipr.html を見ます。

   [RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144,
             May 1997.

[RFC2144]アダムス(C.、「キャスト-128暗号化アルゴリズム」、RFC2144)は1997がそうするかもしれません。

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

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

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

[RFC2630] Housley、R.、「暗号のメッセージ構文」、RFC2630、1999年6月。

Adams                       Standards Track                     [Page 4]

RFC 2984                    CAST-128 in CMS                 October 2000

アダムスStandardsはcm2000年10月にRFC2984キャスト-128を追跡します[4ページ]。

   [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.とホフマンとP.とRamsdellとB.とLundbladeとL.とL.Repka、「S/MIMEバージョン2メッセージ仕様」、RFC2311、1998年3月。

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

DusseとS.とホフマンとP.とRamsdellとB.とJ.ワインスタイン、「S/MIMEバージョン2証明書取り扱い」、RFC2312、1998年3月。

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

[SMIME3] Ramsdell、B.、「S/MIMEバージョン3証明書取り扱い」、RFC2632、1999年6月。

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

Ramsdell、B.、「S/MIMEバージョン3メッセージ仕様」、RFC2633、1999年6月。

Author's Address

作者のアドレス

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

カーライルアダムスは技術1000革新ドライブ、Kanata、オンタリオ(カナダ)K2K3を7Eゆだねます。

   EMail: cadams@entrust.com

メール: cadams@entrust.com

Adams                       Standards Track                     [Page 5]

RFC 2984                    CAST-128 in CMS                 October 2000

アダムスStandardsはcm2000年10月にRFC2984キャスト-128を追跡します[5ページ]。

Full Copyright Statement

完全な著作権宣言文

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

Copyright(C)インターネット協会(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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   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 Editor機能のための基金は現在、インターネット協会によって提供されます。

Adams                       Standards Track                     [Page 6]

アダムス標準化過程[6ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

DAYNAME関数 曜日名を求める

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る