RFC4107 日本語訳

Network Working Group                                        S. Bellovin
Request for Comments: 4107                           Columbia University
BCP: 107                                                      R. Housley
Category: Best Current Practice                           Vigil Security
                                                               June 2005

Bellovinがコメントのために要求するワーキンググループS.をネットワークでつないでください: 4107コロンビア大学BCP: 107R.Housleyカテゴリ: 最も良い現在の練習不寝番セキュリティ2005年6月

              Guidelines for Cryptographic Key Management

暗号化キー管理のためのガイドライン

Status of This Memo

このメモの状態

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2005).

Copyright(C)インターネット協会(2005)。

Abstract

要約

   The question often arises of whether a given security system requires
   some form of automated key management, or whether manual keying is
   sufficient.  This memo provides guidelines for making such decisions.
   When symmetric cryptographic mechanisms are used in a protocol, the
   presumption is that automated key management is generally but not
   always needed.  If manual keying is proposed, the burden of proving
   that automated key management is not required falls to the proposer.

質問は与えられたセキュリティシステムが何らかの形式の自動化されたかぎ管理を必要とするかどうか、または手動の合わせるのが十分であるかどうかしばしば起こります。 このメモはそのような決定をするためのガイドラインを提供します。 左右対称の暗号のメカニズムがプロトコルに使用されるとき、推定はいつもでない、しかし、一般に、自動化されたかぎ管理が必要であるということです。 マニュアルであるなら、合わせることは提案されて、自動化されたかぎ管理は必要でないと立証する負担が提案者の手に落ちます。

1.  Introduction

1. 序論

   The question often arises of whether or not a given security system
   requires some form of automated key management, or whether manual
   keying is sufficient.

質問は与えられたセキュリティシステムが何らかの形式の自動化されたかぎ管理を必要とするかどうか、または手動の合わせるのが十分であるかどうかしばしば起こります。

   There is not one answer to that question; circumstances differ.  In
   general, automated key management SHOULD be used.  Occasionally,
   relying on manual key management is reasonable; we propose some
   guidelines for making that judgment.

その質問の1つの答えがありません。 事情は異なります。 一般に、自動化されて、管理SHOULDを合わせてください。使用されます。 時折、手動のかぎ管理に依存するのは妥当です。 私たちはそれを判断にするためのいくつかのガイドラインを提案します。

   On the other hand, relying on manual key management has significant
   disadvantages, and we outline the security concerns that justify the
   preference for automated key management.  However, there are
   situations in which manual key management is acceptable.

他方では、手動のかぎ管理に依存するのにおいて、重要な損失があります、そして、私たちは自動化されたかぎ管理のために好みを正当化する安全上の配慮について概説します。 しかしながら、手動のかぎ管理が許容できる状況があります。

Bellovin & Housley       Best Current Practice                  [Page 1]

RFC 4107      Guidelines for Cryptographic Key Management      June 2005

BellovinとHousleyの最も良い海流は管理2005年6月に暗号化キーのためのRFC4107ガイドラインを練習します[1ページ]。

1.1.  Terminology

1.1. 用語

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in RFC 2119 [B].

キーワードが解釈しなければならない、本書では現れるとき、RFC2119[B]で説明されるようにNOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりませんか?

2.  Guidelines

2. ガイドライン

   These guidelines are for use by IETF working groups and protocol
   authors who are determining whether to mandate automated key
   management and whether manual key management is acceptable.  Informed
   judgment is needed.

これらのガイドラインは自動化されたかぎ管理を強制するかどうかと、手動のかぎ管理が許容できるかどうかと決心しているIETFワーキンググループとプロトコル作者による使用のためのものです。 知識がある判断が必要です。

   The term "key management" refers to the establishment of
   cryptographic keying material for use with a cryptographic algorithm
   to provide protocol security services, especially integrity,
   authentication, and confidentiality.  Automated key management
   derives one or more short-term session keys.  The key derivation
   function may make use of long-term keys to incorporate authentication
   into the process.  The manner in which this long-term key is
   distributed to the peers and the type of key used (pre-shared
   symmetric secret value, RSA public key, DSA public key, and others)
   is beyond the scope of this document.  However, it is part of the
   overall key management solution.  Manual key management is used to
   distribute such values.  Manual key management can also be used to
   distribute long-term session keys.

暗号アルゴリズムがある使用がプロトコルセキュリティー・サービス、特に保全、認証、および秘密性を提供するように、「かぎ管理」という用語は暗号の合わせることの材料の設立について言及します。 自動化されたかぎ管理は1個以上の短期的なセッションキーを引き出します。 主要な派生機能は、認証をプロセスに組み入れるのに長期のキーを利用するかもしれません。 この長期のキーが使用されるキー(あらかじめ共有された左右対称の秘密の値、RSA公開鍵、DSA公開鍵、および他のもの)の同輩とタイプに分配される方法はこのドキュメントの範囲を超えています。 しかしながら、それは総合的なかぎ管理解決の一部です。 手動のかぎ管理は、そのような値を分配するのに使用されます。 また、長期のセッションキーを分配するのに手動のかぎ管理を使用できます。

   Automated key management and manual key management provide very
   different features.  In particular, the protocol associated with an
   automated key management technique will confirm the liveness of the
   peer, protect against replay, authenticate the source of the short-
   term session key, associate protocol state information with the
   short-term session key, and ensure that a fresh short-term session
   key is generated.  Further, an automated key management protocol can
   improve interoperability by including negotiation mechanisms for
   cryptographic algorithms.  These valuable features are impossible or
   extremely cumbersome to accomplish with manual key management.

自動化されたかぎ管理と手動のかぎ管理は非常に異なった特徴を提供します。 自動化されたかぎ管理のテクニックに関連しているプロトコルは、特に、同輩の活性を確認して、再生から守って、短い用語セッションキーの源を認証して、プロトコル州の情報を短期的なセッションキーに関連づけて、新鮮な短期的なセッションキーが発生しているのを確実にするでしょう。 さらに、自動化されたかぎ管理プロトコルは、暗号アルゴリズムのために交渉メカニズムを含んでいることによって、相互運用性を改良できます。これらの貴重な特徴は、手動のかぎ管理で達成するために不可能であるか、または非常に厄介です。

   For some symmetric cryptographic algorithms, implementations must
   prevent overuse of a given key.  An implementation of such algorithms
   can make use of automated key management when the usage limits are
   nearly exhausted, in order to establish replacement keys before the
   limits are reached, thereby maintaining secure communications.

いくつかの左右対称の暗号アルゴリズムのために、実装は与えられたキーの酷使を防がなければなりません。 用法限界がほとんど消耗しているとき、そのようなアルゴリズムの実装は自動化されたかぎ管理を利用できます、限界に達する前に交換キーを設立するために、その結果、安全なコミュニケーションを維持します。

   Examples of automated key management systems include IPsec IKE and
   Kerberos.  S/MIME and TLS also include automated key management
   functions.

自動化されたかぎ管理システムに関する例はIPsec IKEとケルベロスを含んでいます。 また、S/MIMEとTLSは自動化されたかぎ管理機能を含んでいます。

Bellovin & Housley       Best Current Practice                  [Page 2]

RFC 4107      Guidelines for Cryptographic Key Management      June 2005

BellovinとHousleyの最も良い海流は管理2005年6月に暗号化キーのためのRFC4107ガイドラインを練習します[2ページ]。

   Key management schemes should not be designed by amateurs; it is
   almost certainly inappropriate for working groups to design their
   own.  To put it in concrete terms, the very first key management
   protocol in the open literature was published in 1978 [NS].  A flaw
   and a fix were published in 1981 [DS], and the fix was cracked in
   1994 [AN].  In 1995 [L], a new flaw was found in the original 1978
   version, in an area not affected by the 1981/1994 issue.  All of
   these flaws were obvious once described -- yet no one spotted them
   earlier.  Note that the original protocol (translated to employ
   certificates, which had not been invented at that time) was only
   three messages.

アマチュアはかぎ管理体系を設計するべきではありません。 ワーキンググループがそれら自身のを設計するのは、ほぼ確実に不適当です。 具体名辞、最初に非常に主要にそれを入れるために、開いている文学の管理プロトコルは1978年[NS]に発表されました。 欠点とフィックスは1981年[DS]に発行されました、そして、フィックスは1994年[AN]に解かれました。 1995[L]では、新しい欠点は1978年のオリジナルのバージョンで見つけられました、1981/1994号で影響を受けない領域で。 いったん説明されると、これらの欠点のすべてが明白でした--まだそれらが、より早く見つけられただれも。 オリジナルのプロトコル(その時発明されていなかった証明書を使うために、翻訳される)が3つのメッセージにすぎなかったことに注意してください。

   Key management software is not always large or bloated.  Even IKEv1
   [HC] can be done in less than 200 Kbytes of object code, and TLS [DA]
   in half that space.  Note that this TLS estimate includes other
   functionality as well.

かぎ管理ソフトウェアは、いつも大きいというわけではなく、むくんでいません。 オブジェクトコードの200キロバイト未満、およびそのスペースの半分のTLS[DA]でIKEv1[HC]さえできます。 このTLS見積りがまた、他の機能性を含んでいることに注意してください。

   A session key is used to protect a payload.  The nature of the
   payload depends on the layer where the symmetric cryptography is
   applied.

セッションキーは、ペイロードを保護するのに使用されます。 ペイロードの本質は左右対称の暗号が適用されている層によります。

   In general, automated key management SHOULD be used to establish
   session keys.  Strong justification is needed in the security
   considerations section of a proposal that makes use of manual key
   management.

一般に、自動化されて、管理SHOULDを合わせてください。セッションキーを設立するのが使用されます。 強い正当化が手動のかぎ管理を利用する提案のセキュリティ問題部で必要です。

2.1.  Automated Key Management

2.1. 自動化されたKey Management

   Automated key management MUST be used if any of these conditions
   hold:

これらの状態のどれかが成立するなら、自動化されたかぎ管理を使用しなければなりません:

      A party will have to manage n^2 static keys, where n may become
      large.

パーティーはn^2個の静的なキーを管理しなければならないでしょう。そこでは、nが大きくなるかもしれません。

      Any stream cipher (such as RC4 [TK], AES-CTR [NIST], or AES-CCM
      [WHF]) is used.

どんなストリーム暗号(RC4[TK]、AES-CTR[NIST]、またはAES-CCM[WHF]などの)も使用されています。

      An initialization vector (IV) might be reused, especially an
      implicit IV.  Note that random or pseudo-random explicit IVs are
      not a problem unless the probability of repetition is high.

初期化ベクトル(IV)は特に再利用されるかもしれません。暗黙のIV。 反復の確率が高くない場合無作為であるか擬似ランダムの明白なIVsが問題でないことに注意してください。

      Large amounts of data might need to be encrypted in a short time,
      causing frequent change of the short-term session key.

多量のデータが、まもなく暗号化される必要があるかもしれません、短期的なセッションキーの頻繁な変化を引き起こして。

      Long-term session keys are used by more than two parties.
      Multicast is a necessary exception, but multicast key management
      standards are emerging in order to avoid this in the future.
      Sharing long-term session keys should generally be discouraged.

長期のセッションキーは2回以上のパーティーによって使用されます。 マルチキャストは必要な例外ですが、マルチキャストかぎ管理規格は、将来これを避けるために現れています。 一般に、長期のセッションキーを共有するのはお勧めできなくあるべきです。

Bellovin & Housley       Best Current Practice                  [Page 3]

RFC 4107      Guidelines for Cryptographic Key Management      June 2005

BellovinとHousleyの最も良い海流は管理2005年6月に暗号化キーのためのRFC4107ガイドラインを練習します[3ページ]。

      The likely operational environment is one where personnel (or
      device) turnover is frequent, causing frequent change of the
      short-term session key.

ありそうな運用環境は人員(または、デバイス)取引高が頻繁であるものです、短期的なセッションキーの頻繁な変化を引き起こして。

2.2.  Manual Key Management

2.2. 手動のKey Management

   Manual key management may be a reasonable approach in any of these
   situations:

手動のかぎ管理はこれらの状況のどれかで合理的なアプローチであるかもしれません:

      The environment has very limited available bandwidth or very high
      round-trip times.  Public key systems tend to require long
      messages and lots of computation; symmetric key alternatives, such
      as Kerberos, often require several round trips and interaction
      with third parties.

環境は非常に限られた利用可能な帯域幅か非常に高い往復の時を過します。 公開鍵システムは、長いメッセージと多くの計算を必要とする傾向があります。 ケルベロスなどの対称鍵代替手段はしばしば第三者との数回の周遊旅行と相互作用を必要とします。

      The information being protected has low value.

保護される情報は低値を持っています。

      The total volume of traffic over the entire lifetime of the long-
      term session key will be very low.

長い用語セッションキーの全体の生涯の間のトラフィックの全容積は非常に低くなるでしょう。

      The scale of each deployment is very limited.

それぞれの展開のスケールは非常に限られています。

   Note that assertions about such things should often be viewed with
   skepticism.  The burden of demonstrating that manual key management
   is appropriate falls to the proponents -- and it is a fairly high
   hurdle.

そのようなものの周りの主張がしばしば懐疑をもって見られるべきであることに注意してください。 その手動のかぎ管理のデモをする負担は提案者への適切な落下です、そして、それはかなり高いハードルです。

   Systems that employ manual key management need provisions for key
   changes.  There MUST be some way to indicate which key is in use to
   avoid problems during transition.  Designs SHOULD sketch plausible
   mechanisms for deploying new keys and replacing old ones that might
   have been compromised.  If done well, such mechanisms can later be
   used by an add-on key management scheme.

手動のかぎ管理を使うシステムがキーチェンジのための条項を必要とします。 どのキーが変遷の間、問題を避けるために使用中であるかを示す何らかの方法があるに違いありません。 新しいキーと取り替えの古いものがそれであると配布しながらSHOULDがもっともらしいメカニズムについてスケッチするデザインは感染されたかもしれません。 上手にするなら、アドオンのかぎ管理体系は後でそのようなメカニズムを使用できます。

   Lack of clarity about the parties involved in authentication is not a
   valid reason for avoiding key management.  Rather, it tends to
   indicate a deeper problem with the underlying security model.

認証にかかわるパーティーに関する明快の不足はかぎ管理を避ける正当な理由ではありません。 むしろ、それは、基本的な機密保護モデルに関する、より深い問題を示す傾向があります。

2.3.  Key Size and Random Values

2.3. 主要なサイズと無作為の値

   Guidance on cryptographic key size for public keys that are used for
   exchanging symmetric keys can be found in BCP 86 [OH].

BCP86[OH]で対称鍵を交換するのに使用される公開鍵のための暗号化キーサイズにおける指導を見つけることができます。

   When manual key management is used, long-term shared secret values
   SHOULD be at least 128 bits.

手動のかぎ管理が使用されているとき、長期の共有秘密キーは少なくとも128がビットであったならSHOULDを評価します。

   Guidance on random number generation can be found in BCP 106 [ESC].

BCP106[ESC]で乱数発生における指導を見つけることができます。

Bellovin & Housley       Best Current Practice                  [Page 4]

RFC 4107      Guidelines for Cryptographic Key Management      June 2005

BellovinとHousleyの最も良い海流は管理2005年6月に暗号化キーのためのRFC4107ガイドラインを練習します[4ページ]。

   When manual key management is used, long-term shared secrets MUST be
   unpredictable "random" values, ensuring that an adversary will have
   no greater expectation than 50% of finding the value after searching
   half the key search space.

手動のかぎ管理が使用されているとき、長期の共有秘密キーは予測できない「無作為」の値であるに違いありません、敵には半分を捜した後の値が主要な検索スペースであることがわかるより50%の大きいどんな期待もないのを確実にして。

3.  Security Considerations

3. セキュリティ問題

   This document provides guidance to working groups and protocol
   designers.  The security of the Internet is improved when automated
   key management is employed.

このドキュメントはワーキンググループとプロトコルデザイナーに指導を提供します。 自動化されたかぎ管理が採用しているとき、インターネットのセキュリティは向上されています。

   The inclusion of automated key management does not mean that an
   interface for manual key management is prohibited.  In fact, manual
   key management is very helpful for debugging.  Therefore,
   implementations ought to provide a manual key management interface
   for such purposes, even if it is not specified by the protocol.

自動化されたかぎ管理の包含は、手動のかぎ管理のためのインタフェースが禁止されていることを意味しません。 事実上、デバッグにおいて、手動のかぎ管理は非常に役立っています。 したがって、実装は手動のかぎ管理インタフェースをそのような目的に提供するべきです、それがプロトコルによって指定されないでも。

4.  References

4. 参照

   This section contains normative and informative references.

このセクションは規範的で有益な参照を含みます。

4.1.  Normative References

4.1. 引用規格

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

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

   [ESC]  Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness
          Requirements for Security", BCP 106, RFC 4086, June 2005.

[ESC]イーストレークとD.と3番目、シラー、J.とS.クロッカー、「セキュリティのための偶発性要件」BCP106、2005年6月のRFC4086。

   [OH]   Orman, H. and P. Hoffman, "Determining Strengths For Public
          Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766,
          April 2004

[おお] OrmanとH.とP.ホフマン、「対称鍵を交換するのに使用される公開鍵のために強さを測定する」BCP86、RFC3766、2004年4月

4.2.  Informative References

4.2. 有益な参照

   [AN]   M. Abadi and R. Needham, "Prudent Engineering Practice for
          Cryptographic Protocols", Proc. IEEE Computer Society
          Symposium on Research in Security and Privacy, May 1994.

[AN]M.AbadiとR.ニーダム、「暗号のプロトコルのための慎重なエンジニアリング方式」、Proc。 1994年5月のセキュリティとプライバシーにおける研究に関するIEEEコンピュータ社会シンポジウム。

   [DA]   Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
          2246, January 1999.

[DA] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。

   [DS]   D. Denning and G. Sacco.  "Timestamps in key distributed
          protocols", Communication of the ACM, 24(8):533--535, 1981.

[DS] D.デニングとG.サッコ。 533--535、「主要な分配されたプロトコルのタイムスタンプ」、ACM、24(8)のCommunication:1981。

   [HC]   Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
          RFC 2409, November 1998.

[HC]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。

Bellovin & Housley       Best Current Practice                  [Page 5]

RFC 4107      Guidelines for Cryptographic Key Management      June 2005

BellovinとHousleyの最も良い海流は管理2005年6月に暗号化キーのためのRFC4107ガイドラインを練習します[5ページ]。

   [L]    G. Lowe.  "An attack on the Needham-Schroeder public key
          authentication protocol", Information Processing Letters,
          56(3):131--136, November 1995.

[L] G.ロウ。 「ニーダム-シュローダー公開鍵認証プロトコルに対する攻撃」、情報Processing Letters、56(3): 131--136と、1995年11月。

   [NIST] National Institute of Standards and Technology.
          "Recommendation for Block Cipher Modes of Operation -- Methods
          and Techniques," NIST Special Publication SP 800-38A, December
          2001.

[NIST]米国商務省標準技術局。 「操作--メソッドのブロック暗号モードのための推薦とテクニック」、NIST特別な公表SP800-38A、12月2001

   [NS]   R. Needham and M. Schroeder. "Using encryption for
          authentication in large networks of computers", Communications
          of the ACM, 21(12), December 1978.

[ナノ秒] R.ニーダムとM.シュローダー。 「認証にコンピュータの大きいネットワークに暗号化を使用します」、ACM、21(12)、1978年12月のCommunications。

   [TK]   Thayer, R. and K. Kaukonen.  "A Stream Cipher Encryption
          Algorithm", Work in Progress.

[TK] セイヤー、R.、およびK.コウコネン。 「ストリーム暗号暗号化アルゴリズム」、処理中の作業。

   [WHF]  Whiting, D., Housley, R., and N. Ferguson , "Counter with
          CBC-MAC (CCM)", RFC 3610, September 2003.

2003年9月の[WHF]ホワイティングとD.とHousley、R.とN.ファーガソン、「CBC-MAC(立方センチメートル)があるカウンタ」RFC3610。

Authors' Addresses

作者のアドレス

   Steven M. Bellovin
   Department of Computer Science
   Columbia University
   1214 Amsterdam Avenue, M.C. 0401
   New York, NY 10027-7003

スティーブンM.Bellovinコンピュータサイエンス学部Columbia University1214アムステルダムアベニュー、ニューヨーク、M.C.0401ニューヨーク10027-7003

   Phone: +1 212-939-7149
   EMail: bellovin@acm.org

以下に電話をしてください。 +1 212-939-7149 メールしてください: bellovin@acm.org

   Russell Housley
   Vigil Security, LLC
   918 Spring Knoll Drive
   Herndon, VA 20170

ラッセルHousley不寝番セキュリティ、ハーンドン、LLC918スプリング小山Driveヴァージニア 20170

   Phone: +1 703-435-1775
   EMail: housley@vigilsec.com

以下に電話をしてください。 +1 703-435-1775 メールしてください: housley@vigilsec.com

Bellovin & Housley       Best Current Practice                  [Page 6]

RFC 4107      Guidelines for Cryptographic Key Management      June 2005

BellovinとHousleyの最も良い海流は管理2005年6月に暗号化キーのためのRFC4107ガイドラインを練習します[6ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2005).

Copyright(C)インターネット協会(2005)。

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Bellovin & Housley       Best Current Practice                  [Page 7]

Bellovin&Housleyの最も良い現在の習慣[7ページ]