Network Working Group S. Teiwes
Request for Comments: 3058 P. Hartmann
Category:Informational iT_Security AG (Ltd.)
D. Kuenzi
724 Solutions Inc.
February 2001
Use of the IDEA Encryption Algorithm in CMS
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
This memo specifies how to incorporate International Data Encryption Algorithm (IDEA) into CMS or S/MIME as an additional strong algorithm for symmetric encryption. For organizations who make use of IDEA for data security purposes it is of high interest that IDEA is also available in S/MIME. The intention of this memo is to provide the OIDs and algorithms required that IDEA can be included in S/MIME for symmetric content and key encryption.
このメモは、対称暗号化のための追加の強力なアルゴリズムとしてCMSまたはS / MIMEに国際データ暗号化アルゴリズム（IDEA）を組み込む方法を指定します。データセキュリティのためにIDEAを利用する組織の場合には、IDEAは、S / MIMEでもご覧になれ高い関心があります。このメモの意図は、そのアイデアは、対称コンテンツと鍵暗号化のためのS / MIMEに含めることができます必要なのOIDとアルゴリズムを提供することです。
This memo specifies how to incorporate International Data Encryption Algorithm (IDEA) [IDEA] into CMS or S/MIME [SMIME2, SMIME3] as an additional strong algorithm for symmetric encryption. For organizations who make use of IDEA for data security purposes it is of high interest that IDEA is also available in S/MIME. The intention of this memo is to provide the OIDs and algorithms required that IDEA can be included in S/MIME for symmetric content and key encryption.
このメモは、対称暗号化のための追加の強力なアルゴリズムとしてCMSまたはS / MIME [SMIME2、SMIME3]に国際データ暗号化アルゴリズム（IDEA）[IDEA]を組み込む方法を指定します。データセキュリティのためにIDEAを利用する組織の場合には、IDEAは、S / MIMEでもご覧になれ高い関心があります。このメモの意図は、そのアイデアは、対称コンテンツと鍵暗号化のためのS / MIMEに含めることができます必要なのOIDとアルゴリズムを提供することです。
The general functional capabilities and preferences of S/MIME are specified by the registered list of S/MIME object identifiers (OIDs). This list of OIDs is available from the Internet Mail Consortium at <http://www.imc.org/ietf-smime/oids.html>. The set of S/MIME functions provided by a client is expressed by the S/MIME capabilities attribute. This attribute contains a list of OIDs of supported cryptographic functions.
S / MIMEの全般的な機能的能力および好みはS / MIMEオブジェクト識別子（OID）の登録リストで指定されています。 OIDのこのリストは、<http://www.imc.org/ietf-smime/oids.html>でインターネットメールコンソーシアムから入手可能です。クライアントが提供するS / MIME機能のセットは、S / MIME機能は、属性によって表現されます。この属性は、サポートされている暗号化機能のOIDのリストが含まれています。
In this document, the terms MUST, MUST NOT, SHOULD, and SHOULD NOT are used in capital letters. This conforms to the definitions in [MUSTSHOULD].
この文書では、用語は、と、大文字で使用されているすべきでないてはならないしなければなりません。これは、[MUSTSHOULD]の定義に従います。
The Cryptographic Message Syntax [CMS], derived from PKCS#7 [PKCS7], is the framework for the implementation of cryptographic functions in S/MIME. It specifies data formats and encryption processes without naming the cryptographic algorithms. Each algorithm which is used for encryption purposes must be specified by a unique algorithm identifier. For example, in the special case of content encryption the ContentEncryptionAlgorithmIdentifier specifies the algorithm to be applied. However, according to [CMS] any symmetric encryption algorithm that a CMS implementation includes as a content-encryption algorithm must also be included as a key-encryption algorithm.
PKCS＃7 [PKCS7]から誘導される暗号メッセージ構文[CMS]は、S / MIMEで暗号機能を実装するためのフレームワークです。これは、暗号化アルゴリズムを命名することなく、データ形式と暗号化のプロセスを指定します。暗号化の目的のために使用される各アルゴリズムは独自のアルゴリズム識別子で指定する必要があります。例えば、コンテンツの暗号化の特殊なケースでContentEncryptionAlgorithmIdentifierは、アルゴリズムが適用されるように指定します。しかし、[CMS]に記載のCMSの実装では、コンテンツ暗号化アルゴリズムとして含む任意の対称暗号化アルゴリズムは、キー暗号化アルゴリズムとして含まれていなければなりません。
IDEA is added to the set of optional symmetric encryption algorithms in S/MIME by providing two unique object identifiers (OIDs). One OID defines content encryption and the other one key encryption. Thus an S/MIME agent can apply IDEA either for content or key encryption by selecting the corresponding object identifier, supplying the required parameter, and starting the program code.
IDEAは、2つの固有のオブジェクト識別子（OID）を提供することにより、S / MIMEで任意の対称暗号化アルゴリズムのセットに追加されます。一つのOIDは、コンテンツの暗号化や他の一つのキーの暗号化を定義します。したがって、S / MIMEエージェントは、いずれかの必要なパラメータを供給し、対応するオブジェクト識別子を選択し、プログラムコードを起動することにより、コンテンツまたは鍵暗号化のためのアイデアを適用することができます。
For content encryption the use of IDEA in cipher block chaining (CBC) mode is recommended. The key length is fixed to 128 bits.
コンテンツの暗号化のための暗号ブロック連鎖（CBC）モードでのIDEAの使用が推奨されます。鍵長は128ビットに固定されています。
The IDEA content-encryption algorithm in CBC mode has the object identifier
CBCモードでのIDEAコンテンツ暗号化アルゴリズムは、オブジェクト識別子を持っています
IDEA-CBC OBJECT IDENTIFIER
::= { iso(1) identified-organization(3)
usdod(6) oid(1) private(4) enterprises(1)
ascom(188) systec(7) security(1) algorithms(1) 2 }
The identifier's parameters field contains the initialization vector (IV) as an optional parameter.
識別子のパラメータフィールドは、オプションのパラメータとして初期化ベクトル（IV）を含有します。
IDEA-CBCPar ::= SEQUENCE {
iv OCTET STRING OPTIONAL } -- exactly 8 octets
If IV is specified as above, it MUST be used as initial vector. In this case, the ciphertext MUST NOT include the initial vector. If IV is not specified, the first 64 bits of the ciphertext MUST be considered as the initial vector. However, this alternative of not including IV into "iv OCTET STRING" of IDEA-CBCPar SHOULD NOT be applied in CMS or S/MIME.
IVは、上記のように指定する場合は、初期ベクトルとして使用しなければなりません。この場合、暗号文は、初期ベクトルを含んではいけません。 IVが指定されていない場合、暗号文の最初の64ビットは、初期ベクトルとして考慮されなければなりません。しかし、IDEA-CBCParの「IVオクテットSTRING」にIVを含まないこの代替は、CMSまたはS / MIMEに適用されるべきではありません。
The key-wrap/unwrap algorithms used to encrypt/decrypt an IDEA content-encryption key with an IDEA key-encryption key are specified in the following section. Generation and distribution of IDEA key-encryption keys are beyond the scope of this document.
IDEAキー暗号化キーとIDEAコンテンツ暗号化キーを暗号化/復号化するために使用されるキーラップ/アンラップアルゴリズムは、次のセクションで指定されています。生成とIDEAキー暗号化キーの分布は、このドキュメントの範囲を超えています。
The IDEA key-encryption algorithm has the object identifier
IDEA鍵暗号化アルゴリズムは、オブジェクト識別子を持っています
id-alg-CMSIDEAwrap OBJECT IDENTIFIER
::= { iso(1) identified-organization(3)
usdod(6) oid(1) private(4) enterprises(1)
ascom(188) systec(7) security(1) algorithms(1) 6 }
The identifier's parameters field MUST be NULL.
識別子のパラメータフィールドはNULLでなければなりません。
In the following subsections IDEA key-wrap and key-unwrap algorithms are specified in conformance with [CMS], section 12.3.
以下のサブセクションでIDEAキーラップ及びキーアンラップアルゴリズムは[CMS]、セクション12.3に準拠して規定されています。
The IDEA key-wrap algorithm encrypts an IDEA content-encryption key with an IDEA key-encryption key. The IDEA key-wrap algorithm is defined by:
IDEAキー・ラップ・アルゴリズムはIDEA鍵暗号化鍵とIDEAコンテンツ暗号化キーを暗号化します。 IDEAキーラップアルゴリズムは以下のように定義されています。
1. Let the content-encryption key (16 octets) be called CEK 2. Compute an 8 octet key checksum value on CEK as described in [CMS], section 12.6.1, call the result ICV. 3. Let CEKICV := CEK || ICV. 4. Generate 8 octets at random, call the result IV. 5. Encrypt CEKICV using IDEA in CBC mode and the key-encryption key. Use the random value generated in the previous step as the initialization vector (IV). Call the ciphertext TEMP1. 6. Let TEMP2 = IV || TEMP1. 7. Reverse the order of the octets in TEMP2. That is, the most significant (first) octet is swapped with the least significant (last) octet, and so on. Call the result TEMP3. 8. Encrypt TEMP3 using IDEA in CBC mode and the key-encryption key. Use an initialization vector (IV) of 0x4adda22c79e82105. The ciphertext is 32 octets long.
1.結果ICVを呼び出し、コンテンツ暗号化キー（16オクテット）[CMS]で説明されるようにCEKに8オクテットキーチェックサム値CEK 2.計算と呼ばれる、セクション12.6.1をしましょう。 3.レッツのCEKICV：= CEK || ICV。 4.結果のIVを呼び出し、ランダムに8オクテットを生成します。 CBCモードとキー暗号化キーにIDEAを使用して5.暗号化CEKICV。初期化ベクトル（IV）のような、前のステップで生成したランダム値を使用します。暗号文TEMP1を呼び出します。 6. TEMP2 = IVましょう|| TEMP1。 7. TEMP2のオクテットの順序を逆にします。それは最も重要な（最初の）オクテットはそうで最下位（最後）のオクテットと交換、およびされています。結果TEMP3を呼び出します。 CBCモードとキー暗号化キーにIDEAを使用して8.暗号化TEMP3。 0x4adda22c79e82105の初期化ベクトル（IV）を使用します。暗号文は、32オクテットの長さです。
The IDEA key-unwrap algorithm decrypts an IDEA content-encryption key using an IDEA key-encryption key. The IDEA key-unwrap algorithm is defined by:
IDEAキー・アンラップアルゴリズムはIDEA鍵暗号化キーを使用してIDEAコンテンツ暗号化キーを復号化します。 IDEAキー・アンラップアルゴリズムは以下のように定義されています。
1. If the wrapped content-encryption key is not 32 octets, then error. 2. Decrypt the wrapped content-encryption key using IDEA in CBC mode with the key-encryption key. Use an initialization vector (IV) of 0x4adda22c79e82105. Call the output TEMP3. 3. Reverse the order of the octets in TEMP3. That is, the most significant (first) octet is swapped with the least significant (last) octet, and so on. Call the result TEMP2. 4. Decompose the TEMP2 into IV and TEMP1. IV is the most significant (first) 8 octets, and TEMP1 is the remaining (last) 24 octets. 5. Decrypt TEMP1 using IDEA in CBC mode with the key-encryption key. Use the IV value from the previous step as the initialization vector. Call the plaintext CEKICV. 6. Decompose the CEKICV into CEK and ICV. CEK is the most significant (first) 16 octets, and ICV is the least significant (last) 8 octets. 7. Compute an 8 octet key checksum value on CEK as described in [CMS], section 12.6.1. If the computed key checksum value does not match the decrypted key checksum value, ICV, then error. 8. Use CEK as the content-encryption key.
1.包まれたコンテンツ暗号化キーは、32オクテット、エラーではない場合。 2.キー暗号化キーでCBCモードでIDEAを使用して、ラップされたコンテンツ暗号化キーを復号化。 0x4adda22c79e82105の初期化ベクトル（IV）を使用します。出力TEMP3を呼び出します。 3. TEMP3のオクテットの順序を逆にします。それは最も重要な（最初の）オクテットはそうで最下位（最後）のオクテットと交換、およびされています。結果TEMP2を呼び出します。 4. IVとTEMP1にTEMP2を分解する。 IVは、最も重要な（最初の）8つのオクテットで、TEMP1は、残りの（最後の）24オクテットです。キー暗号化キーでCBCモードでIDEAを使用して復号化5. TEMP1。初期化ベクトルとして前のステップからIV値を使用します。平文CEKICVを呼び出します。 6. CEKとICVにCEKICVを分解する。 CEKは、最も重要な（最初の）16個のオクテットで、ICVは最下位（最後の）8つのオクテットです。 [CMS]で説明したように7、セクション12.6.1をCEKに8オクテットキーチェックサム値を計算します。計算されたキーのチェックサム値は、復号化キーのチェックサム値、ICV、エラーと一致しない場合。コンテンツ暗号鍵として8. CEK。
An S/MIME client can announce the set of cryptographic functions it supports by using the S/MIME capabilities attribute as specified in [SMIME3]. This attribute provides a partial list of OIDs of cryptographic functions and must be signed by the client. These 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 and key wrapping based on IDEA, the capabilities attribute MUST contain the above specified OIDs in the category of symmetric algorithms and key encipherment algorithms. IDEA does not require additional OID parameters since it has a fixed key length of 128 bits.
S / MIMEクライアントは、[SMIME3]に指定されている機能は、属性S / MIMEを使用することによって、それがサポートする暗号化機能のセットを発表することができます。この属性は、暗号化関数のOIDの部分的なリストを提供し、クライアントによって署名されなければなりません。これらのOIDは、論理的に機能的なカテゴリに分離する必要がありますし、自分の好みに関して注文する必要があります。 S / MIMEクライアントは、IDEAに基づく対称暗号化とキーラップをサポートするために必要な場合は、機能が対称アルゴリズムと鍵暗号化アルゴリズムのカテゴリに上記指定されたOIDを含まなければならない属性。それは128ビットの固定鍵長を有するので、IDEAは、追加のOIDパラメータを必要としません。
The SMIMECapability SEQUENCE representing the IDEA symmetric encryption algorithm MUST include the IDEA-CBC OID in the capabilityID field and the parameters field MUST be absent. The SMIMECapability SEQUENCE for IDEA encryption SHOULD be included in the symmetric encryption algorithms portion of the SMIMECapabilities list. The SMIMECapability SEQUENCE representing IDEA MUST be DER-encoded as follows: 300D 060B 2B06 0104 0181 3C07 0101 02.
IDEA対称暗号化アルゴリズムを表すSMIMECapability配列が存在してはならないcapabilityIDフィールドとパラメータフィールドにIDEA-CBC OIDを含まなければなりません。 IDEA暗号化のためSMIMECapability配列はSMIMEケーパビリティリストの対称暗号化アルゴリズム部に含まれるべきです。 300D 060B 2B06は3C07 0101 02 0104 0181を次のようにIDEAを表すSMIMECapability配列は、DER符号化されなければなりません。
The SMIMECapability SEQUENCE representing the IDEA key wrapping algorithm MUST include the id-alg-CMSIDEAwrap OID in the capabilityID field and the parameters field of KeyWrapAlgorithm MUST be absent. The SMIMECapability SEQUENCE for IDEA key wrapping SHOULD be included in the key encipherment algorithms portion of the SMIMECapabilities list. The SMIMECapability SEQUENCE representing IDEA key wrapping MUST be DER-encoded as follows: 300D 060B 2B06 0104 0181 3C07 0101 06.
capabilityIDフィールドのID-ALG-CMSIDEAwrap OIDを含まなければならないIDEA鍵ラッピングアルゴリズムを表すSMIMECapability配列とKeyWrapAlgorithmのパラメータのフィールドは存在してはなりません。 IDEAキー包装用SMIMECapability配列はSMIMEケーパビリティリストの鍵暗号化アルゴリズム部に含まれるべきです。 0181 3C07 0101 06 300D 060B 2B06 0104：IDEA鍵ラッピングを表すSMIMECapability配列は、以下のようにDERは、符号化されなければなりません。
The ASN.1 notation of the SMIMECapability SEQUENCE representing IDEA is
IDEAを表すSMIMECapability配列のASN.1表記であります
SMIMECapability ::= SEQUENCE {
capabilityID OBJECT IDENTIFIER,
parameters ANY DEFINED BY capabilityID OPTIONAL }
where capabilityID is IDEA-CBC (no parameters) for IDEA content encryption in CBC mode or capabilityID is id-alg-CMSIDEAwrap (no parameters) for IDEA key wrapping.
capabilityIDがCBCモードまたはcapabilityIDでIDEAコンテンツ暗号化用のIDEA-CBC（パラメータなし）である場合、ID-CMSIDEAwrap ALG IDEAキー包装用（パラメータなし）です。
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, etc. If users require IDEA 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.
送信エージェントが暗号化されたメッセージを作成するときに、暗号化アルゴリズムのタイプを使用するかを決定する必要があります。一般的には決定プロセスは、ユーザーが対称暗号化のためのアイデアを必要とする場合、それはサポートされなければならない機能のリストから得られた情報の受信者から受信したメッセージに含まれ、ならびに等の民間協定、ユーザーの好み、法的規制、その他の情報を必要とします両方のS / MIMEクライアントによって送信側と受信側と、それはユーザーの好みに設定する必要があります。
A. References
A.参考文献
[IDEA] X. Lai, "On the design and security of block ciphers", ETH Series in Information Processing, J.L. Massey (editor), vol. 1, Hartung-Gorre Verlag Konstanz, Technische Hochschule (Zurich), 1992. A. J. Menezes, P.C. v. Oorschot, S.A. Vanstone, "Handbook of Applied Cryptography," CRC Press New York, 1997, p. 265. B. Schneier, "Applied Cryptography," 2nd ed., John Wiley & Sons Inc. New York, 1996, pp. 319-325. IPR: see the "IETF Page of Intellectual Property Rights Notices", http://www.ietf.org/ipr.html
情報処理における「ブロック暗号のデザインとセキュリティについて」[IDEA] X.ライ、ETHシリーズ、J。L.マッセイ（編集者）、巻。 1、アルトゥング-Gorre Verlag社コンスタンツ、TECHNISCHE音楽大学（チューリッヒ）、1992 A. J.メネゼス、P.C. V。Oorschot、S.A.社Vanstone著、 "応用暗号のハンドブック" CRCプレス、ニューヨーク、1997年、P。 265 B.シュナイアー、 "応用暗号、" 第二版、John Wiley＆Sons社、ニューヨーク、1996年、頁319-325。 IPR：「知的財産権通知のIETFページ」、http://www.ietf.org/ipr.htmlを参照してください
[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メッセージ仕様"、RFC 2311、1998年3月。
[SMIME2] Dusse, S., Hoffman, P., Ramsdell, B. and J. Weinstein, "S/MIME Version 2 Certificate Handling", RFC 2312, March 1998.
【SMIME2] Dusse、S.、ホフマン、P.、Ramsdell、B.及びJ.ワインスタイン、 "S / MIMEバージョン2証明書処理"、RFC 2312、1998年3月。
[SMIME3] Dusse, S., Hoffman, P., Ramsdell, B. and J. Weinstein, "S/MIME Version 3 Certificate Handling", RFC 2632, March 1998.
【SMIME3] Dusse、S.、ホフマン、P.、Ramsdell、B.及びJ.ワインスタイン、 "S / MIMEバージョン3証明書の取り扱い"、RFC 2632、1998年3月。
[SMIME3] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
【SMIME3] Ramsdell、B.、 "S / MIMEバージョン3メッセージ仕様"、RFC 2633、1999年6月。
[MUSTSHOULD] Bradner, S.,"Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[MUSTSHOULD]ブラドナーの、S。、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
[CMS] Housley氏、R.、 "暗号メッセージ構文"、RFC 2630、1999年6月。
[PKCS7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, March 1998.
[PKCS7] Kaliski、B.、 "PKCS＃7：暗号メッセージ構文バージョン1.5"、RFC 2315、1998年3月。
B. Comments on IDEA Security and Standards
B. IDEAのセキュリティと標準化に関するコメントは、
The IDEA algorithm was developed in a joint project involving the Swiss Federal Institute of Technology in Zurich (Dr. X. Lai and Prof. J.L. Massey) and Ascom Ltd. The aim of the project was to develop a strong encryption algorithm that could replace the DES algorithm.
IDEAアルゴリズムは、プロジェクトの目的は、置き換えることができ、強力な暗号化アルゴリズムを開発することであったチューリッヒのスイス連邦工科大学（博士X.ライ教授JLマッセイ）とアスコム社が関与する共同プロジェクトで開発されましたDESアルゴリズム。
IDEA uses 128-bit secret keys and encrypts one 64-bit block at a time [IDEA]. It was particularly strengthened to protect against differential cryptoanalysis attacks. For the full 8-round IDEA there is no attack known which is better than exhaustive search on the total 128-bit key space.
IDEAは128ビットの秘密鍵を使用し、時間[IDEA]で1つの64ビットブロックを暗号化します。これは、特に、差動暗号解読攻撃から保護するために強化されました。フル8ラウンドIDEAの合計128ビットの鍵空間上の網羅的な探索よりも優れている知られているいかなる攻撃がありません。
IDEA permits the implementation of standard Electronic Data Interchange applications. It has been entered in the ISO/IEC register for encryption algorithms and incorporated in the "SECURITY GUIDE LINES" code list by the UNI/EDIFACT "SECURITY JOINT WORKING GROUP".
IDEAは、標準の電子データ交換アプリケーションの実装を可能にします。これは、暗号化アルゴリズムのために登録して、UNI / EDIFACT「SECURITY共同作業部会」による「セキュリティガイドLINES」のコードリストに組み込ま/ IEC ISOに入力されています。
C. Intellectual Property Rights Notice
C.知的財産権に関するお知らせ
Ascom Ltd. holds the patent to IDEA. In accordance with the intellectual property rights procedures of the IETF standards process, Ascom offers a non-exclusive license under reasonable and non-discriminatory terms and conditions.
アスコム（株）は、IDEAの特許を保持しています。 IETF標準化プロセスの知的財産権の手続きに従い、アスコムは、合理的かつ非差別条項および条件の下で非独占的ライセンスを提供しています。
IDEA(TM) is protected by international copyright law and in addition has been patented in several countries. Because Ascom wants to make this highly secure algorithm widely available, the non-commercial use of this algorithm is free.
IDEA（TM）は、国際著作権法により保護されており、加えて、いくつかの国で特許を取得しています。アスコムは、この安全性の高いアルゴリズムが広く利用できるようにしたいので、このアルゴリズムの非商用利用は無料です。
Any party wishing to know more about IDEA or to request a license should visit the web sites <http://www.media-crypt.com/>, <http://www.it-sec.com/> or send an e-mail to info@media-crypt.com or Idea@it-sec.com.
希望当事者は、IDEAの詳細については知っているか、ウェブサイトを参照してください<http://www.media-crypt.com/>、<http://www.it-sec.com/>または送信する必要があり、ライセンスを要求しますinfo@media-crypt.comまたはIdea@it-sec.comへの電子メール。
D. Acknowledgements
D.謝辞
We would like to thank Russ Housley, Jim Schaad and Francois Zeller for their contributions to this document.
私たちは、この文書への貢献のためのラスHousley、ジムSchaadとフランソワ・ツェラーに感謝したいと思います。
E. Authors' Addresses
E.の著者のアドレス
Stephan Teiwes iT_Security AG (Ltd.) Badenerstrasse 530 CH-8048 Zurich, Switzerland
ステファンTeiwes iT_Security AG（株）Badenerstrasse 530 CH-8048チューリッヒ、スイス
Phone: +41 1 404 8200 Fax : +41 1 404 8201 EMail: stephan.teiwes@it-sec.com
電話：+41 1 404 8200ファックス：+41 1 404 8201 Eメール：stephan.teiwes@it-sec.com
Peter Hartmann iT_Security AG (Ltd.) Badenerstrasse 530 CH-8048 Zurich, Switzerland
ピーターハルトマンiT_Security AG（株）Badenerstrasse 530 CH-8048チューリッヒ、スイス
Phone: +41 1 404 8200 Fax : +41 1 404 8201 EMail: peter.hartmann@it-sec.com
電話：+41 1 404 8200ファックス：+41 1 404 8201 Eメール：peter.hartmann@it-sec.com
Diego Kuenzi 724 Solutions Inc. Bahnhofstrasse 16 CH-5600 Lenzburg, Switzerland
ディエゴ・724・ソリューションズ株式会社メイトバーンホフ通り16 CH-5600レンツブルク、スイス
Phone: +41 62 888 3070 Fax: +41 62 888 3071 EMail: dkuenzi@724.com
電話：+41 62 888 3070ファックス：+41 62 888 3071 Eメール：dkuenzi@724.com
F. Full Copyright Statement
F.完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。