この文書はRFC3757の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
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
ドメインネームシステム鍵（ＤＮＳＫＥＹ）資源レコード（ＲＲ）
セキュリティ入口点（ＳＥＰ）フラグ
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.
この文書はインターネット共同体のためのインターネット標準化作業中のプ
ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状
態とこのプロトコル状態は「インターネット公式プロトコル標準」（ＳＴＤ
１）の現在の版を参照してください。このメモの配布は無制限です。
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.
委任署名者（ＤＳ）資源レコード（ＲＲ）で、セキュリティ入口点（ＳＥＰ）
の役を務めている公開鍵の概念が紹介されました。親との公開鍵の交換の間
に、ドメインネームシステム鍵（ＤＮＳＫＥＹ）資源レコードセットの他の
公開鍵とＳＥＰ鍵を区別する必要があります。ＤＮＳＫＥＹのＲＲのフラグ
ビットは、ＤＮＳＫＥＹがＳＥＰとして用いられるはずであることを示すた
めに定義されます。フラグビットは正確にＤＳ資源レコードを生み出すか、
あるいはどのＤＮＳＫＥＹが静的設定に意図されるか示すために使用可能な
手順のサポートを意図します。フラグビットはＤＮＳ検証プロトコルで使わ
れないはずです。この文書はＲＦＣ２５３５とＲＦＣ３７５５を更新します。
Table of Contents
目次
1. Introduction
1. はじめに
2. The Secure Entry Point (SEP) Flag
2. セキュリティ入口点（ＳＥＰ）フラグ
3. DNSSEC Protocol Changes
3. ＤＮＳＳＥＣプロトコルの変更
4. Operational Guidelines
4. 運用ガイドライン
5. Security Considerations
5. セキュリティの考察
6. IANA Considerations
6. ＩＡＮＡの考慮
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].
委任署名者資源レコード（ＤＳ資源レコード）の定義[5]で、ＤＮＳＫＥＹ資
源レコード集合で親ＤＳ資源レコードから示される鍵と、ＤＮＳＫＥＹ資源
レコード集合の他の鍵との区別が重要になりました。我々はこれらの公開鍵
をセキュリティ入口点（ＳＥＰ）の鍵と述べます。ＳＥＰ鍵はＤＳ資源レコー
ドの生成で使われるか、信頼部分木[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.
早期展開テストで、各ゾーンで２（種類の）鍵対を使うのは広く行われまし
た。１種類の鍵対の秘密鍵はソーンのＤＮＳＫＥＹ資源レコード（ＲＲ）集
合の署名に使われます。その公開鍵は親でのＤＳ資源レコードで参照される
ように意図されるか、あるいはリゾルバで静的に配置されます。他の種類の
鍵対の秘密鍵はは地域のデータセットの残りを署名するために使われます。
前の鍵対は鍵署名鍵（ＫＳＫ）と呼ばれます、そして後者は地域署名鍵（Ｚ
ＳＫ）と呼ばれます。実際は、通常それぞれの種類の鍵対が１つであったが、
ときどきそれぞれの複数ありました。
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.
鍵対をＫＳＫとＺＳＫに分割するのは、ＤＳ資源レコードの導入ででも、Ｄ
ＮＳＳＥＣのどの定義でも義務ではないことを指摘します。けれども、テス
トで、この区別は、鍵変更（鍵スーパー譲渡）を計画する際に助けになりま
した。区別が助けになると分かったので、ＫＳＫとＺＳＫのラベルが付きま
した。
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.
鍵署名に使われた鍵と鍵署名で使わていない鍵の区別（ＫＳＫ対ＺＳＫ）の
鍵対の公開鍵を区別する必要があります。この必要性は、どのＤＮＳＫＥＹ
がＤＳ資源レコードを生成するために送られたか、どのＤＮＳＫＥＹがリゾ
ルバに配られて、どの鍵が適切な時に鍵署名者アプリケーションに入れられ
るかを、知るためです。
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:
換言すれば、ＳＥＰビットは第三者にＤＮＳＫＥＹ資源レコードの意図的な
使用法を伝達するインバンドの方法を供給します。例えば、我々はビットが
有用である３つの使用例を示します：
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.
親はレジストリです、親と子は事前の信頼関係でセキュアＤＮＳ問合せと
応答を使うか、子のＤＮＳＫＥＹ資源レコードの交換に安全に保たれたチャ
ネル上でそのままのＤＮＳを使います。ＤＮＳＫＥＹ資源レコード集合が
完全なＤＮＳＫＥＹ資源レコード集合を含んでいるであろから、ＳＥＰビッ
トはＤＳ資源レコードが作られる必要があるＤＮＳＫＥＹを分離するため
に使うことができます。
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.
管理者がセキュリティの認識のあるリゾルバで、信頼できる部分木のルー
トとしてＤＮＳＫＥＹを設定します。そのドメインの頂上から鍵資源レコー
ドを問合せる特別な目的のツールを使って、管理者はＤＳフラグを設定し
た鍵資源レコードの一部の変更によって信頼できる錨の変更に気付くこと
が可能であるでしょう。
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.
署名者が公開鍵のＳＥＰビットを、どの秘密鍵が排他的にＤＮＳＫＥＹ資
源レコードに署名するために使われるか、そしてどの秘密鍵が他のゾーン
の資源レコードの署名に使われるか、決定するために使うかもしれません。
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.
上記の例で証明されるように、署名者と（親）鍵収集者間のフローと署名者
とリゾルバ設定間のフローでＤＮＳＫＥＹ資源レコード照合で他の鍵からＳ
ＥＰ鍵を区別することが可能であることは重要です。ＳＥＰフラグは検証者
と正式なデータ保管者間のフローでは重要でありません。
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.)
用語「ＳＥＰ」の理由はＫＳＫとＺＳＫ鍵対の間の区別が署名者によってさ
れるという観察の結果です、鍵対が同時にＫＳＫとＺＳＫの両方に用いるこ
とができます。明確化のために、用語ＳＥＰが重複による混乱を減らすため
に造り出されました。（このラベルが適用されると、ＫＳＫフラグとＺＳＫ
フラグの両方を持つ誘惑を除く副作用があります。）
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"はＢＣＰ１４、ＲＦＣ２１１９
[1]で記述したように、解釈されるはずです。
2. The Secure Entry Point (SEP) Flag
2. セキュリティ入口点（ＳＥＰ）フラグ
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
ＤＮＳＫＥＹ資源レコードフォーマット
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.
この文書は、フラグフィールドの第１５番目のビットにセキュリティ入口点
（ＳＥＰ）ビットを割り当てます。もしビットが１に設定されるなら、鍵は
セキュリティ入口点の鍵として用いられるように意図されます。もしビット
が０に設定されるなら、特別な意味を鍵に割り当てるべきではありません
(SHOULD NOT)。オペレータがセキュリティ入口点の鍵をフラグフィールドの
１０進数表現の偶数奇数で見分けることができます。
3. DNSSEC Protocol Changes
3. ＤＮＳＳＥＣプロトコルの変更
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)。ＳＥＰフラグ
は鍵の異なる管理特性にについてヒントを供給するためにだけ使います、そ
れ故にＳＥＰフラグの使用はＤＮＳ解決プロトコルあるいは解決処理を変え
ません。
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.
ＳＥＰビットは鍵対生成機が設定し、鍵対の公開部がＤＳ資源レコード生成
機能の入力に対するものか決定するために、ゾーン署名者が使うかもしれま
せん(MAY)。鍵対の公開鍵が認証鎖を作るために親ゾーンに配られるであろう
時、あるいはもし公開鍵が検証の静的設定のために配られるなら、ＳＥＰビッ
トが（１に）設定されるように勧められます。
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.
鍵対が作られる時、オペレータはＤＮＳＫＥＹ資源レコードのＳＥＰビット
が設定されるはずかどうか示す必要があります。ＳＥＰビットが署名資源レ
コードの「鍵タグフィールド」を計算するために使われるデータの中である
から、ＳＥＰビットを変えることはＤＮＳの鍵識別子を変えるでしょう。換
言すれば、鍵が署名を生み出すために使われたら、ＳＥＰビットの設定は変
更されないままでいるはずです。そうでなければ、検証者が適切な鍵資源レ
コードを見いだすことが可能ではないでしょう。
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.
ゾーンに署名する時、ＳＥＰビットが設定された鍵（もしあれば）はゾーン
の鍵資源レコードの署名に使われることが意図されます。同じ鍵をゾーンデー
タの残りの署名に使うこともできます。ＳＥＰビットを持つ鍵の全てがＤＮ
ＥＫＥＹ資源レコード集合に署名するのではないことを想像可能で、このよ
うな鍵は引退待ちか、まだ使用されていないのかもしれません。
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.
資源レコード集合を検証する時、ＳＥＰビットは役割が意図されません。鍵
が検証者に使われる方法は鍵生成時に考慮される事を意図しません。
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.
ＳＥＰフラグが信頼ルートとしてどの公開鍵が使われるかのヒントを供給す
るが、管理者はリゾルバに信頼ルートを設定するときにＳＥＰビットを無視
するように選択できます。
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.
ＳＥＰビットを使い、鍵交換の自動化ができます。親は既存の信頼関係を、
新しいＳＥＰビットを設定したＤＮＳＫＥＹ資源レコードを含む、ＤＮＥＫ
ＥＹ資源レコード集合の検証に使えます。
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.
３章で述べられるように、フラグは解決プロトコルで使わず、鍵のセキュリ
ティ状態を決定しません。フラグは管理上の目的でのみ使われるはずです。
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.
ＤＳ資源レコードの自動交換メカニズムは、再生攻撃に弱いかもしれません。
これは公開鍵交換の直後に起こるかもしれません、ＳＥＰフラグを設定した
２つのＤＮＳＫＥＹ資源レコードを含むＤＮＳＫＥＹ資源レコード集合が親
に送られるかもしれません。親は既存の信頼関係でＤＮＳＫＥＹ資源レコー
ド集合を検証し、そして現在のＤＳ資源レコードが示していないＤＮＳＫＥ
Ｙ資源レコードから新しいＤＳ資源レコードを作ります。この鍵交換は再生
されるかもしれません。親が再生防衛を実行するよう奨励されます。単純な
防衛は最新の鍵変更の際のＤＳ資源レコードを生成に使われる鍵の登録に基
づき得ます。同じ考察はリゾルバに鍵設定する場合に当てはまります。
6. IANA Considerations
6. ＩＡＮＡの考慮
IANA has assigned the 15th bit in the DNSKEY Flags Registry (see
Section 4.3 of [4]) as the Secure Entry Point (SEP) bit.
ＩＡＮＡは、ＤＮＳＫＥＹフラグ登記所（[4]のセ４.３章参照）で１５番目
のビットをセキュリティ入口点（ＳＥＰ）ビットに割当てました。
7. Internationalization Considerations
7. 国際化の考慮
Although SEP is a popular acronym in many different languages, there
are no internationalization considerations.
ＳＥＰが多くの異なる言語でよくある頭字語であるが、国際化の考慮があり
ません。
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.
この文書は２００２年８月にＵＳＣ／ＩＳＩで開催されたＤＮＳＳＥＣオ
ペレーションのワークショップで発表されました。
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.
著作権（Ｃ）インターネット学会（２００４）。この文書はＢＣＰ７８に含
まれる権利と許可と制限の適用を受け、そしてこの中に明らかにされる以外
は著者がすべての権利を維持します。
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.
この文書に記述された実装や技術に関して主張される知的財産権や他の権利の
正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
可能かの範囲について、ＩＥＴＦは何の立場もとりません；この様な権利を
認識する独立の調査をしたとは述べません。ＲＦＣ文書の権利に関する手続
きの情報はＢＣＰ７８とＢＣＰ７９を見てください。
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.
ＩＥＴＦ事務局に公開されたＩＰＲの写しと、利用可能な許可証と、仕様書
の実装者や利用者によってされた一般的な許可書や許可を得るためにされた
試みの結果は、http://www.ietf.org/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-ipr@ietf.orgのＩＥＴＦに情報を伝えてください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the
Internet Society.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。