この文書はRFC3008の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group B. Wellington
Request for Comments: 3008 Nominum
Updates: 2535 November 2000
Category: Standards Track
Domain Name System Security (DNSSEC) Signing Authority
ドメインネームシステムセキュリティ（DNSSEC）の署名の権限
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 (2000). All Rights Reserved.
Abstract
概要
This document proposes a revised model of Domain Name System Security
(DNSSEC) Signing Authority. The revised model is designed to clarify
earlier documents and add additional restrictions to simplify the
secure resolution process. Specifically, this affects the
authorization of keys to sign sets of records.
この文書はドメインネームシステムセキュリティ（DNSSEC）の署名の権限の
修正されたモデルを提案します。修正されたモデルは以前の文書を明確にし
て、安全な解決処理を単純化するため追加の制限を加えるよう意図されます。
特に、これはレコードセットに署名する鍵の認証に影響を与えます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード"MUST"と"MUST NOT"と"REQUIRED"と"SHALL"と"SHALL
NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"MAY"と"OPTIONAL"は
RFC2119[RFC2119]に記述されるように解釈します。
1 - Introduction
1 - はじめに
This document defines additional restrictions on DNSSEC signatures
(SIG) records relating to their authority to sign associated data.
The intent is to establish a standard policy followed by a secure
resolver; this policy can be augmented by local rules. This builds
upon [RFC2535], updating section 2.3.6 of that document.
この文書は関連するデータに署名する権限に関するDNSSEC署名（SIG）レ
コードの追加の制限を定義します。この意図は安全なリゾルバの従う標準
ポリシーを確立するためです；このポリシーはローカルな規則で増加でき
ます。これは[RFC2535]を元に作られ、[RFC2535]の２.３.６章を更新しま
す。
The most significant change is that in a secure zone, zone data is
required to be signed by the zone key.
最も重要な変更は安全なゾーンで、ゾーンデータがゾーン鍵によって署名
されるように要求されるということです。
Familiarity with the DNS system [RFC1034, RFC1035] and the DNS
security extensions [RFC2535] is assumed.
読者がＤＮＳシステム[RFC1034, RFC1035]とＤＮＳセキュリティ拡張
[RFC2535]に精通してると想定します。
2 - The SIG Record
2 - 署名レコード
A SIG record is normally associated with an RRset, and "covers" (that
is, demonstrates the authenticity and integrity of) the RRset. This
is referred to as a "data SIG". Note that there can be multiple SIG
records covering an RRset, and the same validation process should be
repeated for each of them. Some data SIGs are considered "material",
that is, relevant to a DNSSEC capable resolver, and some are
"immaterial" or "extra-DNSSEC", as they are not relevant to DNSSEC
validation. Immaterial SIGs may have application defined roles. SIG
records may exist which are not bound to any RRset; these are also
considered immaterial. The validation process determines which SIGs
are material; once a SIG is shown to be immaterial, no other
validation is necessary.
署名レコードは通常資源レコード集合と対応し、資源レコード集合をカバー
します（つまり、信憑性と完全性を証明します）。これを「データ署名」と
言います。ある資源レコード集合をカバーする複数の署名レコードがあり得
て、同じ検証処理が各署名に繰返されるべきであることに注意してください。
あるデータ署名は「重要」と考えられ、これはＤＮＳＳＥＣ能力のあるリゾ
ルバに有用です、ある署名はＤＮＳＳＥＣ検証に関係がないから、「重要で
ない」あるいは「ＤＮＳＳＥＣに余分」と考えられます。重要でない書名は
アプリケーションの定義する役割を持つかもしれません。資源レコード集合
と結び付かない署名レコードが存在するかもしれません；これらは同じく重
要でないと思われます。検証プロセスはどの署名が重要か決定します；署名
が重要でないことを示されると、他の検証は必要ありません。
SIGs may also be used for transaction security. In this case, a SIG
record with a type covered field of 0 is attached to a message, and
is used to protect message integrity. This is referred to as a
SIG(0) [RFC2535, RFC2931].
署名は同じく処理セキュリティに使われるかもしれません。この場合カバー
タイプフィールドが０の署名レコードがメッセージに置かれ、メッセージ完
全性を守るために使われます。これはSIG(0)[RFC2535, RFC2931]と呼ばれます。
The following sections define requirements for all of the fields of a
SIG record. These requirements MUST be met in order for a DNSSEC
capable resolver to process this signature. If any of these
requirements are not met, the SIG cannot be further processed.
Additionally, once a KEY has been identified as having generated this
SIG, there are requirements that it MUST meet.
次の章は署名レコードフィールドのすべての必要条件を定義します。これら
の必要条件はＤＮＳＳＥＣ能力のあるリゾルバの処理の順番に順序付けられ
ます(MUST)。もしこれらの必要条件のいずれかが満たされないならそこで署
名の処理は終わります。さらに、署名を生成した鍵がわかると、その鍵への
必要条件があります(MUST)。
2.1 - Type Covered
2.1 - カバータイプ
For a data SIG, the type covered MUST be the same as the type of data
in the associated RRset. For a SIG(0), the type covered MUST be 0.
データ署名ののカバータイプは関連する資源レコード集合のデータタイプと
同じでなければなりません(MUST)。SIG(0)のカバータイプは０でなければな
りません(MUST)。
2.2 - Algorithm Number
2.2 - アルゴリズム番号
The algorithm specified in a SIG MUST be recognized by the client,
and it MUST be an algorithm that has a defined SIG rdata format.
署名で指定されたアルゴリズムはクライアントに認識できなければなりませ
ん(MUST)、署名レコードにはアルゴリズム毎に定義された署名資源データが
あるに違いありません(MUST)。
2.3 - Labels
2.3 - ラベル
The labels count MUST be less than or equal to the number of labels
in the SIG owner name, as specified in [RFC2535, section 4.1.3].
ラベル数は、[RFC2535, section 4.1.3]に示すように、署名所有者名のラベ
ル数以下に違いありません(MUST)。
2.4 - Original TTL
2.4 - 元のＴＴＬ
The original TTL MUST be greater than or equal to the TTL of the SIG
record itself, since the TTL cannot be increased by intermediate
servers. This field can be ignored for SIG(0) records.
元のＴＴＬは中継サーバで増やされることがないので、署名レコード自身の
ＴＴＬ以上に違いありません(MUST)。このフィールドはSIG(0)レコードでは
無視できます。
2.5 - Signature Expiration and Inception
2.5 - 署名期限と署名発行時刻
The current time at the time of validation MUST lie within the
validity period bounded by the inception and expiration times.
検証を行ってる時刻が署名の署名発行時刻と署名期限で示された期間内にな
ければなりません(MUST)。
2.6 - Key Tag
2.6 - 鍵タグ
There are no restrictions on the Key Tag field, although it is
possible that future algorithms will impose constraints.
未来のアルゴリズムで制約が出るかもしれませんが、鍵タグフィールドに現
在は制限がありません。
2.7 - Signer's Name
2.7 - 署名者名
The signer's name field of a data SIG MUST contain the name of the
zone to which the data and signature belong. The combination of
signer's name, key tag, and algorithm MUST identify a zone key if the
SIG is to be considered material. The only exception that the
signer's name field in a SIG KEY at a zone apex SHOULD contain the
parent zone's name, unless the KEY set is self-signed. This document
defines a standard policy for DNSSEC validation; local policy may
override the standard policy.
データ署名の署名者名はのデータと署名が属するゾーンの名前を含んでなく
てはなりません(MUST)。もし署名が重要と思われるなら、署名者名と鍵タグ
とアルゴリズムの組合せはゾーン鍵を指定してなくてはなりません(MUST)。
ゾーンの頂上の署名鍵の署名者名フィールドの唯一の例外は、鍵を自分で署
名しなければ、親ゾーンの名前を含むべきという事です。この文書はＤＮＳ
ＳＥＣ検証の標準ポリシーを定義します；ローカルポリシーがが標準ポリシー
より優先するかもしれません。
There are no restrictions on the signer field of a SIG(0) record.
The combination of signer's name, key tag, and algorithm MUST
identify a key if this SIG(0) is to be processed.
SIG(0)レコードの署名者フィールドに制限がありません。もしこのSIG(0)を
処理するなら、署名者名と鍵タグとアルゴリズムの組合せが鍵を識別しなく
てはなりません(MUST)。
2.8 - Signature
2.8 - 署名
There are no restrictions on the signature field. The signature will
be verified at some point, but does not need to be examined prior to
verification unless a future algorithm imposes constraints.
署名フィールドに制限がありません。署名はある時点で検証されるでしょう、
しかし未来のアルゴリズムに制約を押し付けないため、検証の前に調べる必
要がありません。
3 - The Signing KEY Record
3 - 署名鍵レコード
Once a signature has been examined and its fields validated (but
before the signature has been verified), the resolver attempts to
locate a KEY that matches the signer name, key tag, and algorithm
fields in the SIG. If one is not found, the SIG cannot be verified
and is considered immaterial. If KEYs are found, several fields of
the KEY record MUST have specific values if the SIG is to be
considered material and authorized. If there are multiple KEYs, the
following checks are performed on all of them, as there is no way to
determine which one generated the signature until the verification is
performed.
署名が調べられそのフィールドが検証されると（署名を検証する前に）リゾ
ルバは署名の名前と鍵タグとアルゴリズムフィールドに一致する鍵を探しま
す。もしなにも見るからないなら署名の検証は不可能で、重要でない証明と
思います。もし鍵が見つかったら、署名が重要と考えられ認証されるために
は、鍵レコードのいくつかのフィールドが特定の値でなければなりません
(MUST)。もし多数の鍵があるなら署名を生成した鍵を特定する方法がないの
で、いずれかの鍵の証明が実行されるまで以下の点検が各鍵に対して行われ
ます。
3.1 - Type Flags
3.1 - タイプフラグ
The signing KEY record MUST have a flags value of 00 or 01
(authentication allowed, confidentiality optional) [RFC2535, 3.1.2].
A DNSSEC resolver MUST only trust signatures generated by keys that
are permitted to authenticate data.
署名鍵レコードはフラグ値００か０１（認証可能、機密性任意）でなければ
なりません[RFC2535, 3.1.2](MUST)。ＤＮＳＳＥＣリゾルバはデータ認証を
認められた鍵によって生成された署名だけを信頼しなければなりません(MUST)。
3.2 - Name Flags
3.2 - 名前フラグ
The interpretation of this field is considerably different for data
SIGs and SIG(0) records.
このフィールドの解釈はデータ署名のための鍵とSIG(0)レコードのための鍵
でかなり異なっています。
3.2.1 - Data SIG
3.2.1 - データ署名
If the SIG record covers an RRset, the name type of the associated
KEY MUST be 01 (zone) [RFC2535, 3.1.2]. This updates RFC 2535,
section 2.3.6. The DNSSEC validation process performed by a resolver
MUST ignore all keys that are not zone keys unless local policy
dictates otherwise.
もし署名レコードが資源レコード集合をカバーするなら、関連した鍵の名前
タイプは０１（ゾーン）[RFC2535, 3.1.2]に違いありません(MUST)。これは
RFC 2535の２.３.６章の記述を変更します。リゾルバの行うＤＮＳＳＥＣ検
証プロセスは、ローカルポリシーが他の命令をしない限り、ゾーン鍵でない
鍵をすべて無視しなくければなりません(MUST)。
The primary reason that RFC 2535 allows host and user keys to
generate material DNSSEC signatures is to allow dynamic update
without online zone keys; that is, avoid storing private keys in an
online server. The desire to avoid online signing keys cannot be
achieved, though, because they are necessary to sign NXT and SOA sets
[RFC3007]. These online zone keys can sign any incoming data.
Removing the goal of having no online keys removes the reason to
allow host and user keys to generate material signatures.
RFC 2535が重要なＤＮＳＳＥＣ署名を生成するのにホスト鍵とユーザ鍵を許
すという主要な理由はオンラインゾーン鍵のないダイナミック更新を許すた
めです；つまり秘密鍵をオンラインのサーバーに保管するのを避けるためで
す。オンライン署名鍵を避ける希望は成し遂げられることができません、な
ぜならダイナミック更新はNXTとSOAの署名に必要だからです[RFC3007]。これ
らのオンラインゾーン鍵はどんな入力データにも署名できます。オンライン
鍵を持たない目標を除くことで、ホストとユーザ鍵で重要な署名を生成を許
す理由がなくなります。
Limiting material signatures to zone keys simplifies the validation
process. The length of the verification chain is bounded by the
name's label depth. The authority of a key is clearly defined; a
resolver does not need to make a potentially complicated decision to
determine whether a key has the proper authority to sign data.
重要な署名をゾーン鍵に制限することは検証処理を単純化します。証明鎖の
長さは名前のラベル深さが限界になります。鍵の権限は明らかに定義されま
す；リゾルバは鍵がデータに署名するために適切な権限を持っているか決定
するために潜在的に複雑な決断をする必要がありません。
Finally, there is no additional flexibility granted by allowing
host/user key generated material signatures. As long as users and
hosts have the ability to authenticate update requests to the primary
zone server, signatures by zone keys are sufficient to protect the
integrity of the data to the world at large.
最終的に、ホスト／ユーザ鍵で重要な署名の生成を許すことによる利点があ
りません。ユーザーとホストが認証更新要求をプライマリゾーンサーバーに
要求する限り、ゾーン鍵による署名は世界で一般的にデータ完全性を保護す
ることに十分です。
3.2.2 - SIG(0)
3.2.2 - SIG(0)
If the SIG record is a SIG(0) protecting a message, the name type of
the associated KEY SHOULD be 00 (user) or 10 (host/entity).
Transactions are initiated by a host or user, not a zone, so zone
keys SHOULD not generate SIG(0) records.
もし署名レコードがメッセージを守るSIG(0)なら、関連する鍵名タイプは
００（ユーザー）か１０（ホスト／エンティティー）であるべきです(SHOULD)。
処理がホストかユーザにより始められ、ゾーンによるのでないため、ゾーン
鍵がSIG(0)レコードを生成すべきではありません(SHOULD not)。
A client is either explicitly executed by a user or on behalf of a
host, therefore the name type of a SIG(0) generated by a client
SHOULD be either user or host. A nameserver is associated with a
host, and its use of SIG(0) is not associated with a particular zone,
so the name type of a SIG(0) generated by a nameserver SHOULD be
host.
クライアントは明示的にユーザーによって実行されるか、ホストのために実
行されるので、クライアントによって生成されたSIG(0)名タイプはユーザー
かホストであるべきです(SHOULD)。ネームサーバがホストと結び付き、そこ
で使うSIG(0)は特定のゾーンと結び付きません、そのためネームサーバで生
成されたSIG(0)の名前タイプはホストであるべきです(SHOULD)。
3.3 - Signatory Flags
3.3 - 署名者フラグ
This document does not assign any values to the signatory field, nor
require any values to be present.
この文書は署名者フィールドに割当てる値や、値の存在を要求しません。
3.4 - Protocol
3.4 - プロトコル
The signing KEY record MUST have a protocol value of 3 (DNSSEC) or
255 (ALL). If a key is not specified for use with DNSSEC, a DNSSEC
resolver MUST NOT trust any signature that it generates.
署名鍵レコードのプロトコル値は３（ＤＮＳＳＥＣ）か２５５（すべて）で
なければなりません(MUST)。もしＤＮＳＳＥＣで使う鍵が指定されないなら、
ＤＮＳＳＥＣリゾルバが生成された署名を信頼してはなりません(MUST NOT)。
3.5 - Algorithm Number
3.5 - アルゴリズム番号
The algorithm field MUST be identical to that of the generated SIG
record, and MUST meet all requirements for an algorithm value in a
SIG record.
アルゴリズムフィールドは生成された署名レコードとまったく同じに違いな
く(MUST)、署名レコードのすべてのアルゴリズム値の必要条件を満たさなく
てはなりません(MUST)。
4 - Security Considerations
4 - セキュリティの考察
This document defines a standard baseline for a DNSSEC capable
resolver. This is necessary for a thorough security analysis of
DNSSEC, if one is to be done.
この文書はＤＮＳＳＥＣ能力のあるリゾルバの標準基準を定義します。もし
これをするなら、ＤＮＳＳＥＣの徹底的なセキュリティ分析が必要です。
Specifically, this document places additional restrictions on SIG
records that a resolver must validate before the signature can be
considered worthy of DNSSEC trust. This simplifies the protocol,
making it more robust and able to withstand scrutiny by the security
community.
特に、この文書はリゾルバが、署名がＤＮＳＳＥＣ信頼に値するか検証する
前に、確認しなければならない署名レコードの追加の制限をします。これは
プロトコルを単純化し、いっそう強固にし、セキュリティ共同体の精査に耐
えることを可能にします。
5 - Acknowledgements
5 - 謝辞
The author would like to thank the following people for review and
informative comments (in alphabetical order):
著者はレビューと教育的なコメントに対して次の人々（アルファベット順）
に感謝します：
Olafur Gudmundsson
Ed Lewis
6 - References
6 - 参考文献
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2136] Vixie (Ed.), P., Thomson, S., Rekhter, Y. and J. Bound,
"Dynamic Updates in the Domain Name System", RFC 2136,
April 1997.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
(SIG(0)s )", RFC 2931, September 2000.
[RFC3007] Wellington, B., "Simple Secure Domain Name System
(DNS) Dynamic Update", RFC 3007, November 2000.
7 - Author's Address
7 - 著者のアドレス
Brian Wellington
Nominum, Inc.
950 Charter Street
Redwood City, CA 94063
Phone: +1 650 381 6022
EMail: Brian.Wellington@nominum.com
8 Full Copyright Statement
8. 著作権表示全文
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（Ｃ）インターネット学会（２０００）。すべての権利は保留される。
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
上記著作権表示とこの段落が全ての複写や派生的な仕事につけられていれば、
この文書と翻訳は複写や他者への提供ができ、そしてコメントや説明や実装
を支援する派生的な仕事のためにこの文書の全部か一部を制約なく複写や出
版や配布できます。しかし、この文書自身は、英語以外の言葉への翻訳やイ
ンターネット標準を開発する目的で必要な場合以外は、インターネット学会
や他のインターネット組織は著作権表示や参照を削除されるような変更がで
きません、インターネット標準を開発する場合はインターネット標準化プロ
セスで定義された著作権の手順に従われます。
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
上に与えられた限定された許可は永久で、インターネット学会やその後継者
や譲渡者によって無効にされません。
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
この文書とここに含む情報は無保証で供給され、そしてインターネット学会
とインターネット技術標準化タスクフォースは、特別にも暗黙にも、この情
報の利用が権利を侵害しないことや商業利用や特別の目的への利用に適当で
ある事の保障を含め、すべての保証を拒否します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the
Internet Society.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。