この文書はRFC3757の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。


Network Working Group                                         O. Kolkman
Request for Comments: 3757                                      RIPE NCC
Updates: 3755, 2535                                          J. Schlyter
Category: Standards Track                                         NIC-SE
                                                                E. Lewis
                                                                    ARIN
                                                              April 2004


         Domain Name System KEY (DNSKEY) Resource Record (RR)
                     Secure Entry Point (SEP) Flag
      ドメインネームシステム鍵(DNSKEY)資源レコード(RR)
                    セキュリティ入口点(SEP)フラグ

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 (2004).  All Rights Reserved.

Abstract
概要

   With the Delegation Signer (DS) resource record (RR), the concept of
   a public key acting as a secure entry point (SEP) has been
   introduced.  During exchanges of public keys with the parent there is
   a need to differentiate SEP keys from other public keys in the Domain
   Name System KEY (DNSKEY) resource record set.  A flag bit in the
   DNSKEY RR is defined to indicate that DNSKEY is to be used as a SEP.
   The flag bit is intended to assist in operational procedures to
   correctly generate DS resource records, or to indicate what DNSKEYs
   are intended for static configuration.  The flag bit is not to be
   used in the DNS verification protocol.  This document updates RFC
   2535 and RFC 3755.
   委任署名者(DS)資源レコード(RR)で、セキュリティ入口点(SEP)
   の役を務めている公開鍵の概念が紹介されました。親との公開鍵の交換の間
   に、ドメインネームシステム鍵(DNSKEY)資源レコードセットの他の
   公開鍵とSEP鍵を区別する必要があります。DNSKEYのRRのフラグ
   ビットは、DNSKEYがSEPとして用いられるはずであることを示すた
   めに定義されます。フラグビットは正確にDS資源レコードを生み出すか、
   あるいはどのDNSKEYが静的設定に意図されるか示すために使用可能な
   手順のサポートを意図します。フラグビットはDNS検証プロトコルで使わ
   れないはずです。この文書はRFC2535とRFC3755を更新します。


Table of Contents
目次

   1.  Introduction
   1.  はじめに
   2.  The Secure Entry Point (SEP) Flag
   2.  セキュリティ入口点(SEP)フラグ
   3.  DNSSEC Protocol Changes
   3.  DNSSECプロトコルの変更
   4.  Operational Guidelines
   4.  運用ガイドライン
   5.  Security Considerations
   5.  セキュリティの考察
   6.  IANA Considerations
   6.  IANAの考慮
   7.  Internationalization Considerations
   7.  国際化の考慮
   8.  Acknowledgments
   8. 謝辞
   9.  References
   9.  参考文献
       9.1.  Normative References
       9.1.  参照する参考文献

       9.2.  Informative References
       9.2.  有益な参考文献
   10. Authors' Addresses
   10. 著者のアドレス
   11. Full Copyright Statement
   11. 著作権表示全文


1.  Introduction
1.  はじめに

   "All keys are equal but some keys are more equal than others" [6].
   "すべての鍵は平等ですが、ある鍵が他よりより平等です" [6]

   With the definition of the Delegation Signer Resource Record (DS RR)
   [5], it has become important to differentiate between the keys in the
   DNSKEY RR set that are (to be) pointed to by parental DS RRs and the
   other keys in the DNSKEY RR set.  We refer to these public keys as
   Secure Entry Point (SEP) keys.  A SEP key either used to generate a
   DS RR or is distributed to resolvers that use the key as the root of
   a trusted subtree [3].
   委任署名者資源レコード(DS資源レコード)の定義[5]で、DNSKEY資
   源レコード集合で親DS資源レコードから示される鍵と、DNSKEY資源
   レコード集合の他の鍵との区別が重要になりました。我々はこれらの公開鍵
   をセキュリティ入口点(SEP)の鍵と述べます。SEP鍵はDS資源レコー
   ドの生成で使われるか、信頼部分木[3]の頂点としてリゾルバに配布されます。

   In early deployment tests, the use of two (kinds of) key pairs for
   each zone has been prevalent.  For one kind of key pair the private
   key is used to sign just the zone's DNSKEY resource record (RR) set.
   Its public key is intended to be referenced by a DS RR at the parent
   or configured statically in a resolver.  The private key of the other
   kind of key pair is used to sign the rest of the zone's data sets.
   The former key pair is called a key-signing key (KSK) and the latter
   is called a zone-signing key (ZSK).  In practice there have been
   usually one of each kind of key pair, but there will be multiples of
   each at times.
   早期展開テストで、各ゾーンで2(種類の)鍵対を使うのは広く行われまし
   た。1種類の鍵対の秘密鍵はソーンのDNSKEY資源レコード(RR)集
   合の署名に使われます。その公開鍵は親でのDS資源レコードで参照される
   ように意図されるか、あるいはリゾルバで静的に配置されます。他の種類の
   鍵対の秘密鍵はは地域のデータセットの残りを署名するために使われます。
   前の鍵対は鍵署名鍵(KSK)と呼ばれます、そして後者は地域署名鍵(Z
   SK)と呼ばれます。実際は、通常それぞれの種類の鍵対が1つであったが、
   ときどきそれぞれの複数ありました。

   It should be noted that division of keys pairs into KSK's and ZSK's
   is not mandatory in any definition of DNSSEC, not even with the
   introduction of the DS RR.  But, in testing, this distinction has
   been helpful when designing key roll over (key super-cession)
   schemes.  Given that the distinction has proven helpful, the labels
   KSK and ZSK have begun to stick.
   鍵対をKSKとZSKに分割するのは、DS資源レコードの導入ででも、D
   NSSECのどの定義でも義務ではないことを指摘します。けれども、テス
   トで、この区別は、鍵変更(鍵スーパー譲渡)を計画する際に助けになりま
   した。区別が助けになると分かったので、KSKとZSKのラベルが付きま
   した。

   There is a need to differentiate the public keys for the key pairs
   that are used for key signing from keys that are not used key signing
   (KSKs vs ZSKs).  This need is driven by knowing which DNSKEYs are to
   be sent for generating DS RRs, which DNSKEYs are to be distributed to
   resolvers, and which keys are fed to the signer application at the
   appropriate time.
   鍵署名に使われた鍵と鍵署名で使わていない鍵の区別(KSK対ZSK)の
   鍵対の公開鍵を区別する必要があります。この必要性は、どのDNSKEY
   がDS資源レコードを生成するために送られたか、どのDNSKEYがリゾ
   ルバに配られて、どの鍵が適切な時に鍵署名者アプリケーションに入れられ
   るかを、知るためです。

   In other words, the SEP bit provides an in-band method to communicate
   a DNSKEY RR's intended use to third parties.  As an example we
   present 3 use cases in which the bit is useful:
   換言すれば、SEPビットは第三者にDNSKEY資源レコードの意図的な
   使用法を伝達するインバンドの方法を供給します。例えば、我々はビットが
   有用である3つの使用例を示します:

      The parent is a registry, the parent and the child use secured DNS
      queries and responses, with a preexisting trust-relation, or plain
      DNS over a secured channel to exchange the child's DNSKEY RR sets.
      Since a DNSKEY RR set will contain a complete DNSKEY RRset the SEP
      bit can be used to isolate the DNSKEYs for which a DS RR needs to
      be created.
      親はレジストリです、親と子は事前の信頼関係でセキュアDNS問合せと
      応答を使うか、子のDNSKEY資源レコードの交換に安全に保たれたチャ
      ネル上でそのままのDNSを使います。DNSKEY資源レコード集合が
      完全なDNSKEY資源レコード集合を含んでいるであろから、SEPビッ
      トはDS資源レコードが作られる必要があるDNSKEYを分離するため
      に使うことができます。

      An administrator has configured a DNSKEY as root for a trusted
      subtree into security aware resolver.  Using a special purpose
      tool that queries for the KEY RRs from that domain's apex, the
      administrator will be able to notice the roll over of the trusted
      anchor by a change of the subset of KEY RRs with the DS flag set.
      管理者がセキュリティの認識のあるリゾルバで、信頼できる部分木のルー
      トとしてDNSKEYを設定します。そのドメインの頂上から鍵資源レコー
      ドを問合せる特別な目的のツールを使って、管理者はDSフラグを設定し
      た鍵資源レコードの一部の変更によって信頼できる錨の変更に気付くこと
      が可能であるでしょう。

      A signer might use the SEP bit on the public key to determine
      which private key to use to exclusively sign the DNSKEY RRset and
      which private key to use to sign the other RRsets in the zone.
      署名者が公開鍵のSEPビットを、どの秘密鍵が排他的にDNSKEY資
      源レコードに署名するために使われるか、そしてどの秘密鍵が他のゾーン
      の資源レコードの署名に使われるか、決定するために使うかもしれません。

   As demonstrated in the above examples it is important to be able to
   differentiate the SEP keys from the other keys in a DNSKEY RR set in
   the flow between signer and (parental) key-collector and in the flow
   between the signer and the resolver configuration.  The SEP flag is
   to be of no interest to the flow between the verifier and the
   authoritative data store.
   上記の例で証明されるように、署名者と(親)鍵収集者間のフローと署名者
   とリゾルバ設定間のフローでDNSKEY資源レコード照合で他の鍵からS
   EP鍵を区別することが可能であることは重要です。SEPフラグは検証者
   と正式なデータ保管者間のフローでは重要でありません。

   The reason for the term "SEP" is a result of the observation that the
   distinction between KSK and ZSK key pairs is made by the signer, a
   key pair could be used as both a KSK and a ZSK at the same time.  To
   be clear, the term SEP was coined to lessen the confusion caused by
   the overlap.  (Once this label was applied, it had the side effect of
   removing the temptation to have both a KSK flag bit and a ZSK flag
   bit.)
   用語「SEP」の理由はKSKとZSK鍵対の間の区別が署名者によってさ
   れるという観察の結果です、鍵対が同時にKSKとZSKの両方に用いるこ
   とができます。明確化のために、用語SEPが重複による混乱を減らすため
   に造り出されました。(このラベルが適用されると、KSKフラグとZSK
   フラグの両方を持つ誘惑を除く副作用があります。)

   The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED",
   "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be
   interpreted as described in BCP 14, RFC 2119 [1].
   この文書のキーワード"MAY"と"MAY NOT"と"MUST"と"MUST NOT"と"REQUIRED"
   と"RECOMMENDED"と"SHOULD"と"SHOULD NOT"はBCP14、RFC2119
   [1]で記述したように、解釈されるはずです。

2.  The Secure Entry Point (SEP) Flag
2.  セキュリティ入口点(SEP)フラグ

                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              flags          |S|   protocol    |   algorithm   |
   |                             |E|               |               |
   |                             |P|               |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               /
   /                        public key                             /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          DNSKEY RR Format
              DNSKEY資源レコードフォーマット

   This document assigns the 15th bit in the flags field as the secure
   entry point (SEP) bit.  If the bit is set to 1 the key is intended to
   be used as secure entry point key.  One SHOULD NOT assign special
   meaning to the key if the bit is set to 0.  Operators can recognize
   the secure entry point key by the even or odd-ness of the decimal
   representation of the flag field.
   この文書は、フラグフィールドの第15番目のビットにセキュリティ入口点
   (SEP)ビットを割り当てます。もしビットが1に設定されるなら、鍵は
   セキュリティ入口点の鍵として用いられるように意図されます。もしビット
   が0に設定されるなら、特別な意味を鍵に割り当てるべきではありません
   (SHOULD NOT)。オペレータがセキュリティ入口点の鍵をフラグフィールドの
   10進数表現の偶数奇数で見分けることができます。

3.  DNSSEC Protocol Changes
3.  DNSSECプロトコルの変更

   The bit MUST NOT be used during the resolving and verification
   process.  The SEP flag is only used to provide a hint about the
   different administrative properties of the key and therefore the use
   of the SEP flag does not change the DNS resolution protocol or the
   resolution process.
   ビットは解決と検証処理で使われてはなりません(MUST NOT)。SEPフラグ
   は鍵の異なる管理特性にについてヒントを供給するためにだけ使います、そ
   れ故にSEPフラグの使用はDNS解決プロトコルあるいは解決処理を変え
   ません。

4.  Operational Guidelines
4.  運用ガイドライン

   The SEP bit is set by the key-pair-generator and MAY be used by the
   zone signer to decide whether the public part of the key pair is to
   be prepared for input to a DS RR generation function.  The SEP bit is
   recommended to be set (to 1) whenever the public key of the key pair
   will be distributed to the parent zone to build the authentication
   chain or if the public key is to be distributed for static
   configuration in verifiers.
   SEPビットは鍵対生成機が設定し、鍵対の公開部がDS資源レコード生成
   機能の入力に対するものか決定するために、ゾーン署名者が使うかもしれま
   せん(MAY)。鍵対の公開鍵が認証鎖を作るために親ゾーンに配られるであろう
   時、あるいはもし公開鍵が検証の静的設定のために配られるなら、SEPビッ
   トが(1に)設定されるように勧められます。

   When a key pair is created, the operator needs to indicate whether
   the SEP bit is to be set in the DNSKEY RR.  As the SEP bit is within
   the data that is used to compute the 'key tag field' in the SIG RR,
   changing the SEP bit will change the identity of the key within DNS.
   In other words, once a key is used to generate signatures, the
   setting of the SEP bit is to remain constant.  If not, a verifier
   will not be able to find the relevant KEY RR.
   鍵対が作られる時、オペレータはDNSKEY資源レコードのSEPビット
   が設定されるはずかどうか示す必要があります。SEPビットが署名資源レ
   コードの「鍵タグフィールド」を計算するために使われるデータの中である
   から、SEPビットを変えることはDNSの鍵識別子を変えるでしょう。換
   言すれば、鍵が署名を生み出すために使われたら、SEPビットの設定は変
   更されないままでいるはずです。そうでなければ、検証者が適切な鍵資源レ
   コードを見いだすことが可能ではないでしょう。

   When signing a zone, it is intended that the key(s) with the SEP bit
   set (if such keys exist) are used to sign the KEY RR set of the zone.
   The same key can be used to sign the rest of the zone data too.  It
   is conceivable that not all keys with a SEP bit set will sign the
   DNSKEY RR set, such keys might be pending retirement or not yet in
   use.
   ゾーンに署名する時、SEPビットが設定された鍵(もしあれば)はゾーン
   の鍵資源レコードの署名に使われることが意図されます。同じ鍵をゾーンデー
   タの残りの署名に使うこともできます。SEPビットを持つ鍵の全てがDN
   EKEY資源レコード集合に署名するのではないことを想像可能で、このよ
   うな鍵は引退待ちか、まだ使用されていないのかもしれません。

   When verifying a RR set, the SEP bit is not intended to play a role.
   How the key is used by the verifier is not intended to be a
   consideration at key creation time.
   資源レコード集合を検証する時、SEPビットは役割が意図されません。鍵
   が検証者に使われる方法は鍵生成時に考慮される事を意図しません。

   Although the SEP flag provides a hint on which public key is to be
   used as trusted root, administrators can choose to ignore the fact
   that a DNSKEY has its SEP bit set or not when configuring a trusted
   root for their resolvers.
   SEPフラグが信頼ルートとしてどの公開鍵が使われるかのヒントを供給す
   るが、管理者はリゾルバに信頼ルートを設定するときにSEPビットを無視
   するように選択できます。

   Using the SEP flag a key roll over can be automated.  The parent can
   use an existing trust relation to verify DNSKEY RR sets in which a
   new DNSKEY RR with the SEP flag appears.
   SEPビットを使い、鍵交換の自動化ができます。親は既存の信頼関係を、
   新しいSEPビットを設定したDNSKEY資源レコードを含む、DNEK
   EY資源レコード集合の検証に使えます。

5.  Security Considerations
5.  セキュリティの考察

   As stated in Section 3 the flag is not to be used in the resolution
   protocol or to determine the security status of a key.  The flag is
   to be used for administrative purposes only.
   3章で述べられるように、フラグは解決プロトコルで使わず、鍵のセキュリ
   ティ状態を決定しません。フラグは管理上の目的でのみ使われるはずです。

   No trust in a key should be inferred from this flag - trust MUST be
   inferred from an existing chain of trust or an out-of-band exchange.
   鍵の信頼がこのフラグから推論されるべきではありません−信頼は既存の信
   頼連鎖かアウトバンド交換から推論されなくてはなりません(MUST)。

   Since this flag might be used for automating public key exchanges, we
   think the following consideration is in place.
   このフラグが公開鍵交換を自動化することに対して使われるかもしれないの
   で、我々は次の考察があると思います。

   Automated mechanisms for roll over of the DS RR might be vulnerable
   to a class of replay attacks.  This might happen after a public key
   exchange where a DNSKEY RR set, containing two DNSKEY RRs with the
   SEP flag set, is sent to the parent.  The parent verifies the DNSKEY
   RR set with the existing trust relation and creates the new DS RR
   from the DNSKEY RR that the current DS RR is not pointing to.  This
   key exchange might be replayed.  Parents are encouraged to implement
   a replay defense.  A simple defense can be based on a registry of
   keys that have been used to generate DS RRs during the most recent
   roll over.  These same considerations apply to entities that
   configure keys in resolvers.
   DS資源レコードの自動交換メカニズムは、再生攻撃に弱いかもしれません。
   これは公開鍵交換の直後に起こるかもしれません、SEPフラグを設定した
   2つのDNSKEY資源レコードを含むDNSKEY資源レコード集合が親
   に送られるかもしれません。親は既存の信頼関係でDNSKEY資源レコー
   ド集合を検証し、そして現在のDS資源レコードが示していないDNSKE
   Y資源レコードから新しいDS資源レコードを作ります。この鍵交換は再生
   されるかもしれません。親が再生防衛を実行するよう奨励されます。単純な
   防衛は最新の鍵変更の際のDS資源レコードを生成に使われる鍵の登録に基
   づき得ます。同じ考察はリゾルバに鍵設定する場合に当てはまります。

6.  IANA Considerations
6.  IANAの考慮

   IANA has assigned the 15th bit in the DNSKEY Flags Registry (see
   Section 4.3 of [4]) as the Secure Entry Point (SEP) bit.
   IANAは、DNSKEYフラグ登記所([4]のセ4.3章参照)で15番目
   のビットをセキュリティ入口点(SEP)ビットに割当てました。

7.  Internationalization Considerations
7.  国際化の考慮

   Although SEP is a popular acronym in many different languages, there
   are no internationalization considerations.
   SEPが多くの異なる言語でよくある頭字語であるが、国際化の考慮があり
   ません。

8.  Acknowledgments
8. 謝辞

   The ideas documented in this document are inspired by communications
   we had with numerous people and ideas published by other folk.  Among
   others Mark Andrews, Rob Austein, Miek Gieben, Olafur Gudmundsson,
   Daniel Karrenberg, Dan Massey, Scott Rose, Marcos Sanz and Sam Weiler
   have contributed ideas and provided feedback.
   この文書で文書化された考えは、我々と多数の人々との交流と、他の人々の
   発表した考えによって起きました。とりわけMark AndrewsとRob Austeinと
   Miek GiebenとOlafur GudmundssonとDaniel KarrenbergとDan Masseyと
   Scott RoseとMarcos SanzとSam Weilerは考えを提供し、フィードバックを
   供給しました。

   This document saw the light during a workshop on DNSSEC operations
   hosted by USC/ISI in August 2002.
   この文書は2002年8月にUSC/ISIで開催されたDNSSECオ
   ペレーションのワークショップで発表されました。

9.  References
9.  参考文献

9.1.  Normative References
9.1.  参照する参考文献


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

   [2]  Eastlake, D., "Domain Name System Security Extensions", RFC
        2535, March 1999.

   [3]  Lewis, E., "DNS Security Extension Clarification on Zone
        Status", RFC 3090, March 2001.

   [4]  Weiler, S., "Legacy Resolver Compatibility for Delegation Signer
        (DS)", RFC 3755, April 2004.

9.2.  Informative References
9.2.  有益な参考文献

   [5]  Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
        RFC 3658, December 2003.

   [6]  Orwell, G. and R. Steadman (illustrator), "Animal Farm; a Fairy
        Story", ISBN 0151002177 (50th anniversary edition), April 1996.

10.  Authors' Addresses
10.  著者のアドレス

   Olaf M. Kolkman
   RIPE NCC
   Singel 256
   Amsterdam  1016 AB
   NL

   Phone: +31 20 535 4444
   EMail: olaf@ripe.net
   URI:   http://www.ripe.net/


   Jakob Schlyter
   NIC-SE
   Box 5774
   SE-114 87 Stockholm
   Sweden

   EMail: jakob@nic.se
   URI:   http://www.nic.se/


   Edward P. Lewis
   ARIN
   3635 Concorde Parkway Suite 200
   Chantilly, VA  20151
   US


   Phone: +1 703 227 9854
   EMail: edlewis@arin.net
   URI:   http://www.arin.net/


11.  Full Copyright Statement
11.  著作権表示全文

   Copyright (C) The Internet Society (2004).  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.
   著作権(C)インターネット学会(2004)。この文書は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.
   この文書とここに含まれる情報はあるがままに供給されます、貢献者と貢献
   者が代表するか貢献者を後援する組織(もしあれば)とインターネット学会
   とインターネット技術標準化タスクフォースは、明確にも暗黙にも、この情
   報の使用が権利の侵害しないことや商業利用や特別の目的への利用に適当で
   ある事の保障を含め、全ての保証を拒否します。

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は何の立場もとりません;この様な権利を
   認識する独立の調査をしたとは述べません。RFC文書の権利に関する手続
   きの情報はBCP78とBCP79を見てください。

   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.
   IETF事務局に公開されたIPRの写しと、利用可能な許可証と、仕様書
   の実装者や利用者によってされた一般的な許可書や許可を得るためにされた
   試みの結果は、http://www.ietf.org/iprにあるIETFオンラインIPR
   貯蔵庫で得られます。

   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エディタ機能のための資金供給が現在インターネット学会によって
   供給されます。

Japanese translation by Ishida So