[要約] RFC 3757は、DNSKEYリソースレコードのSEPフラグに関する仕様を定めています。この仕様の目的は、DNSSECにおける鍵管理のためにSEPフラグを使用する方法を提供することです。
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.
著作権（c）The Internet Society（2004）。無断転載を禁じます。
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）として機能する公開鍵の概念が導入されました。親とのパブリックキーの交換中、SEPキーをドメイン名システムキー（DNSKEY）リソースレコードセットの他のパブリックキーと区別する必要があります。DNSKEY RRのフラグビットは、DNSKEYがSEPとして使用されることを示すように定義されています。フラグビットは、DSリソースレコードを正しく生成するための運用手順を支援するか、DNSKEYが静的構成を目的としているものを示すことを目的としています。フラグビットは、DNS検証プロトコルでは使用されません。このドキュメントは、RFC 2535およびRFC 3755を更新します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Secure Entry Point (SEP) Flag. . . . . . . . . . . . . . . 4
3. DNSSEC Protocol Changes. . . . . . . . . . . . . . . . . . . . 4
4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 6
7. Internationalization Considerations. . . . . . . . . . . . . . 6
8. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . 6
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8
"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 RR）[5]の定義により、親のDS RRSとDNSKEYの他のキーによって（そうであるように）指されるDNSKEY RRセットのキーを区別することが重要になっています。RRセット。これらのパブリックキーを安全なエントリポイント（SEP）キーと呼びます。DS RRを生成するために使用されるSEPキーは、キーを信頼できるサブツリーのルートとして使用するリゾルバーに分布しています[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 RRによって参照されるか、リゾルバーで静的に構成されることを目的としています。他の種類のキーペアの秘密鍵は、ゾーンの残りのデータセットに署名するために使用されます。前者のキーペアはキーシインキー（KSK）と呼ばれ、後者はゾーン署名キー（ZSK）と呼ばれます。実際には、通常、それぞれの種類のキーペアの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はDNSSECの定義では必須ではなく、DS RRの導入ではありません。しかし、テストでは、キーロールオーバー（キースーパーケンセッション）スキームを設計する際に、この区別が役立ちました。区別が役立つことが証明されていることを考えると、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.
キーペアのキーペアのパブリックキーを、キーサイン（KSKS vs ZSK）を使用していないキーからのキー署名に使用する必要があります。このニーズは、どのdnskeyがDS RRを生成するために送信されるかを知ることによって促進されます。これは、どの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 RRの意図された使用を第三者に伝えるための帯域内の方法を提供します。例として、ビットが役立つ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クエリと応答を使用し、安全なチャネル上のプレーンDNSを使用して、子供のDNSKEYRRセットを交換します。DNSKEY RRセットには完全なDNSKEY RRSetが含まれるため、SEPビットを使用して、DS RRを作成する必要がある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をセキュリティ認識リゾルバーに設定しました。そのドメインの頂点からキーRRを照会する特別な目的ツールを使用して、管理者は、DSフラグセットを使用してキーRRSのサブセットの変更により、信頼できるアンカーのロールオーバーに気付くことができます。
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 RRSETにのみ署名するために使用する秘密鍵と、ゾーン内の他のRRSetsに署名するために使用する秘密鍵を決定する場合があります。
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.
上記の例で示されているように、SEPキーを他のキーからSEPキーを、署名者と（親の）キーコレクターの間のフローと署名者とリゾルバー構成の間のフローで設定したDNSKEY RRの分布を区別できることが重要です。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].
キーワード「可能性はありません」、「そうでない」、「必須」、「必須」、「必須」、「推奨」、「必要」、「必要」は、このドキュメントの「はない」、BCP 14で説明されているように解釈されるべきです、RFC 2119 [1]。
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.
DNSKEY RRフォーマットこのドキュメントは、Flagsフィールドの15番目のビットを安全なエントリポイント（SEP）ビットとして割り当てます。ビットが1に設定されている場合、キーは安全なエントリポイントキーとして使用することを目的としています。ビットが0に設定されている場合、キーに特別な意味を割り当てないでください。オペレーターは、フラッグフィールドの小数表の偶数または奇数によって安全なエントリポイントキーを認識できます。
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.
ビットは、解決および検証プロセス中に使用してはなりません。SEPフラグは、キーのさまざまな管理プロパティに関するヒントを提供するためにのみ使用されます。したがって、SEPフラグの使用は、DNS解像度プロトコルまたは解像度プロセスを変更しません。
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 RR生成関数への入力のために準備されるかどうかを決定できます。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.
キーペアが作成された場合、演算子はSEPビットをDNSKEY RRに設定するかどうかを示す必要があります。SEPビットはSIG RRの「キータグフィールド」を計算するために使用されるデータ内にあるため、SEPビットを変更すると、DNS内のキーのIDが変更されます。言い換えれば、キーが署名を生成するために使用されると、SEPビットの設定は一定のままであることです。そうでない場合、検証剤は関連するキー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.
ゾーンに署名するとき、SEPビットセットのキー（そのようなキーが存在する場合）がゾーンのキーRRセットに署名するために使用されることを意図しています。同じキーを使用して、ゾーンデータの残りの部分にも署名できます。SEPビットセットを持つすべてのキーがDNSKEY RRセットに署名するわけではないと考えられます。そのようなキーは、退職が保留されているか、まだ使用されていない可能性があります。
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.
RRセットを検証するとき、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フラグは、どの公開キーを信頼できるルートとして使用するかについてのヒントを提供しますが、管理者は、DNSKEYがリゾルバーの信頼ルートを構成するときに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 RRが表示されるDNSKEY RRセットを確認できます。
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.
このフラグから鍵への信頼は推測されるべきではありません - 信頼は、既存の信頼の連鎖または帯域外の交換から推測されなければなりません。
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 RRのロールオーバーの自動化されたメカニズムは、リプレイ攻撃のクラスに対して脆弱になる可能性があります。これは、SEPフラグセットを備えた2つのDNSKEY RRSを含むDNSKEY RRセットが親に送信される公開キー交換の後に発生する可能性があります。親は、既存の信頼関係でDNSKEY RRセットを検証し、現在のDS RRが指摘していないDNSKEY RRから新しいDS RRを作成します。この重要な交換は再生される可能性があります。親は、リプレイの防御を実装することをお勧めします。単純な防御は、最新のロールオーバー中にDS RRSを生成するために使用されたキーのレジストリに基づいています。これらの同じ考慮事項は、リゾルバーでキーを構成するエンティティに適用されます。
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 Flagsレジストリ（[4]のセクション4.3を参照）で15ビットを安全なエントリポイント（SEP）ビットとして割り当てました。
Although SEP is a popular acronym in many different languages, there are no internationalization considerations.
SEPは多くの異なる言語で人気のある頭字語ですが、国際化の考慮事項はありません。
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.
このドキュメントに記録されているアイデアは、他の人々によって公開された多くの人々やアイデアとのコミュニケーションに触発されています。とりわけ、マーク・アンドリュース、ロブ・オーストイン、ミーク・ギーベン、オラファー・グドムンドソン、ダニエル・カレンバーグ、ダン・マッセイ、スコット・ローズ、マルコス・サンツ、サム・ワイラーがアイデアを提供し、フィードバックを提供しました。
This document saw the light during a workshop on DNSSEC operations hosted by USC/ISI in August 2002.
このドキュメントでは、2002年8月にUSC/ISIが主催するDNSSEC運用に関するワークショップで光が見られました。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[2] EastLake、D。、「ドメイン名システムセキュリティ拡張機能」、RFC 2535、1999年3月。
[3] Lewis, E., "DNS Security Extension Clarification on Zone Status", RFC 3090, March 2001.
[3] Lewis、E。、「ゾーンステータスに関するDNSセキュリティ拡張の明確化」、RFC 3090、2001年3月。
[4] Weiler, S., "Legacy Resolver Compatibility for Delegation Signer (DS)", RFC 3755, April 2004.
[4] Weiler、S。、「Legacy Resolver Compatibility for Deligation Signer（DS）」、RFC 3755、2004年4月。
[5] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)", RFC 3658, December 2003.
[5] Gudmundsson、O。、「Delegation Signer（DS）Resource Record（RR）」、RFC 3658、2003年12月。
[6] Orwell, G. and R. Steadman (illustrator), "Animal Farm; a Fairy Story", ISBN 0151002177 (50th anniversary edition), April 1996.
[6] Orwell、G。およびR. Steadman（Illustrator）、「Animal Farm; A Fairy Story」、ISBN 0151002177（50周年記念版）、1996年4月。
Olaf M. Kolkman RIPE NCC Singel 256 Amsterdam 1016 AB NL
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
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
エドワードP.ルイスアリン3635コンコルドパークウェイスイート200チャンティリー、バージニア州20151米国
Phone: +1 703 227 9854
EMail: edlewis@arin.net
URI: http://www.arin.net/
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）The Internet Society（2004）。この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となりますが、著者はすべての権利を保持しています。
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ドキュメントの権利に関する手順に関する情報は、BCP 78および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.
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エディター機能の資金は現在、インターネット協会によって提供されています。