この文書はRFC 4509の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group W. Hardaker Request for Comments: 4509 Sparta Category: Standards Track May 2006 Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (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. この文書はインターネット共同体のためのインターネット標準化中のプロト コルを指定し、そして改良のために議論と提案を求めます。このプロトコル と標準化状態と状況は「インターネット公式プロトコル標準」（ＳＴＤ１） の最新版を参照してください。このメモの配布は無制限です。 Copyright Notice 著作権表示 Copyright (C) The Internet Society (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. この文書はどのようにＤＮＳ委任署名（ＤＳ）資源記録（ＲＲ）でＳＨＡ− ２５６要約種別を使うべきか明示します。委任署名レコードが、親ゾーン に保管されるとき、子ゾーンでＤＮＳＫＥＹを指し示します。 Table of Contents 目次 1. Introduction 1. はじめに 2. Implementing the SHA-256 Algorithm for DS Record Support 2. 委任署名レコードサポートのためにＳＨＡ−２５６アルゴリズムを実装すること 2.1. DS Record Field Values 2.1. 委任署名レコードフィールド値 2.2. DS Record with SHA-256 Wire Format 2.2. ＳＨＡ−２５６を伴う委任署名レコードのワイヤフォーマット 2.3. Example DS Record Using SHA-256 2.3. ＳＨＡ−２５６を使う委任署名レコード例 3. Implementation Requirements 3. 実装必要条件 4. Deployment Considerations 4. 配置の考慮 5. IANA Considerations 5. ＩＡＮＡの考慮 6. Security Considerations 6. セキュリティの考察 6.1. Potential Digest Type Downgrade Attacks 6.1. ダイジェスト種別格下げ攻撃の可能性 6.2. SHA-1 vs. SHA-256 Considerations for DS Records 6.2. 委任署名記録に対するＳＨＡ−１とＳＨＡ−２５６の考察 7. Acknowledgements 7. 謝辞 8. References 8. 参考文献 8.1. Normative References 8.1. 参照する参考文献 8.2. Informative References 8.2. 有益な参考文献 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. ＤＮＳＳＥＣ[RFC4033] [RFC4034] [RFC4035]委任署名資源レコードは子の ＤＮＳＫＥＹ資源レコード集合の鍵の１つの暗号ダイジェストを配布するた めに親地域で公開されます。委任署名資源レコード集合は親が使用中のそれ ぞれのアルゴリズムに対し、親ゾーンの秘密ゾーンデータ署名鍵の少なくと も１個によって署名されます。それぞれの署名が、委任署名資源レコード集 合と同じドメイン名で、委任署名を覆う種別の、資源レコード署名資源レコー ドで公開されます。 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"と"MUST NOT"と"REQUIRED"と"SHALL"と"SHALL NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"MAY"と"OPTIONAL"は [RFC2119]で記述されるように解釈されるはずです。 2. Implementing the SHA-256 Algorithm for DS Record Support 2. 委任署名レコードサポートのためにＳＨＡ−２５６アルゴリズムを実装すること 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. この文書は、委任署名レコード等に使用のために、ダイジェスト種別コード ２にＳＨＡ−２５６[SHA256] [SHA256CODE]を割り当てられたことを明示しま す。ダイジェストアルゴリズムの結果は切り落とされてはなりません (MUST NOT)、そして全部で３２バイトのダイジェスト結果は委任署名レコー ドで公にされるはずです。 2.1. DS Record Field Values 2.1. 委任署名レコードフィールド値 Using the SHA-256 digest algorithm within a DS record will make use of the following DS-record fields: 委任署名レコードの中でＳＨＡ−２５６ダイジェストアルゴリズムを使う 時は、次の委任署名レコードフィールドを利用するでしょう： Digest type: 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. ダイジェスト：次の式（「|」が結合を意味します）を使うことで計算した ＳＨＡ−２５６ビットダイジェスト値。結果値は切り詰められません、 そして全部の３２バイトの結果は結果ＤＳ記録と関連した計算で使われ るはずです。 digest = SHA_256(DNSKEY owner name | DNSKEY RDATA) where DNSKEY RDATA is defined by [RFC4034] as: ここでDNSKEY RDATAは[RFC4034]で定義された通りです： DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key The Key Tag field and Algorithm fields remain unchanged by this document and are specified in the [RFC4034] specification. 鍵タグフィールドとアルゴリズムフィールドはこの文書でに変化せず [RFC4034]仕様で指定されます。 2.2. DS Record with SHA-256 Wire Format 2.2. ＳＨＡ−２５６を伴う委任署名レコードのワイヤフォーマット The resulting on-the-wire format for the resulting DS record will be as follows: 委任署名レコードのワイヤフォーマットが以下の通りです： 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) / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 2.3. Example DS Record Using SHA-256 2.3. ＳＨＡ−２５６を使う委任署名レコード例 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]. 次はＤＮＳＫＥＹの例であろ、委任署名レコードに一致します。このＤＮ ＳＫＥＹレコードは[RFC4034]の５.４章で見いだされたＤＮＳＫＥＹ／委 任署名レコード例から来ます。 The DNSKEY record: ＤＮＳＫＥＹレコード： dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz fwJr1AYtsmx3TGkJaNXVbfi/ 2pHm822aJ5iI9BMzNXxeYCmZ DRD99WYwYqUSdjMmmAphXdvx egXd/M5+X7OrzKBaMbCVdFLU Uh6DhweJBjEVv5f2wwjM9Xzc nOf+EPbtG9DMBmADjFDc2w/r ljwvFw== ) ; key id = 60485 The resulting DS record covering the above DNSKEY record using a SHA-256 digest: ＳＨＡ−２５６ダイジェストを使って上記のＤＮＳＫＥＹレコードをカバー する委任署名レコード： dskey.example.com. 86400 IN DS 60485 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. 実装が委任署名資源レコードでＳＨＡ−２５６アルゴリズムの使用をサポー トしなくてはなりません(MUST)。もしＳＨＡ−２５６ダイジェストを持って いる委任署名資源レコードが委任署名資源レコード集合に存在しているなら、 検証者実装は ＳＨＡ−１ダイジェストを含んでいる委任署名資源レコードを 無視するべきです(SHOULD)。 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. もし検証者がＳＨＡ-２５６ダイジェスト種別をサポートせず、そしてゾー ンの委任署名資源レコード集合に他のサポートするダイジェスト種別が存在 しないなら、検証者には親から子へのサポートした認証経路がありません。 リゾルバは、［RFC4035］の５.２章で記述されるように、この場合を、委任 署名資源レコード集合が存在しないことを証明している認証されたＮＳＥＣ 資源レコード集合の場合のように、扱うべきです。 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. ゾーン管理者がゾーンを参照しているかもしれない検証者のＳＨＡ−２５６ に対するサポートの配置スピードを管理することができないから、ゾーン操 作者はＳＨＡ−１とＳＨＡ−２５６ベースの委任署名レコードの両方を配置 することを考えるべきです。これは委任署名レコードが生成されているすべ てのＤＮＳＫＥＹのためにされるべきです。両方のダイジェスト種別を利用 するべきかどうか、そしてどれぐらい長くかは、この文書の範囲外のポリシ 決定です。 5. IANA Considerations 5. ＩＡＮＡの考慮 Only one IANA action is required by this document: たった１つのＩＡＮＡの行動がこの文書によって必要とされます： The Digest Type to be used for supporting SHA-256 within DS records has been assigned by IANA. 委任署名レコードでＳＨＡ−２５６のために使われるダイジェスト種別は ＩＡＮＡによって割り当てられました。 At the time of this writing, the current digest types assigned for use in DS records are as follows: この執筆の時点で、委任署名レコードでの使用のために割り当てられた最 新のダイジェスト種別は次の通りです： VALUE Digest Type Status 0 Reserved - 1 SHA-1 MANDATORY 2 SHA-256 MANDATORY 3-255 Unassigned - 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 ゾーンにある子のＤＮＳＫＥＹの多数の委任署名レコードが含まれます、 そしてそれぞれが異なるダイジェスト種別を使います。 o A validator accepts a weaker digest even if a stronger one is present but invalid. o たとえ強いダイジェストが存在し、無効であっても、検証者がより弱い ダイジェストを受け入れます。 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 ある子ゾーンのＤＮＳＫＥＹに対し、ＳＨＡ−１とＳＨＡ−２５６ベー スのダイジェストの両方がの親ゾーンの委任署名レコードで公開されます。 o The DS record with the SHA-1 digest matches the digest computed using the child zone's DNSKEY. o ＳＨＡ−１ダイジェストを持つ委任署名レコードは子ゾーンのＤＮＳＫ ＥＹを使って計算されたダイジェストと一致します。 o The DS record with the SHA-256 digest fails to match the digest computed using the child zone's 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. それから、もし検証者が上の状況を安全であると受け取るなら、もっと強い ＳＨＡ−２５６ダイジェストが無視されますから、これは格下げ攻撃として 使用されることができます。 6.2. SHA-1 vs. SHA-256 Considerations for DS Records 6.2. 委任署名記録に対するＳＨＡ−１とＳＨＡ−２５６の考察 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. ＤＮＳＳＥＣのユーザは、ソフトウェア実装が可能になるとすぐにＳＨＡ− ２５６を配置するよう奨励されます。ＳＨＡ−２５６がＳＨＡ−１より攻 撃に強いと広く信じられています、そしてＳＨＡ−１の強さが最近公表さ れた攻撃で侵害されています。ＳＨＡ−１に対する攻撃がＤＮＳＳＥＣに 影響を与えるであろうかどうかにかかわらず、委任署名でレコードでＳＨ Ａ−２５６を使うのがよりよい選択肢であると（この執筆時点で）信じら れています。 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. この公開の時点で、ＳＨＡ−２５６ダイジェストアルゴリズムは近い将来 の間十分に強いと思われます。それは同じく近い将来のＤＮＳＳＥＣ委任 署名資源レコードでの用途に十分であると思われます。しかしながら、将 来公開される攻撃が委任署名資源レコードでのこのアルゴリズムの有用性 を弱めるかもしれません。広範囲にＳＨＡ−２５６ダイジェストアルゴリ ズムの暗号の力についてあれこれ思索することはこの文書の範囲を越えて ます。 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. 同じく、ＳＨＡ−２５６ベースの委任署名レコードと平行してＳＨＡ−１ ベースの委任署名レコードを公開するかあるいはどれぐらいの期間公開す べきか明示することはこの文書の範囲を越えてます。 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. この文書は既存のＤＮＳＳＥＣ文書への小さい拡張です、そして、それら の著者の既存文書に注がれた困難な仕事に感謝します。 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. 次の人々はこの文書の部分にある方法で寄与しました：Mark Andrews, Roy Arends, Olafur Gudmundsson, Paul Hoffman, Olaf M. Kolkman, Edward Lewis, Scott Rose, Stuart E. Schechter, Sam Weiler.。 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. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. [SHA256] National Institute of Standards and Technology, "Secure Hash Algorithm. NIST FIPS 180-2", August 2002. 8.2. Informative References 8.2. 有益な参考文献 [SHA256CODE] Eastlake, D., "US Secure Hash Algorithms (SHA)", Work in Progress. Author's Address 著者のアドレス Wes Hardaker Sparta P.O. Box 382 Davis, CA 95617 USA EMail: hardaker@tislabs.com Full Copyright Statement 著作権表示全文 Copyright (C) The Internet Society (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. この文書はＢＣＰ７８に含まれる権利と許可と制限の適用を受け、そして この中に明らかにされる以外は著者がすべての権利を維持します。 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 provided by the IETF Administrative Support Activity (IASA). ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって 供給されます。