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


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)
DNSSEC委任署名(DS)資源レコード(RR)でのSHA−256の使用

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).

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委任署名(DS)資源記録(RR)でSHA−
   256要約種別を使うべきか明示します。委任署名レコードが、親ゾーン
   に保管されるとき、子ゾーンでDNSKEYを指し示します。

Table of Contents
目次

   1. Introduction
   1. はじめに
   2. Implementing the SHA-256 Algorithm for DS Record Support
   2. 委任署名レコードサポートのためにSHA−256アルゴリズムを実装すること
      2.1. DS Record Field Values
      2.1. 委任署名レコードフィールド値
      2.2. DS Record with SHA-256 Wire Format
      2.2. SHA−256を伴う委任署名レコードのワイヤフォーマット
      2.3. Example DS Record Using SHA-256
      2.3. SHA−256を使う委任署名レコード例
   3. Implementation Requirements
   3. 実装必要条件
   4. Deployment Considerations
   4. 配置の考慮
   5. IANA Considerations
   5. IANAの考慮
   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. 委任署名記録に対するSHA−1とSHA−256の考察
   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.
   DNSSEC[RFC4033] [RFC4034] [RFC4035]委任署名資源レコードは子の
   DNSKEY資源レコード集合の鍵の1つの暗号ダイジェストを配布するた
   めに親地域で公開されます。委任署名資源レコード集合は親が使用中のそれ
   ぞれのアルゴリズムに対し、親ゾーンの秘密ゾーンデータ署名鍵の少なくと
   も1個によって署名されます。それぞれの署名が、委任署名資源レコード集
   合と同じドメイン名で、委任署名を覆う種別の、資源レコード署名資源レコー
   ドで公開されます。

   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.  委任署名レコードサポートのために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.
   この文書は、委任署名レコード等に使用のために、ダイジェスト種別コード
   2にSHA−256[SHA256] [SHA256CODE]を割り当てられたことを明示しま
   す。ダイジェストアルゴリズムの結果は切り落とされてはなりません
   (MUST NOT)、そして全部で32バイトのダイジェスト結果は委任署名レコー
   ドで公にされるはずです。

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:
   委任署名レコードの中でSHA−256ダイジェストアルゴリズムを使う
   時は、次の委任署名レコードフィールドを利用するでしょう:

   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)

      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.  SHA−256を伴う委任署名レコードのワイヤフォーマット

   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.  SHA−256を使う委任署名レコード例

   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の例であろ、委任署名レコードに一致します。このDN
   SKEYレコードは[RFC4034]の5.4章で見いだされたDNSKEY/委
   任署名レコード例から来ます。

   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

   The resulting DS record covering the above DNSKEY record using a
   SHA-256 digest:
   SHA−256ダイジェストを使って上記のDNSKEYレコードをカバー
   する委任署名レコード:

   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.
   実装が委任署名資源レコードでSHA−256アルゴリズムの使用をサポー
   トしなくてはなりません(MUST)。もしSHA−256ダイジェストを持って
   いる委任署名資源レコードが委任署名資源レコード集合に存在しているなら、
   検証者実装は SHA−1ダイジェストを含んでいる委任署名資源レコードを
   無視するべきです(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.
   もし検証者がSHA-256ダイジェスト種別をサポートせず、そしてゾー
   ンの委任署名資源レコード集合に他のサポートするダイジェスト種別が存在
   しないなら、検証者には親から子へのサポートした認証経路がありません。
   リゾルバは、[RFC4035]の5.2章で記述されるように、この場合を、委任
   署名資源レコード集合が存在しないことを証明している認証されたNSEC
   資源レコード集合の場合のように、扱うべきです。

   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.
   ゾーン管理者がゾーンを参照しているかもしれない検証者のSHA−256
   に対するサポートの配置スピードを管理することができないから、ゾーン操
   作者はSHA−1とSHA−256ベースの委任署名レコードの両方を配置
   することを考えるべきです。これは委任署名レコードが生成されているすべ
   ての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.
   委任署名レコードでSHA−256のために使われるダイジェスト種別は
   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  ゾーンにある子のDNSKEYの多数の委任署名レコードが含まれます、
      そしてそれぞれが異なるダイジェスト種別を使います。

   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  ある子ゾーンのDNSKEYに対し、SHA−1とSHA−256ベー
      スのダイジェストの両方がの親ゾーンの委任署名レコードで公開されます。

   o  The DS record with the SHA-1 digest matches the digest computed
      using the child zone's DNSKEY.
   o  SHA−1ダイジェストを持つ委任署名レコードは子ゾーンのDNSK
      EYを使って計算されたダイジェストと一致します。

   o  The DS record with the SHA-256 digest fails to match the digest
      computed using the child zone's DNSKEY.
   o SHA−256ダイジェストを持つ委任署名レコードは子ゾーンのDN
      SKEYを使って計算されたダイジェストと一致しません。

   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.
   それから、もし検証者が上の状況を安全であると受け取るなら、もっと強い
   SHA−256ダイジェストが無視されますから、これは格下げ攻撃として
   使用されることができます。

6.2.  SHA-1 vs. SHA-256 Considerations for DS Records
6.2.  委任署名記録に対するSHA−1と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に
   影響を与えるであろうかどうかにかかわらず、委任署名でレコードでSH
   A−256を使うのがよりよい選択肢であると(この執筆時点で)信じら
   れています。

   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委任
   署名資源レコードでの用途に十分であると思われます。しかしながら、将
   来公開される攻撃が委任署名資源レコードでのこのアルゴリズムの有用性
   を弱めるかもしれません。広範囲に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−256ベースの委任署名レコードと平行してSHA−1
   ベースの委任署名レコードを公開するかあるいはどれぐらいの期間公開す
   べきか明示することはこの文書の範囲を越えてます。

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

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 provided by the IETF
   Administrative Support Activity (IASA).
   RFCエディタ機能のための資金供給が現在インターネット学会によって
   供給されます。


Japanese translation by Ishida So