RFC4509 日本語訳
4509 Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records(RRs). W. Hardaker. May 2006. (Format: TXT=14155 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group W. Hardaker Request for Comments: 4509 Sparta Category: Standards Track May 2006
Hardakerがコメントのために要求するワーキンググループW.をネットワークでつないでください: 4509年のスパルタカテゴリ: 標準化過程2006年5月
Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
DNSSEC代表団署名者(DS)リソース記録におけるSHA-256の使用(RRs)
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This document specifies how to use the SHA-256 digest type in DNS Delegation Signer (DS) Resource Records (RRs). DS records, when stored in a parent zone, point to DNSKEYs in a child zone.
このドキュメントはDNS Delegation Signer(DS)リソースRecords(RRs)のSHA-256ダイジェストタイプを使用する方法を指定します。 親ゾーンに格納されると、DS記録は子供ゾーンにDNSKEYsを示します。
Table of Contents
目次
1. Introduction ....................................................2
2. Implementing the SHA-256 Algorithm for DS Record Support ........2
2.1. DS Record Field Values .....................................2
2.2. DS Record with SHA-256 Wire Format .........................3
2.3. Example DS Record Using SHA-256 ............................3
3. Implementation Requirements .....................................3
4. Deployment Considerations .......................................4
5. IANA Considerations .............................................4
6. Security Considerations .........................................4
6.1. Potential Digest Type Downgrade Attacks ....................4
6.2. SHA-1 vs SHA-256 Considerations for DS Records .............5
7. Acknowledgements ................................................5
8. References ......................................................6
8.1. Normative References .......................................6
8.2. Informative References .....................................6
1. 序論…2 2. DSのためにSHA-256アルゴリズムを実行して、サポートを記録してください…2 2.1. DSは分野値を記録します…2 2.2. DSはSHA-256ワイヤ形式で記録します…3 2.3. SHA-256を使用して、例のDSは記録します…3 3. 実現要件…3 4. 展開問題…4 5. IANA問題…4 6. セキュリティ問題…4 6.1. 潜在的ダイジェストタイプは攻撃を格下げします…4 6.2. SHA-1対DSのためのSHA-256問題は記録します…5 7. 承認…5 8. 参照…6 8.1. 標準の参照…6 8.2. 有益な参照…6
Hardaker Standards Track [Page 1] RFC 4509 Use of SHA-256 in DNSSEC DS RRs May 2006
Hardaker規格は2006年5月にDNSSEC DS RRsにおけるSHA-256のRFC4509使用を追跡します[1ページ]。
1. Introduction
1. 序論
The DNSSEC [RFC4033] [RFC4034] [RFC4035] DS RR is published in parent zones to distribute a cryptographic digest of one key in a child's DNSKEY RRset. The DS RRset is signed by at least one of the parent zone's private zone data signing keys for each algorithm in use by the parent. Each signature is published in an RRSIG resource record, owned by the same domain as the DS RRset, with a type covered of DS.
DNSSEC[RFC4033][RFC4034][RFC4035]DS RRは、子供のDNSKEY RRsetで1個のキーの暗号のダイジェストを配布するために親ゾーンで発行されます。 DS RRsetは少なくとも親で使用中のそれぞれのアルゴリズムのためにキーにサインする親ゾーンの個人的なゾーンデータの1つによってサインされます。 タイプがDSについてカバーされている状態で、各署名はDS RRsetと同じドメインによって所有されていたRRSIGリソース記録で発行されます。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119].
本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように解釈されることであるべきですか?
2. Implementing the SHA-256 Algorithm for DS Record Support
2. DSの記録的なサポートのためのSHA-256アルゴリズムを実行します。
This document specifies that the digest type code 2 has been assigned to SHA-256 [SHA256] [SHA256CODE] for use within DS records. The results of the digest algorithm MUST NOT be truncated, and the entire 32 byte digest result is to be published in the DS record.
このドキュメントは、DS記録の中の使用のためにSHA-256[SHA256][SHA256CODE]にダイジェストタイプコード2を割り当ててあると指定します。 ダイジェストアルゴリズムの結果に先端を切らせてはいけません、そして、32バイトの全体のダイジェスト結果はDS記録で発行されることです。
2.1. DS Record Field Values
2.1. DSは分野値を記録します。
Using the SHA-256 digest algorithm within a DS record will make use of the following DS-record fields:
DS記録の中でSHA-256ダイジェストアルゴリズムを使用すると、以下のDS-記録分野は利用されるでしょう:
Digest type: 2
タイプを読みこなしてください: 2
Digest: A SHA-256 bit digest value calculated by using the following
formula ("|" denotes concatenation). The resulting value is not
truncated, and the entire 32 byte result is to be used in the
resulting DS record and related calculations.
以下を読みこなしてください。 SHA-256が以下の公式を使用することによって計算されたダイジェスト値に噛み付いた、(「|」、指示、連結) 結果として起こる値は端が欠けていません、そして、32バイトの全体の結果は結果として起こるDS記録と関連する計算に使用されることです。
digest = SHA_256(DNSKEY owner name | DNSKEY RDATA)
ダイジェスト=SHA_256(DNSKEY所有者名| DNSKEY RDATA)
where DNSKEY RDATA is defined by [RFC4034] as:
どこDNSKEY RDATAは[RFC4034]によって以下と定義されるか。
DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key
DNSKEY RDATAは旗と等しいです。| プロトコル| アルゴリズム| 公開鍵
The Key Tag field and Algorithm fields remain unchanged by this document and are specified in the [RFC4034] specification.
Key Tag分野とAlgorithm分野は、このドキュメントで変わりがなくて、[RFC4034]仕様で指定されます。
Hardaker Standards Track [Page 2] RFC 4509 Use of SHA-256 in DNSSEC DS RRs May 2006
Hardaker規格は2006年5月にDNSSEC DS RRsにおけるSHA-256のRFC4509使用を追跡します[2ページ]。
2.2. DS Record with SHA-256 Wire Format
2.2. DSはSHA-256ワイヤ形式で記録します。
The resulting on-the-wire format for the resulting DS record will be as follows:
結果として起こるDS記録のためのワイヤの結果として起こる形式は以下の通りになるでしょう:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Tag | Algorithm | DigestType=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Digest (length for SHA-256 is 32 bytes) /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | キー・タグ| アルゴリズム| DigestType=2| ダイジェスト..長さ..バイト|
2.3. Example DS Record Using SHA-256
2.3. SHA-256を使用して、例のDSは記録します。
The following is an example DNSKEY and matching DS record. This DNSKEY record comes from the example DNSKEY/DS records found in section 5.4 of [RFC4034].
↓これはDNSKEYと合っているDSが記録する例です。 このDNSKEY記録は[RFC4034]のセクション5.4で見つけられた例のDNSKEY/DS記録から来ます。
The DNSKEY record:
DNSKEYは記録します:
dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
fwJr1AYtsmx3TGkJaNXVbfi/
2pHm822aJ5iI9BMzNXxeYCmZ
DRD99WYwYqUSdjMmmAphXdvx
egXd/M5+X7OrzKBaMbCVdFLU
Uh6DhweJBjEVv5f2wwjM9Xzc
nOf+EPbtG9DMBmADjFDc2w/r
ljwvFw==
) ; key id = 60485
dskey.example.com。 86400 DNSKEY256 3 5(AQOeiiR0GOMYkDshWoSKz9Xz fwJr1AYtsmx3TGkJaNXVbfi/2pHm822aJ5iI9BMzNXxeYCmZ DRD99WYwYqUSdjMmmAphXdvx egXd/M5+X7OrzKBaMbCVdFLU Uh6DhweJBjEVv5f2wwjM9Xzc nOf+EPbtG9DMBmADjFDc2w/r ljwvFw=)で。 主要なイド=60485
The resulting DS record covering the above DNSKEY record using a SHA-256 digest:
結果として起こるDSはSHA-256ダイジェストを使用することで上記のDNSKEY記録をカバーしながら、記録します:
dskey.example.com. 86400 IN DS 60485 5 2 ( D4B7D520E7BB5F0F67674A0C
CEB1E3E0614B93C4F9E99B83
83F6A1E4469DA50A )
dskey.example.com。 86400 DS60485 5 2で(D4B7D520E7BB5F0F67674A0C CEB1E3E0614B93C4F9E99B83 83F6A1E4469DA50A)
3. Implementation Requirements
3. 実現要件
Implementations MUST support the use of the SHA-256 algorithm in DS RRs. Validator implementations SHOULD ignore DS RRs containing SHA-1 digests if DS RRs with SHA-256 digests are present in the DS RRset.
実現はDS RRsにおけるSHA-256アルゴリズムの使用を支持しなければなりません。 Validator実現SHOULDはDS RRsetでSHA-256ダイジェストがあるDS RRsが存在しているならSHA-1ダイジェストを含むDS RRsを無視します。
Hardaker Standards Track [Page 3] RFC 4509 Use of SHA-256 in DNSSEC DS RRs May 2006
Hardaker規格は2006年5月にDNSSEC DS RRsにおけるSHA-256のRFC4509使用を追跡します[3ページ]。
4. Deployment Considerations
4. 展開問題
If a validator does not support the SHA-256 digest type and no other DS RR exists in a zone's DS RRset with a supported digest type, then the validator has no supported authentication path leading from the parent to the child. The resolver should treat this case as it would the case of an authenticated NSEC RRset proving that no DS RRset exists, as described in [RFC4035], Section 5.2.
validatorがSHA-256ダイジェストタイプを支持しないで、また他のどんなDS RRもゾーンのDS RRsetに支持されたダイジェストタイプで存在していないなら、validatorには、親から子供まで導かない支持された認証経路が全くあります。 レゾルバは認証されたNSEC RRsetに関するケースが、どんなDS RRsetも存在しないと立証して、扱うように本件を扱うはずです、[RFC4035]で説明されるように、セクション5.2。
Because zone administrators cannot control the deployment speed of support for SHA-256 in validators that may be referencing any of their zones, zone operators should consider deploying both SHA-1 and SHA-256 based DS records. This should be done for every DNSKEY for which DS records are being generated. Whether to make use of both digest types and for how long is a policy decision that extends beyond the scope of this document.
ゾーンの管理者が彼らのゾーンのいずれにも参照をつけているかもしれないvalidatorsでSHA-256のサポートの展開速度を制御できないので、ゾーンのオペレータは、SHA-1とSHA-256のベースのDS記録の両方を配備すると考えるべきです。 DS記録が発生しているあらゆるDNSKEYのためにこれをするべきです。 両方の使用を読みこなさせるかどうかが、タイプして、どれくらい長い間、このドキュメントの範囲で広がる政策決定であるか。
5. IANA Considerations
5. IANA問題
Only one IANA action is required by this document:
1つのIANA動作だけがこのドキュメントによって必要とされます:
The Digest Type to be used for supporting SHA-256 within DS records has been assigned by IANA.
DS記録の中でSHA-256を支持するのに使用されるべきDigest TypeはIANAによって割り当てられました。
At the time of this writing, the current digest types assigned for use in DS records are as follows:
この書くこと時点で、DS記録における使用のために選任された現在のダイジェストタイプは以下の通りです:
VALUE Digest Type Status
0 Reserved -
1 SHA-1 MANDATORY
2 SHA-256 MANDATORY
3-255 Unassigned -
状態0が予約した値のダイジェストタイプ--1 SHA-256の義務的な3-255が割り当てなかったSHA-1の義務的な2、-
6. Security Considerations
6. セキュリティ問題
6.1. Potential Digest Type Downgrade Attacks
6.1. 潜在的ダイジェストタイプダウングレード攻撃
A downgrade attack from a stronger digest type to a weaker one is possible if all of the following are true:
以下のすべてが本当であるなら、より強いダイジェストタイプから、より弱いものまでのダウングレード攻撃は可能です:
o A zone includes multiple DS records for a given child's DNSKEY,
each of which uses a different digest type.
o ゾーンはそれのそれぞれが異なったダイジェストタイプを使用する与えられた子供のDNSKEYにおいて複数のDS記録を含んでいます。
o A validator accepts a weaker digest even if a stronger one is
present but invalid.
o より強いものが現在ですが、無効であっても、validatorは、より弱いダイジェストを受け入れます。
Hardaker Standards Track [Page 4] RFC 4509 Use of SHA-256 in DNSSEC DS RRs May 2006
Hardaker規格は2006年5月にDNSSEC DS RRsにおけるSHA-256のRFC4509使用を追跡します[4ページ]。
For example, if the following conditions are all true:
以下の条件が例えばすべて本当であるなら:
o Both SHA-1 and SHA-256 based digests are published in DS records
within a parent zone for a given child zone's DNSKEY.
o SHA-1とSHA-256のベースのダイジェストの両方が与えられた子供ゾーンのDNSKEYのために親ゾーンの中のDS記録で発行されます。
o The DS record with the SHA-1 digest matches the digest computed
using the child zone's DNSKEY.
o DSはSHA-1ダイジェストマッチで子供ゾーンのDNSKEYを使用することで計算されたダイジェストを記録します。
o The DS record with the SHA-256 digest fails to match the digest
computed using the child zone's DNSKEY.
o SHA-256ダイジェストがあるDS記録は子供ゾーンのDNSKEYを使用することで計算されたダイジェストに合っていません。
Then, if the validator accepts the above situation as secure, then this can be used as a downgrade attack since the stronger SHA-256 digest is ignored.
そして、validatorが、上の状況が安全であると受け入れるなら、より強いSHA-256が読みこなすのでダウングレード攻撃が無視されるとき、これを使用できます。
6.2. SHA-1 vs. SHA-256 Considerations for DS Records
6.2. SHA-1対DS記録のためのSHA-256問題
Users of DNSSEC are encouraged to deploy SHA-256 as soon as software implementations allow for it. SHA-256 is widely believed to be more resilient to attack than SHA-1, and confidence in SHA-1's strength is being eroded by recently announced attacks. Regardless of whether the attacks on SHA-1 will affect DNSSEC, it is believed (at the time of this writing) that SHA-256 is the better choice for use in DS records.
ソフトウェア実行がそれを考慮するとすぐに、DNSSECのユーザがSHA-256を配備するよう奨励されます。 SHA-256はSHA-1より攻撃に弾力があると広く信じられていて、SHA-1の強さにおける信用は最近発表された攻撃で浸食されています。 SHA-1に対する攻撃がDNSSECに影響するかどうかにかかわらず、SHA-256がDS記録における使用のための、より良い選択であると信じられています(この書くこと時点で)。
At the time of this publication, the SHA-256 digest algorithm is considered sufficiently strong for the immediate future. It is also considered sufficient for use in DNSSEC DS RRs for the immediate future. However, future published attacks may weaken the usability of this algorithm within the DS RRs. It is beyond the scope of this document to speculate extensively on the cryptographic strength of the SHA-256 digest algorithm.
この公表時点で、SHA-256ダイジェストアルゴリズムは十分強いと即座の未来と考えられます。 また、それはDNSSEC DS RRsにおける、即座の未来の使用に十分であると考えられます。 しかしながら、今後の発行された攻撃はDS RRsの中でこのアルゴリズムのユーザビリティを弱めるかもしれません。 それは、手広くSHA-256ダイジェストアルゴリズムの暗号の強さを推測するためにこのドキュメントの範囲を超えています。
Likewise, it is also beyond the scope of this document to specify whether or for how long SHA-1 based DS records should be simultaneously published alongside SHA-256 based DS records.
同様に、指定するこのドキュメントの範囲を超えてもいる、同時にどれくらい長い間SHA-1のベースのDS記録がそうであるべきであるかために、または、SHA-256のベースのDS記録と並んで発行されています。
7. Acknowledgements
7. 承認
This document is a minor extension to the existing DNSSEC documents and those authors are gratefully appreciated for the hard work that went into the base documents.
このドキュメントはDNSSECが記録する存在への小さい方の拡大です、そして、元にした文書を調べたきつい仕事のために感謝してそれらの作者に感謝します。
The following people contributed to portions of this document in some fashion: Mark Andrews, Roy Arends, Olafur Gudmundsson, Paul Hoffman, Olaf M. Kolkman, Edward Lewis, Scott Rose, Stuart E. Schechter, Sam Weiler.
以下の人々は何らかのファッションによるこのドキュメントの一部に貢献しました: アンドリュース、ロイArends、Olafurグドムンソン、ポール・ホフマン、オラフM.Kolkman、エドワード・ルイス、スコット・ローズ、スチュアート・E.シェクター、サム・ウィーラーをマークしてください。
Hardaker Standards Track [Page 5] RFC 4509 Use of SHA-256 in DNSSEC DS RRs May 2006
Hardaker規格は2006年5月にDNSSEC DS RRsにおけるSHA-256のRFC4509使用を追跡します[5ページ]。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005.
[RFC4033] Arends、R.Austein、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、「DNSセキュリティ序論と要件」(RFC4033)は2005を行進させます。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security
Extensions", RFC 4034, March 2005.
[RFC4034] Arends、R.、Austein、R.、ラーソン、M.、マッシー、D.、およびS.が上昇したと「リソースはDNSセキュリティ拡張子のために記録します」、RFC4034、2005年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
[RFC4035]Arends(R.、Austein、R.、ラーソン、M.、マッシー、D.、およびS.ローズ)は「DNSセキュリティ拡張子のための変更について議定書の中で述べます」、RFC4035、2005年3月。
[SHA256] National Institute of Standards and Technology, "Secure
Hash Algorithm. NIST FIPS 180-2", August 2002.
[SHA256]米国商務省標準技術局、「細切れ肉料理アルゴリズムを保証してください。」 NIST FIPS、1802インチ、8月2002日
8.2. Informative References
8.2. 有益な参照
[SHA256CODE] Eastlake, D., "US Secure Hash Algorithms (SHA)", Work in
Progress.
[SHA256CODE] イーストレーク、D.、「米国の安全な細切れ肉料理アルゴリズム(SHA)」が進行中で働いています。
Author's Address
作者のアドレス
Wes Hardaker Sparta P.O. Box 382 Davis, CA 95617 USA
ウェスHardakerスパルタP.O. Box382カリフォルニア95617デイヴィス(米国)
EMail: hardaker@tislabs.com
メール: hardaker@tislabs.com
Hardaker Standards Track [Page 6] RFC 4509 Use of SHA-256 in DNSSEC DS RRs May 2006
Hardaker規格は2006年5月にDNSSEC DS RRsにおけるSHA-256のRFC4509使用を追跡します[6ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
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 provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Hardaker Standards Track [Page 7]
Hardaker標準化過程[7ページ]
一覧
スポンサーリンク
