[要約] RFC 6841は、DNSSECポリシーとDNSSECプラクティスステートメントのためのフレームワークを提供するものであり、DNSセキュリティ担当者が適切なポリシーと手順を策定するためのガイドラインを提供します。目的は、DNSSECの実装と運用における一貫性と信頼性を向上させることです。
Internet Engineering Task Force (IETF) F. Ljunggren
Request for Comments: 6841 Kirei AB
Category: Informational AM. Eklund Lowinder
ISSN: 2070-1721 .SE
T. Okubo
ICANN
January 2013
A Framework for DNSSEC Policies and DNSSEC Practice Statements
DNSSECポリシーとDNSSEC実施規定のフレームワーク
Abstract
概要
This document presents a framework to assist writers of DNS Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements, such as domain managers and zone operators on both the top level and secondary level, who are managing and operating a DNS zone with Security Extensions implemented.
このドキュメントは、DNS Security Extensions（DNSSEC）ポリシーおよびDNSSEC実務声明（トップレベルとセカンダリレベルの両方のドメインマネージャーやゾーンオペレーターなど、セキュリティ拡張機能が実装されたDNSゾーンを管理および運用している）の作成者を支援するフレームワークを示します。
In particular, the framework provides a comprehensive list of topics that should be considered for inclusion into a DNSSEC Policy definition and Practice Statement.
特に、フレームワークは、DNSSECポリシーの定義と実践ステートメントに含めるために検討する必要があるトピックの包括的なリストを提供します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6841.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6841で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. DNSSEC Policy . . . . . . . . . . . . . . . . . . . . . . 6
3.2. DNSSEC Practice Statement . . . . . . . . . . . . . . . . 7
3.3. Relationship between DNSSEC Policy and Practice
Statement . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Set of Provisions . . . . . . . . . . . . . . . . . . . . 9
4. Contents of a Set of Provisions . . . . . . . . . . . . . . . 10
4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Publication and Repositories . . . . . . . . . . . . . . . 11
4.3. Operational Requirements . . . . . . . . . . . . . . . . . 12
4.4. Facility, Management, and Operational Controls . . . . . . 13
4.5. Technical Security Controls . . . . . . . . . . . . . . . 17
4.6. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . 20
4.7. Compliance Audit . . . . . . . . . . . . . . . . . . . . . 22
4.8. Legal Matters . . . . . . . . . . . . . . . . . . . . . . 23
5. Outline of a Set of Provisions . . . . . . . . . . . . . . . . 23
6. Security Considerations . . . . . . . . . . . . . . . . . . . 26
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
8.1. Normative References . . . . . . . . . . . . . . . . . . . 26
8.2. Informative References . . . . . . . . . . . . . . . . . . 26
The Domain Name System (DNS) was not originally designed with strong security mechanisms to provide integrity and authenticity of its data. Over the years, a number of vulnerabilities have been discovered that threaten the reliability and trustworthiness of the system.
ドメインネームシステム（DNS）は、データの整合性と信頼性を提供する強力なセキュリティメカニズムをもとに設計されていません。長年にわたって、システムの信頼性と信頼性を脅かすいくつかの脆弱性が発見されました。
The Domain Name System Security Extensions (DNSSEC, [RFC4033], [RFC4034], [RFC4035]) address these vulnerabilities by using public key cryptography to add data origin authentication, data integrity verification, and authenticated denial-of-existence capabilities to the DNS. In short, DNSSEC provides a way for software to verify the origin of DNS data and validate that it has not been modified in transit or by intermediaries.
ドメインネームシステムのセキュリティ拡張機能（DNSSEC、[RFC4033]、[RFC4034]、[RFC4035]）は、公開鍵暗号を使用してこれらの脆弱性に対処し、DNSにデータ発信元認証、データ整合性検証、および認証された存在拒否機能を追加します。要するに、DNSSECはソフトウェアがDNSデータの出所を確認し、それが転送中または仲介者によって変更されていないことを検証する方法を提供します。
To provide a means for stakeholders to evaluate the strength and security of the DNSSEC chain of trust, an entity operating a DNSSEC-enabled zone may publish a DNSSEC Practice Statement (DPS), comprising statements describing critical security controls and procedures relevant for scrutinizing the trustworthiness of the system. The DPS may also identify any of the DNSSEC Policies (DPs) it supports, explaining how it meets their requirements.
関係者がDNSSECチェーンの信頼性とセキュリティを評価するための手段を提供するために、DNSSEC対応ゾーンを運営するエンティティは、重要なセキュリティ管理と信頼性の精査に関連する手順を説明するステートメントを含むDNSSEC実践ステートメント（DPS）を公開することができます。システムの。 DPSは、サポートするDNSSECポリシー（DP）のいずれかを識別して、要件を満たす方法を説明することもあります。
The DP and DPS are not primarily aimed at users who rely on signed responses from the DNS ("relying parties"); instead, their audience is other stakeholders of the DNS infrastructure, a group that may include bodies such as regulatory authorities.
DPおよびDPSは、主にDNSからの署名付き応答に依存するユーザー（「証明書利用者」）を対象としたものではありません。その代わり、彼らの聴衆はDNSインフラストラクチャの他の利害関係者であり、規制当局などの団体を含むグループです。
Even though this document is heavily inspired by the "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework" [RFC3647], with large parts being drawn from that document, the properties and structure of the DNSSEC trust model are fundamentally different from those of the X.509 Public Key Infrastructure (PKI).
このドキュメントは「インターネットX.509公開キーインフラストラクチャの証明書ポリシーと認証実践フレームワーク」[RFC3647]に強く触発されていますが、そのドキュメントから大部分が抽出されていますが、DNSSEC信頼モデルのプロパティと構造は、根本的に異なりますX.509公開鍵インフラストラクチャ（PKI）のそれら。
The purpose of this document is twofold. Firstly, the document explains the concepts of a DNSSEC Policy (DP) and of a DNSSEC Practice Statement (DPS), and it describes the relationship between the two. Secondly, it presents a framework to encourage and assist writers of Policies and Practice Statements in creating consistent and comparable documents. In particular, the framework identifies the elements that should be considered in formulating a DP or a DPS.
このドキュメントの目的は2つあります。まず、このドキュメントではDNSSECポリシー（DP）とDNSSEC実務声明（DPS）の概念について説明し、両者の関係について説明します。第二に、それは一貫した比較可能なドキュメントを作成する際にポリシーと実践ステートメントの作成者を奨励し、支援するためのフレームワークを提示します。特に、フレームワークは、DPまたはDPSを作成する際に考慮すべき要素を識別します。
It does not, however, define a particular Policy or Practice Statement, nor does it seek to provide legal advice or recommendations as to the contents.
ただし、特定のポリシーや実践ステートメントを定義するものではなく、コンテンツに関する法的助言や推奨事項を提供しようとするものでもありません。
The scope of this document is limited to discussion of the topics that can be covered in a DP or a DPS, but it does not go into the specific details that could possibly be included in either a DP or a DPS. In particular, this document describes the types of information that should be considered for inclusion in them.
このドキュメントの範囲は、DPまたはDPSでカバーできるトピックの説明に限定されていますが、DPまたはDPSのいずれかに含まれる可能性がある特定の詳細には触れません。特に、このドキュメントでは、それらに含めることを検討する必要がある情報の種類について説明します。
This framework should be viewed and used as a checklist of factors that ought be taken into consideration prior to deploying DNSSEC, and as an outline to create an operational practices disclosure document. As such, it focuses on the topics affected by the introduction of DNSSEC into a zone. Other aspects, such as the operations of name servers and registry systems, are considered out of scope. The framework is primarily aimed at Top-Level Domain (TLD) managers and organizations providing registry services, but it may be used by high-value domain holders and so serve as a checklist for DNSSEC readiness at a high level.
このフレームワークは、DNSSECを展開する前に考慮すべき要素のチェックリストとして、および運用慣行の開示文書を作成するための概要として、表示および使用する必要があります。そのため、ゾーンへのDNSSECの導入によって影響を受けるトピックに焦点を当てています。ネームサーバーやレジストリシステムの操作など、その他の側面は範囲外と見なされます。このフレームワークは、主にレジストリサービスを提供するトップレベルドメイン（TLD）マネージャーおよび組織を対象としていますが、価値の高いドメインホルダーが使用する可能性があるため、DNSSECを高レベルで準備するためのチェックリストとして機能します。
This document assumes that the reader is familiar with the general concepts of DNS, DNSSEC, and PKI.
このドキュメントは、読者がDNS、DNSSEC、およびPKIの一般的な概念に精通していることを前提としています。
This document makes use of the following defined terms:
このドキュメントでは、次の定義された用語を使用します。
Audit logs: Control evidence information to prove the integrity of processes. This may be generated by DNS and DNSSEC-related systems, supplied by the surrounding facility, or obtained from manually generated, non-electronic documentation. Audit logs will be examined by the internal and/or external auditors.
監査ログ：プロセスの整合性を証明するための証拠情報を制御します。これは、DNSおよびDNSSEC関連システムによって生成されるか、周辺施設によって提供されるか、手動で生成された非電子ドキュメントから取得されます。監査ログは内部および/または外部の監査人によって検査されます。
Activation data: Data values, other than keys, required to operate the cryptographic modules used to protect the keys from unauthorized use.
アクティベーションデータ：キーを不正使用から保護するために使用される暗号化モジュールを操作するために必要な、キー以外のデータ値。
Chain of trust: A hierarchical structure of trust consisting of DNS keys, signatures, and delegation signer records that, when validated in a series, can provide proof of authenticity of the last element in the chain, providing that the first element is trusted. Usually, the first element is a trust anchor.
信頼の連鎖：DNSキー、署名、および委任署名者レコードで構成される信頼の階層構造。一連の検証で、最初の要素が信頼されている場合、連鎖の最後の要素の信頼性を証明できます。通常、最初の要素はトラストアンカーです。
Compromise (key compromise): Key compromise is a situation where the private component of a signing key is lost, stolen, exposed, modified, or used in an unauthorized manner. More strictly, even a suspicion that one of these has occurred will be enough to be considered as key compromise.
侵害（鍵の侵害）：鍵の侵害とは、署名鍵の秘密コンポーネントが紛失、盗難、露出、変更、または不正な方法で使用される状況です。より厳密には、これらの1つが発生したという疑いでさえ、鍵の侵害と見なされるのに十分です。
DNS: The Domain Name System (DNS) is a hierarchical global naming catalog for computers, services, or any resource connected to the Internet.
DNS：ドメインネームシステム（DNS）は、インターネットに接続されたコンピューター、サービス、またはリソースの階層的なグローバルネーミングカタログです。
DNS zone: A portion of the global Domain Name System (DNS) namespace for which administrative responsibility has been delegated.
DNSゾーン：管理責任が委任されているグローバルドメインネームシステム（DNS）名前空間の一部。
DNSSEC: DNS Security Extensions (DNSSEC) is a set of IETF specifications [RFC4033] [RFC4034] [RFC4035] that uses public key cryptography to add data origin authentication, data integrity verification, and authenticated denial of existence capabilities to DNS.
DNSSEC：DNS Security Extensions（DNSSEC）は、IETF仕様[RFC4033] [RFC4034] [RFC4035]のセットで、公開鍵暗号を使用して、データ発信元認証、データ整合性検証、および認証済みの存在拒否機能をDNSに追加します。
DNSSEC Policy: A DNSSEC Policy (DP) sets forth the security requirements and standards to be implemented for a DNSSEC-signed zone.
DNSSECポリシー：DNSSECポリシー（DP）は、DNSSEC署名ゾーンに実装されるセキュリティ要件と標準を規定します。
DNSSEC Practice Statement: A DNSSEC Practice Statement (DPS) is a practices disclosure document that may support and be a supplemental document to the DNSSEC Policy (if such exists), and it states how the management of a given zone implements procedures and controls at a high level.
DNSSEC実務声明：DNSSEC実務声明（DPS）は、DNSSECポリシー（存在する場合）をサポートおよび補足する可能性のある実務開示文書であり、所定のゾーンの管理が手順と制御をどのように実装するかを記載しています。高いレベル。
Key rollover: An operational process to change one of the DNSSEC keys used for signing a zone via distribution of public keys in a trusted manner.
キーロールオーバー：信頼できる方法で公開キーを配布することにより、ゾーンの署名に使用されるDNSSECキーの1つを変更する運用プロセス。
Multi-person control: A security concept to distribute the authority of an operation over multiple persons, to mitigate threats caused by a single authorized individual. For example, a key recovery function may require some number of authorized individuals (m) out of the (n) to whom a portion of the recovery key was distributed, to combine their key fragments, before key recovery can occur.
複数人による制御：1人の許可された個人によって引き起こされる脅威を軽減するために、操作の権限を複数の人に分散するセキュリティの概念。たとえば、キー回復機能を使用するには、回復キーの一部が配布された（n）人のうち、キーフラグメントを結合して、キー回復を行う前に、許可された個人（m）が必要になる場合があります。
PKI: Public Key Infrastructure (PKI) is a concept that makes use of asymmetric cryptography to provide a system with integrity, authentication, and confidentiality and to do it via distribution of public keys in a trusted manner.
PKI：公開キー基盤（PKI）は、非対称暗号化を利用してシステムに整合性、認証、および機密性を提供し、信頼できる方法で公開キーを配布することでそれを行う概念です。
Policy authority: The body responsible for setting and administering a DNSSEC Policy and for determining whether a DPS is suitable for that Policy.
ポリシー機関：DNSSECポリシーの設定と管理を担当し、DPSがそのポリシーに適しているかどうかを判断する機関。
Relying party: An entity that relies on a signed response from the DNS.
証明書利用者：DNSからの署名された応答に依存するエンティティ。
Repository: A location on the Internet to store DP, DPS, trust anchors, and other related information that should be kept public.
リポジトリ：公開しておく必要があるDP、DPS、トラストアンカー、およびその他の関連情報を格納するインターネット上の場所。
Security posture: A security posture is an indicator of how secure an entity is and how secure the entity should be. It is the result of an adequate threat model and risk assessment.
セキュリティ態勢：セキュリティ態勢は、エンティティの安全性とエンティティの安全性の指標です。これは、適切な脅威モデルとリスク評価の結果です。
Separation of duties: A security concept that limits the influence of a single person by segregating roles and responsibilities.
職務の分離：役割と責任を分離することにより、1人の人物の影響を制限するセキュリティの概念。
Signing key: Private component of an asymmetric key pair that is used for signing of resource records within the zone. Note that the other component, called public key, is used for signature validation.
署名キー：ゾーン内のリソースレコードの署名に使用される非対称キーペアのプライベートコンポーネント。公開鍵と呼ばれる他のコンポーネントは、署名の検証に使用されることに注意してください。
TLD: A Top-Level Domain (TLD) is one of the domains at the highest level below the root in the hierarchy of the DNS.
TLD：トップレベルドメイン（TLD）は、DNSの階層でルートの下の最上位レベルにあるドメインの1つです。
Trust anchor: Public portion of a key pair that is the authoritative entity used to authenticate the first element in a chain of trust.
トラストアンカー：信頼の連鎖の最初の要素を認証するために使用される権限のあるエンティティであるキーペアの公開部分。
This section describes the concepts of a DNSSEC Policy and of a DNSSEC Practice Statement. Other related concepts are described as well.
このセクションでは、DNSSECポリシーとDNSSEC実践規定の概念について説明します。その他の関連する概念についても説明します。
A DNSSEC Policy (DP) sets forth requirements that are appropriate for a specified level of assurance. For example, a DP may encompass all topics of this framework, each with a certain set of security requirements, possibly grouped according to impact. The progression from medium to high levels of assurance would correspond to increasing security requirements and corresponding increasing levels of assurance.
DNSSECポリシー（DP）は、指定された保証レベルに適した要件を規定しています。たとえば、DPはこのフレームワークのすべてのトピックを包含し、それぞれが特定のセキュリティ要件のセットを持ち、影響によってグループ化される可能性があります。中レベルから高レベルの保証への移行は、セキュリティ要件の増加と対応する保証レベルの増加に対応します。
A DP also constitutes a basis for an audit, accreditation, or another assessment of an entity. Each entity can be assessed against one or more DPs that it claims to implement.
DPは、エンティティの監査、認定、または別の評価の基礎も構成します。各エンティティは、実装を要求する1つ以上のDPに対して評価できます。
Most zone managers using DNSSEC will not have the need to create a thorough and detailed statement of practices. For example, a registrant may be the sole relying party of its own zone and would already be aware of the nature and trustworthiness of its services. In other cases, a zone manager may provide registration services with only a very low level of assurances where the domain names being secured may pose only marginal risks if compromised. Publishing a DPS is most relevant for entities operating a zone that contains a significant number of delegations to other entities.
DNSSECを使用するほとんどのゾーン管理者は、徹底的で詳細な実践の声明を作成する必要はありません。たとえば、登録者が自分のゾーンの唯一の依存パーティであり、そのサービスの性質と信頼性をすでに認識している場合があります。他の場合では、ゾーンマネージャーは、非常に低レベルの保証のみで登録サービスを提供し、セキュリティ保護されているドメイン名が危険にさらされた場合にわずかなリスクしかもたらさない場合があります。 DPSの公開は、他のエンティティへのかなりの数の委任を含むゾーンを運営しているエンティティに最も関連しています。
A DNSSEC Practice Statement (DPS) should contain information that is relevant to the stakeholders of the relevant zone(s). Since these generally include the Internet community, it should not contain such information that could be considered to be sensitive details of an entity's operations.
DNSSECプラクティスステートメント（DPS）には、関連するゾーンの利害関係者に関連する情報を含める必要があります。これらには一般にインターネットコミュニティが含まれるため、エンティティの操作の機密情報と見なされる可能性のある情報は含めないでください。
A DNSSEC Practice Statement may identify a supported DP, which may subsequently be used by a relying party to evaluate the trustworthiness of any digital signatures verified using the public key of that entity.
DNSSEC実務声明では、サポートされているDPを識別できます。これは、依存エンティティが後でそのエンティティの公開キーを使用して検証したデジタル署名の信頼性を評価するために使用できます。
A DNSSEC Policy and a DNSSEC Practice Statement address the same set of topics of interest to the stakeholders in terms of the level of confidence ascribed to the security posture of a zone. The primary difference is in the focus of their provisions. A Policy sets forth the requirements and standards to be implemented for a DNSSEC-signed zone, and may be used to communicate requirements that must be met by complying parties; as such, it may also be used to determine or establish equivalency between policies associated with different zones. A Practice Statement, by contrast, describes how a zone operator (and possibly other participants in the management of a given zone) implements procedures and controls to meet the requirements of applicable Policies. In other words, the Policy says what needs to be done, and the Practice Statement says what is being done.
DNSSECポリシーとDNSSEC実践声明は、ゾーンのセキュリティ体制に起因する信頼性のレベルに関して、利害関係者が関心を持つ同じ一連のトピックに対処しています。主な違いは、規定の焦点にあります。ポリシーは、DNSSEC署名ゾーンに実装される要件と標準を示し、準拠する当事者が満たす必要のある要件を伝えるために使用できます。そのため、異なるゾーンに関連付けられたポリシー間の同等性を判断または確立するためにも使用できます。対照的に、実践ステートメントは、ゾーンオペレーター（および場合によっては特定のゾーンの管理の他の参加者）が、適用可能なポリシーの要件を満たすための手順と制御を実装する方法を説明します。言い換えると、ポリシーには何をする必要があるかが示され、実践ステートメントには何が行われているかが示されます。
An additional difference between a Policy and a Practice Statement relates to the scope of coverage of the two kinds of documents, in terms of its applicability. A Policy may apply to multiple organizations or multiple zones. By contrast, a Practice Statement would usually apply only to a single zone operator or a single organization, since it describes the actual controls in place that meet the requirements of applicable Policy.
ポリシーと実務ステートメントの間の追加の違いは、2種類のドキュメントの適用範囲に関して、その適用可能性に関連しています。ポリシーは、複数の組織または複数のゾーンに適用される場合があります。対照的に、実践声明は、該当するポリシーの要件を満たす実際の統制を説明しているため、通常、単一のゾーンオペレーターまたは単一の組織にのみ適用されます。
For example, a TLD manager or regulatory authority may define requirements in a Policy for the operation of one or more zones. The Policy will be a broad statement of the general requirements for managing the zone. A zone operator may be required to write its own Practice Statement to support the Policy, explaining how it meets the requirements of the Policy. Alternatively, a zone operator that is also the manager of that zone, and not governed by any external Policy, may still choose to disclose operational practices by publishing a DPS. The zone operator might do so to provide transparency and to gain community trust in its operations.
たとえば、TLDマネージャーまたは規制当局は、1つ以上のゾーンの運用に関するポリシーで要件を定義できます。このポリシーは、ゾーンを管理するための一般的な要件の幅広い説明になります。ゾーンオペレーターは、ポリシーをサポートするために独自のプラクティスステートメントを記述し、ポリシーの要件をどのように満たすかを説明する必要がある場合があります。または、そのゾーンの管理者でもあり、外部ポリシーによって管理されていないゾーンオペレーターは、DPSを公開することで運用慣行を開示することを選択できます。ゾーンの運営者は、透明性を提供し、その事業に対するコミュニティの信頼を得るためにそうするかもしれません。
A Policy and a Practice Statement also differ in the level of detail each expresses: although there may be variations, a Practice Statement will provide a description of procedures and controls and so will usually be more detailed than a Policy, which provides general principles.
ポリシーと実践ステートメントは、それぞれが表す詳細レベルも異なります。バリエーションが存在する場合がありますが、実践ステートメントは手順と制御の説明を提供するため、一般原則を提供するポリシーよりも詳細です。
The main differences between a Policy and Practice Statement can be summarized as follows:
ポリシーと実践ステートメントの主な違いは、次のように要約できます。
(a) Operation of a DNS zone with DNSSEC may be governed by a Policy that establishes requirements stating what the entity operating that zone must do. An entity can use a Practice Statement to disclose how it meets the requirements of a Policy or how it has implemented critical processes and controls, absent a controlling Policy.
（a）DNSSECを使用したDNSゾーンの操作は、そのゾーンを操作するエンティティが何をしなければならないかを示す要件を確立するポリシーによって管理される場合があります。エンティティは、実務ステートメントを使用して、ポリシーの要件をどのように満たすか、または重要なプロセスと制御をどのように実装したかを開示することができます。
(b) A Policy may serve the purpose of establishing a common basis of trusted operation throughout a set of zones in the DNS hierarchy. By contrast, a Practice Statement is a statement of a single zone operator or organization.
（b）ポリシーは、DNS階層内の一連のゾーン全体で信頼できる操作の共通基盤を確立する目的に役立つ場合があります。対照的に、実践ステートメントは、単一のゾーンオペレーターまたは組織のステートメントです。
(c) A Practice Statement is generally more detailed than a Policy and specifies how the zone operator or organization implements critical processes and controls, and how the entity meets any requirements specified in the one or more Policies under which it operates DNSSEC.
（c）実践ステートメントは一般にポリシーよりも詳細であり、ゾーンオペレーターまたは組織が重要なプロセスと制御を実装する方法、およびエンティティがDNSSECを運用する1つ以上のポリシーで指定された要件を満たす方法を指定します。
A set of provisions is a collection of Policy requirements or Practice Statements, which may employ the approach described in this framework by covering the topics appearing in Section 5 below. The topics are described in detail in Section 4.
一連の規定は、ポリシー要件または実践ステートメントのコレクションであり、以下のセクション5に記載されているトピックをカバーすることにより、このフレームワークで説明されているアプローチを採用できます。トピックについては、セクション4で詳しく説明します。
A Policy can be expressed as a single set of provisions. A Practice Statement can also be expressed as a single set of provisions with each component addressing the requirements of one or more Policies. Alternatively, it could be a set of provisions that do not reference any particular policy but instead describe a set of self-imposed controls to the stakeholders. For example, a Practice Statement could be expressed as a combination of the following:
ポリシーは、単一の条項のセットとして表すことができます。実践ステートメントは、各コンポーネントが1つ以上のポリシーの要件に対処する単一の規定セットとして表現することもできます。あるいは、特定のポリシーを参照せず、代わりに、利害関係者に課された一連の制御を説明する一連の規定とすることもできます。たとえば、実践ステートメントは次の組み合わせで表すことができます。
(a) a list of Policies supported by the DPS;
（a）DPSがサポートするポリシーのリスト。
(b) for each Policy in (a), a set of provisions that contains statements addressing the requirements by filling in details not stipulated in that policy or expressly left to the discretion of the implementer. Such statements serve to show how this particular Practice Statement implements the requirements of the particular Policy; or
（b）（a）の各ポリシーについて、そのポリシーで規定されていないか、実装者の裁量に明示的に委ねられていない詳細を記入することにより要件に対処するステートメントを含む一連の規定。そのようなステートメントは、この特定の実践ステートメントが特定のポリシーの要件をどのように実装するかを示すのに役立ちます。または
(c) a set of provisions that contains statements regarding the DNSSEC operations practices, independent of any Policy.
（c）ポリシーに関係なく、DNSSECの運用慣行に関する記述を含む一連の規定。
The statements provided in (b) may augment or refine the stipulations of an applicable Policy, but generally they must not conflict with the stipulations. In certain cases, however, a Policy authority may permit exceptions because certain compensating controls of the entity disclosed in its Practice Statement allow it to provide a level of assurance equivalent to full compliance with the policy.
（b）で提供されるステートメントは、該当するポリシーの規定を強化または改善する可能性がありますが、通常、それらは規定と矛盾してはなりません。ただし、場合によっては、ポリシー当局が例外を許可することがあります。これは、その実務声明で開示されたエンティティの特定の補完的統制により、ポリシーへの完全な準拠と同等のレベルの保証を提供できるためです。
The framework outlines the contents of a set of provisions, in terms of eight primary components, as follows:
フレームワークは、次のように、8つの主要コンポーネントの観点から、一連の条項の内容の概要を示しています。
1. Introduction
1. はじめに
2. Publication and Repositories
2. 公開とリポジトリ
3. Operational Requirements
3. 運用要件
4. Facility, Management, and Operational Controls
4. 施設、管理、および運用管理
5. Technical Security Controls
5. 技術的なセキュリティ管理
6. Zone Signing 7. Compliance Audit
6.ゾーン署名7.コンプライアンス監査
8. Legal Matters
8. 法的事項
This framework can be used by Policy authorities to write DNSSEC Policies and by zone operators to write a DNSSEC Practice Statements. Having a set of documents with the same structure facilitates comparisons with the corresponding documents of other zones.
このフレームワークは、ポリシー当局がDNSSECポリシーを記述したり、ゾーンオペレーターがDNSSEC実践ステートメントを記述したりするために使用できます。同じ構造の一連のドキュメントがあると、他のゾーンの対応するドキュメントとの比較が容易になります。
This section describes the contents of a set of provisions. Refer to Section 5 for the complete outline.
このセクションでは、一連の規定の内容について説明します。完全な概要については、セクション5を参照してください。
Drafters of DPSs conforming to this framework are permitted to add additional levels of subcomponents below those described here to meet specific needs. All components listed in Section 5 should be present, but drafters may leave components empty, only stating "no stipulation", if so required.
このフレームワークに準拠するDPSの垂木は、特定のニーズを満たすために、ここに記載されているレベルの下にサブコンポーネントのレベルを追加することができます。セクション5に記載されているすべてのコンポーネントが存在する必要がありますが、起草者はコンポーネントを空のままにして、必要に応じて「規定なし」とのみ記載することができます。
This component identifies and introduces the set of provisions, and indicates the types of entities and applications for which the document (either Policy or Practice Statement) is targeted.
このコンポーネントは、一連の規定を識別および導入し、ドキュメント（ポリシーまたはプラクティスステートメント）の対象となるエンティティおよびアプリケーションの種類を示します。
This subcomponent provides a general introduction to the document. It can also be used to provide a description of entities to which the Policy or Practice Statement applies.
このサブコンポーネントは、ドキュメントの一般的な紹介を提供します。また、ポリシーまたは実務声明が適用されるエンティティの説明を提供するために使用することもできます。
This subcomponent provides any applicable names or other identifiers of the document.
このサブコンポーネントは、ドキュメントの該当する名前またはその他の識別子を提供します。
This subcomponent identifies the stakeholders along with their expected roles and responsibilities. These include (but are not limited to) an entity signing the zone, entities relying on the signed zone, other entities that have operational dependency on the signed zone, and an entity that entrusted the zone signing.
このサブコンポーネントは、期待される役割と責任とともに、利害関係者を識別します。これらには、ゾーンに署名するエンティティ、署名されたゾーンに依存するエンティティ、署名されたゾーンに操作上の依存関係を持つ他のエンティティ、およびゾーンの署名を委託したエンティティが含まれます（これらに限定されません）。
This subcomponent contains the contact details of the organization responsible for managing the DP/DPS, as well as the specification change procedures. These procedures may include the description of the notification mechanisms used to provide advance notice of amendments that are deemed to materially affect the assurance provided by the entity and how/when such amendments will be communicated to the stakeholders.
このサブコンポーネントには、DP / DPSの管理を担当する組織の連絡先の詳細、および仕様変更手順が含まれています。これらの手順には、エンティティによって提供される保証に重大な影響を与えると思われる修正の事前通知を提供するために使用される通知メカニズムの説明、およびそのような修正が利害関係者に伝達される方法/時期が含まれる場合があります。
If a Policy authority is responsible for determining whether a DPS is suitable for the Policy, this subcomponent may include the name and contact information of the entity in charge of making such a determination. In this case, the subcomponent also includes the procedures by which this determination is made.
ポリシー当局がDPSがポリシーに適しているかどうかを判断する責任がある場合、このサブコンポーネントには、そのような判断を行う主体の名前と連絡先情報を含めることができます。この場合、サブコンポーネントには、この決定が行われる手順も含まれます。
The component describes the requirements for an entity to publish information regarding its practices, public keys, the current status of such keys together with details relating to the repositories in which the information is held. This may include the responsibilities of publishing the DPS and of identifying documents that are not made publicly available owing to their sensitive nature, e.g., security controls, clearance procedures, or business information.
このコンポーネントは、エンティティがその実務、公開鍵、そのような鍵の現在のステータスに関する情報を、情報が保持されているリポジトリに関する詳細とともに公開するための要件を記述します。これには、DPSの公開、および機密情報（セキュリティ管理、クリアランス手順、ビジネス情報など）のために公開されていないドキュメントを識別する責任が含まれる場合があります。
This subcomponent describes the repository mechanisms used for making information available to the stakeholders, and may include:
このサブコンポーネントは、関係者が情報を利用できるようにするために使用されるリポジトリメカニズムを説明します。
o The locations of the repositories and the means by which they may be accessed;
o リポジトリの場所とリポジトリへのアクセス方法。
o An identification of the entity or entities that operate repositories, such as a zone operator or a TLD manager;
o ゾーンオペレータやTLDマネージャなど、リポジトリを操作するエンティティの識別情報。
o Access control on published information objects; and
o 公開された情報オブジェクトのアクセス制御。そして
o Any notification services that may be subscribed to by the stakeholders.
o 利害関係者によってサブスクライブされる可能性のある通知サービス。
This subcomponent contains information relating to the publication of public keys:
このサブコンポーネントには、公開鍵の公開に関する情報が含まれています。
o Whether the public keys are included in a key hierarchy, published as trust anchors, or both;
o 公開鍵が鍵階層に含まれるか、トラストアンカーとして公開されるか、またはその両方か。
o The data formats and methods available to validate the authenticity of public keys;
o 公開鍵の信頼性を検証するために使用できるデータ形式と方法。
o The frequency and timing of publishing new information (principally, as advance notice for stakeholders relying on the public keys).
o 新しい情報を公開する頻度とタイミング（主に、公開鍵に依存する利害関係者への事前通知として）。
This component describes the operational requirements when operating a DNSSEC-signed zone.
このコンポーネントは、DNSSEC署名ゾーンを操作するときの操作要件を説明します。
This subcomponent describes the overall policy of child zone naming, if any.
このサブコンポーネントは、もしあれば、子ゾーンの命名の全体的なポリシーを記述します。
This subcomponent describes how the child zone manager has initially been identified, and how any subsequent change request is authenticated as originating from the manager or their authorized representative.
このサブコンポーネントは、子ゾーンマネージャーが最初に識別された方法、および後続の変更要求がマネージャーまたはその承認された代表者から発信されたものとして認証される方法を記述します。
This subcomponent describes the process of establishing the chain-of-trust to the child zone by incorporating delegation signer (DS) record(s) into the zone.
このサブコンポーネントは、委任署名者（DS）レコードをゾーンに組み込むことにより、子ゾーンへの信頼チェーンを確立するプロセスを記述します。
This subcomponent describes whether and, if so, under what circumstances the child zone manager is required to provide proof of the possession of the private component of any current or subsequent child zone signing key corresponding to a DS record they wish to incorporate into the parent zone.
このサブコンポーネントは、どのような状況で、子ゾーンマネージャーが、親ゾーンに組み込みたいDSレコードに対応する現在または後続の子ゾーン署名鍵のプライベートコンポーネントを所有していることの証明を提供する必要があるかどうか、またその場合に説明します。
This subcomponent will explain how, when, and under what circumstances the DS records may be removed from the zone.
このサブコンポーネントでは、DSレコードをゾーンから削除する方法、タイミング、および状況を説明します。
This component describes non-technical security controls (i.e., physical, procedural, and personnel) in use by the entity to securely perform the DNSSEC related functions. Such controls include physical access, key management, disaster recovery, auditing, and archiving.
このコンポーネントは、エンティティがDNSSEC関連の機能を安全に実行するために使用している非技術的なセキュリティ制御（つまり、物理的、手続き的、および人員）を記述します。そのような制御には、物理的アクセス、キー管理、災害復旧、監査、およびアーカイブが含まれます。
These non-technical security controls are critical for trusting the DNSSEC signatures, since lack of security may compromise DNSSEC operations. For example, it could result in the creation of signatures with erroneous information or in the compromise of the signing key.
セキュリティの欠如はDNSSECの運用を危険にさらす可能性があるため、これらの非技術的なセキュリティ管理はDNSSEC署名を信頼するために重要です。たとえば、誤った情報を含む署名が作成されたり、署名キーが危険にさらされたりする可能性があります。
Within each subcomponent, separate consideration will usually need to be given to each entity type.
各サブコンポーネント内では、通常、各エンティティタイプに対して個別に検討する必要があります。
In this subcomponent, the physical controls on the facility housing the entity systems are described. Topics addressed may include:
このサブコンポーネントでは、エンティティシステムを収容する施設の物理的な制御について説明します。扱われるトピックは次のとおりです。
o Site location and construction, such as requirements for multiple tiers of physical barriers, construction requirements for high-security areas, etc. It may also describe the use of locked rooms, cages, safes, cabinets, etc.;
o 物理的な障壁の複数の層の要件、高セキュリティエリアの建設要件など、サイトの場所と建設。施錠された部屋、ケージ、金庫、キャビネットなどの使用についても説明する場合があります。
o Physical access, i.e., mechanisms to control access from one area of the facility to another or additional controls for reaching into higher tiers, such as dual-access control and two-factor authentication;
o 物理的なアクセス、つまり、施設のある領域から別の領域へのアクセスを制御するメカニズム、またはデュアルアクセス制御や2要素認証などの上位層に到達するための追加の制御。
o Power and air conditioning;
o 電源とエアコン。
o Water exposures;
o 水への暴露;
o Fire prevention and protection;
o 防火と保護;
o Media storage, e.g., requiring the storage of backup media in a separate location that is physically secure and protected from fire, smoke, particle, and water damage;
o メディアの保管。たとえば、物理的に安全で、火災、煙、粒子、水による損傷から保護された別の場所にバックアップメディアを保管する必要がある。
o Waste disposal; and o Off-site backup.
o廃棄物処理;およびoオフサイトバックアップ。
In this subcomponent, requirements for recognizing trusted roles are described, together with a description of the responsibilities of each role. Examples of trusted roles include system administrators, security officers, crypto officers, and system auditors.
このサブコンポーネントでは、信頼された役割を認識するための要件が、各役割の責任の説明とともに説明されています。信頼できる役割の例には、システム管理者、セキュリティ担当者、暗号担当者、システム監査人が含まれます。
For each task identified, the number of individuals required to perform the task (m of n rule, if applicable) should be stated for each role. Identification and authentication requirements for each role may also be defined.
識別されたタスクごとに、タスクを実行するために必要な個人の数（該当する場合は、nルールのm）を役割ごとに記載する必要があります。各ロールの識別と認証の要件も定義できます。
This subcomponent also includes the separation of duties in terms of the roles that cannot be performed by the same individuals.
このサブコンポーネントには、同じ個人が実行できない役割に関する職務の分離も含まれます。
This subcomponent addresses the following:
このサブコンポーネントは、次のことを扱います。
o Qualifications, experience, and clearances that personnel must have as a condition of filling trusted roles or other important roles. Examples include credentials, job experiences, and official government clearances;
o 信頼された役割またはその他の重要な役割を満たすための条件として、担当者が持っている必要がある資格、経験、およびクリアランス。例としては、資格、職務経験、政府の認可などがあります。
o Background checks and clearance procedures that are required in connection with the hiring of personnel filling trusted roles or other important roles. Such roles may require a check of their criminal records, financial records, references, and any additional clearances required for the position in question;
o 信頼できる役割またはその他の重要な役割を担当する要員の採用に関連して必要なバックグラウンドチェックとクリアランス手順。そのような役割では、犯罪歴、財務記録、参照、および問題の職位に必要な追加の許可のチェックが必要になる場合があります。
o Training requirements and training procedures for each role following the hiring of personnel;
o 人材採用後の各ロールのトレーニング要件とトレーニング手順。
o Any retraining period and retraining procedures for each role after completion of initial training;
o 最初のトレーニングの完了後の各役割の再トレーニング期間と再トレーニング手順。
o Frequency and sequence for job rotation among various roles;
o さまざまな役割間のジョブローテーションの頻度と順序。
o Sanctions against personnel for unauthorized actions, such as unauthorized use of authority or unauthorized use of the entity systems;
o 権限の不正使用またはエンティティシステムの不正使用などの不正行為に対する職員に対する制裁。
o Controls on personnel that are contractors rather than employees of the entity; examples include:
o 企業の従業員ではなく請負業者である要員の管理。例は次のとおりです。
* Bonding requirements on contract personnel;
* 契約担当者の結合要件;
* Contractual requirements including indemnification for damages due to the actions of the contractor personnel;
* 請負業者の担当者の行為による損害の補償を含む契約上の要件。
* Auditing and monitoring of contractor personnel; and
* 請負業者の監査と監視;そして
* Other controls on contracting personnel.
* 契約社員に関するその他の管理。
o Documentation to be supplied to personnel during initial training, retraining, or otherwise.
o 初期トレーニング、再トレーニング、その他の際に担当者に提供されるドキュメント。
This subcomponent is used to describe event logging and audit systems, implemented for the purpose of maintaining an audit trail and to provide evidence of process integrity. Elements include the following:
このサブコンポーネントは、イベント追跡と監査システムを説明するために使用され、監査証跡を維持する目的で実装され、プロセスの整合性の証拠を提供します。要素には次のものがあります。
o Types of events recorded, such as records of key rollover and other key management operations, the personnel assigned to various roles, attempts to access the system, and requests made to the system;
o キーのロールオーバーやその他のキー管理操作の記録、さまざまな役割に割り当てられた担当者、システムへのアクセスの試行、システムに対して行われた要求など、記録されたイベントの種類。
o Frequency with which audit logs are processed or archived, e.g., weekly following an alarm or anomalous event or whenever the audit log size reaches a particular size;
o 監査ログが処理またはアーカイブされる頻度。たとえば、アラームまたは異常イベントの後の毎週、または監査ログのサイズが特定のサイズに達したとき。
o Period for which audit logs are kept;
o 監査ログが保持される期間。
o Protection of audit logs:
o 監査ログの保護：
* Who can view audit logs, for example, only the audit administrator;
* 誰が監査ログを表示できるか（例えば、監査管理者のみ）。
* Protection against modification of audit logs, for instance, a requirement that no one may modify or delete the audit records or that only an audit administrator may delete an audit file as part of audit file rotation; and
* 監査ログの変更に対する保護。たとえば、誰も監査レコードを変更または削除できない、または監査管理者だけが監査ファイルローテーションの一部として監査ファイルを削除できるという要件。そして
* Protection against deletion of audit logs.
* 監査ログの削除に対する保護。
o Audit log backup procedures;
o 監査ログのバックアップ手順。
o Whether the audit log collection function is internal or external to the system;
o 監査ログ収集機能がシステムの内部か外部か。
o Whether the subject who caused an audit event to occur is notified of the audit action; and
o 監査イベントを発生させた対象者に監査アクションが通知されるかどうか。そして
o Vulnerability assessments, for example, where audit data is run through a tool that identifies potential attempts to breach the security of the system.
o たとえば、システムのセキュリティを侵害する潜在的な試みを識別するツールを介して監査データが実行される脆弱性評価。
This subcomponent describes requirements relating to notification and recovery procedures in the event of compromise or disaster. Each of the following may need to be addressed separately:
このサブコンポーネントは、侵害または災害が発生した場合の通知および回復手順に関連する要件について説明します。以下のそれぞれに個別に対処する必要がある場合があります。
o Identification or listing of the applicable incident and compromise reporting and handling procedures, which may include the investigation of measures to prevent the event from reoccurring.
o 該当するインシデントの特定または一覧表示、および問題の再発を防止するための対策の調査を含む、報告および処理手順の妥協。
o The recovery procedures used if computing resources, software, and/or data are corrupted or suspected to have been corrupted. These procedures describe how, and under what circumstances, operations of the system are to be suspended; how and when normal operations are resumed; how the stakeholders are to be informed; and how to assess the damage and carry out the root cause analysis.
o コンピューティングリソース、ソフトウェア、データが破損しているか、破損している疑いがある場合に使用される回復手順。これらの手順は、システムの運用をどのように、どのような状況で停止するかを説明しています。通常の操作が再開される方法と時期利害関係者にどのように通知するか;損傷を評価し、根本原因分析を実行する方法。
o The recovery procedures used if any keys are compromised. These procedures describe how a secure environment is re-established, how the keys are rolled over, how a new trust anchor is provided to the community (if applicable), and how new zone information is published.
o キーが危険にさらされた場合に使用される回復手順。これらの手順では、安全な環境を再確立する方法、キーをロールオーバーする方法、新しいトラストアンカーをコミュニティに提供する方法（該当する場合）、および新しいゾーン情報を公開する方法について説明します。
o The entity's capabilities to ensure business continuity following a natural or other disaster. Such capabilities may include the availability of a disaster recovery site at which operations may be recovered. They may also include procedures for securing its facility during the period of time following a natural or other disaster and before a secure environment is re-established, either at the original site or at a disaster recovery site, for example, procedures to protect against theft of sensitive materials from an earthquake-damaged site.
o 自然災害またはその他の災害後の事業継続性を確保するための企業の能力。このような機能には、操作を回復できる災害復旧サイトの可用性が含まれる場合があります。また、自然災害やその他の災害が発生した後、元のサイトまたは災害復旧サイトで安全な環境が再確立されるまでの間に施設を保護するための手順（盗難から保護するための手順など）も含まれます。地震で被害を受けたサイトからの機密資料の収集。
This subcomponent describes requirements relating to procedures for termination of a contract with an entity, termination notification, and transition of responsibilities to another entity. The purpose may be to ensure that the transition process will be transparent to the stakeholders, and it will not affect the services.
このサブコンポーネントは、エンティティとの契約の終了、終了通知、および責任の別のエンティティへの移行の手順に関連する要件を記述します。目的は、移行プロセスが関係者に透過的であり、サービスに影響を及ぼさないようにすることです。
This component is used to define the security measures taken to protect the cryptographic keys and activation data (e.g., PINs, passwords, or manually held key shares) relevant to DNSSEC operations. Secure key management is critical to ensure that all secret and private keys and activation data are protected and used only by authorized personnel.
このコンポーネントは、DNSSEC操作に関連する暗号化キーとアクティベーションデータ（PIN、パスワード、手動で保持されたキー共有など）を保護するために講じられるセキュリティ対策を定義するために使用されます。安全な鍵管理は、すべての秘密鍵と秘密鍵、およびアクティベーションデータが保護され、許可された担当者のみが使用できるようにするために重要です。
Also described here are other technical security controls used to perform the functions of key generation, authentication, registration, auditing, and archiving. Technical controls include life cycle security controls, software development environment security, and operational security controls.
また、ここでは、キーの生成、認証、登録、監査、およびアーカイブの機能を実行するために使用されるその他の技術的なセキュリティコントロールについても説明します。技術的管理には、ライフサイクルセキュリティ管理、ソフトウェア開発環境セキュリティ、および運用セキュリティ管理が含まれます。
If applicable, other technical security controls on repositories, authoritative name servers, or other participants may also be documented here.
該当する場合、リポジトリ、権威ネームサーバー、または他の参加者に対する他の技術的なセキュリティ管理もここに文書化される場合があります。
Key pair generation and installation need to be considered, which may involve answering the following questions:
鍵ペアの生成とインストールを検討する必要があります。これには、次の質問への回答が含まれる場合があります。
1. Who generates the zone's public/private key pairs? How is the key generation performed? Is the key generation performed by hardware or software?
1. ゾーンの公開/秘密鍵ペアは誰が生成しますか？鍵の生成はどのように行われますか？鍵の生成はハードウェアまたはソフトウェアによって実行されますか？
2. How is the private key installed in all parts of the key management system?
2. 秘密鍵は、鍵管理システムのすべての部分にどのようにインストールされますか？
3. How are the zone's public keys provided securely to the parent zone and potential relying parties?
3. ゾーンの公開キーはどのようにして親ゾーンと潜在的な依存者に安全に提供されますか？
4. Who generates the public key parameters. Is the quality of the parameters checked during key generation?
4. 誰が公開鍵パラメータを生成するか。鍵の生成中にパラメーターの品質がチェックされますか？
5. For what purposes may the keys be used, and/or for what purposes should usage of the key be restricted?
5. キーはどのような目的で使用できますか？および/またはキーの使用をどのような目的で制限する必要がありますか？
4.5.2. Private Key Protection and Cryptographic Module Engineering Controls
4.5.2. 秘密鍵の保護と暗号化モジュールのエンジニアリング管理
Requirements for private key protection and cryptographic modules need to be considered for key generation and creation of signatures. The following questions may need to be answered: 1. What standards, if any, are required for the cryptographic module used to generate the keys? A cryptographic module can be composed of hardware, software, firmware, or any combination of them. For example, are the zone's signatures required to be generated using modules compliant with the US FIPS 140-2 [FIPS-140-2] standard? If so, what is the required FIPS 140-2 level of the module? Are there any other engineering or other controls relating to a cryptographic module, such as the identification of the cryptographic module boundary, input/ output, roles and services, finite state machine, physical security, software security, operating system security, algorithm compliance, electromagnetic compatibility, and self tests?
秘密鍵の保護と暗号化モジュールの要件は、鍵の生成と署名の作成のために考慮する必要があります。次の質問に回答する必要がある場合があります。1.鍵を生成するために使用される暗号モジュールに必要な標準がある場合、どのような標準が必要ですか？暗号化モジュールは、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組み合わせで構成できます。たとえば、ゾーンの署名は、US FIPS 140-2 [FIPS-140-2]標準に準拠したモジュールを使用して生成する必要がありますか？もしそうなら、モジュールの必要なFIPS 140-2レベルは何ですか？暗号化モジュールの境界、入力/出力、役割とサービス、有限状態機械、物理的セキュリティ、ソフトウェアセキュリティ、オペレーティングシステムセキュリティ、アルゴリズムコンプライアンス、電磁気の識別など、暗号化モジュールに関連する他のエンジニアリングまたはその他の制御はありますか？互換性、およびセルフテスト？
2. Is the private key under m of n multi-person control? If yes, provide m and n (two-person control is a special case of m of n, where m = 2 and n >= 2).
2. 秘密鍵はn人のm人の複数人による管理下にありますか？はいの場合は、mとnを指定します（2人のコントロールは、mがnの特別な場合で、m = 2およびn> = 2です）。
3. Is the private key escrowed? If so, who is the escrow agent, in what form is the key escrowed (e.g., plaintext, encrypted, split key), and what are the security controls on the escrow system?
3. 秘密鍵はエスクローされますか？その場合、エスクローエージェントは誰で、エスクローされたキーはどのような形式（例：平文、暗号化、分割キー）で、エスクローシステムのセキュリティコントロールは何ですか？
4. Is the private key backed up? If so, who is the backup agent, in what form is the key backed up (e.g., plaintext, encrypted, split key), and what are the security controls on the backup system?
4. 秘密鍵はバックアップされていますか？その場合、バックアップエージェントは誰で、どの形式でキーがバックアップされますか（例：平文、暗号化、分割キー）、バックアップシステムのセキュリティ管理は何ですか？
5. Is the private key archived? If so, who is the archival agent, in what form is the key archived (e.g. plaintext, encrypted, split key), and what are the security controls on the archival system?
5. 秘密鍵はアーカイブされていますか？もしそうなら、誰がアーカイブエージェントであり、どの形式でキーがアーカイブされているか（例：平文、暗号化、分割キー）、アーカイブシステムのセキュリティ管理は何ですか？
6. Under what circumstances, if any, can a private key be transferred into or from a cryptographic module? Who is permitted to perform such a transfer operation? In what form is the private key during the transfer (e.g., plaintext, encrypted, or split key)?
6. 秘密鍵を暗号化モジュールに転送したり、暗号化モジュールから転送したりできる状況はありますか？誰がそのような転送操作を実行することが許可されていますか？転送中の秘密鍵はどのような形式ですか（平文、暗号化、分割鍵など）？
7. How is the private key stored in the module (e.g., plaintext, encrypted, or split key)?
7. 秘密キーはどのようにモジュールに保存されますか（例：平文、暗号化、または分割キー）？
8. Who can activate (use) the private key? What actions must be performed to activate the private key (e.g., login, power on, supply PIN, insert token/key, automatic, etc.)? Once the key is activated, is the key active for an indefinite period, active for one time, or active for a defined time period?
8. 誰が秘密鍵をアクティブ化（使用）できますか？秘密キーをアクティブにするために実行する必要があるアクション（ログイン、電源オン、PINの提供、トークン/キーの挿入、自動など）は何ですか？キーがアクティブになると、キーは無期限にアクティブになりますか、1回アクティブになりますか、または定義された期間アクティブになりますか？
9. Who can deactivate the private key and how? Examples of methods of deactivating private keys include logging out, turning the power off, removing the token/key, automatic deactivation, and time expiration.
9. 秘密鍵を無効にできるのは誰ですか？秘密鍵を非アクティブ化する方法の例には、ログアウト、電源のオフ、トークン/キーの削除、自動非アクティブ化、および時間の満了が含まれます。
10. Who can destroy the private key and how? Examples of methods of destroying private keys include token surrender, token destruction, and zeroizing the key.
10. 誰が秘密鍵を破壊できますか？秘密鍵を破棄する方法の例には、トークンの降伏、トークンの破棄、および鍵のゼロ化が含まれます。
Other aspects of key management need to be considered for the zone operator and other participants. For each of these types of entities, the following questions may need to be answered:
ゾーン管理者と他の参加者は、キー管理の他の側面を考慮する必要があります。これらの種類のエンティティごとに、次の質問に回答する必要がある場合があります。
1. What are the life cycle states for the management of any signing keys?
1. 署名鍵を管理するためのライフサイクルの状態は何ですか？
2. What is the operational period of these keys? What are the usage periods or active lifetimes for the pairs?
2. これらのキーの運用期間はどのくらいですか？ペアの使用期間またはアクティブなライフタイムは何ですか？
Activation data refers to data values other than whole private keys that are required to operate private keys or cryptographic modules containing private keys, such as a PIN, passphrase, or portions of a private key used in a key-splitting scheme. Protection of activation data prevents unauthorized use of the private key and potentially needs to be considered for the zone operator and other participants. Such a consideration may need to address the entire life cycle of the activation data from generation through archival and destruction. For each of the entity types, all of the questions listed in Sections 4.5.1 through 4.5.3 potentially need to be answered with respect to activation data rather than with respect to keys.
アクティベーションデータとは、PIN、パスフレーズ、またはキー分割スキームで使用される秘密キーの一部など、秘密キーまたは秘密キーを含む暗号化モジュールを操作するために必要な秘密キー全体以外のデータ値のことです。アクティベーションデータを保護することで、秘密キーの不正使用を防止し、ゾーンオペレーターや他の参加者が考慮する必要がある可能性があります。このような考慮事項は、生成からアーカイブおよび破棄までのアクティベーションデータのライフサイクル全体に対処する必要がある場合があります。エンティティタイプごとに、セクション4.5.1から4.5.3にリストされているすべての質問に、キーではなくアクティベーションデータに関して回答する必要がある可能性があります。
This subcomponent is used to describe computer security controls such as:
このサブコンポーネントは、次のようなコンピュータセキュリティコントロールを説明するために使用されます。
1. use of the trusted computing base concept or equivalent;
1. 信頼できるコンピューティングベースコンセプトまたは同等の使用。
2. discretionary access control, labels, mandatory access controls;
2. 随意アクセス制御、ラベル、必須アクセス制御;
3. object reuse;
3. オブジェクトの再利用;
4. auditing;
4. 監査;
5. identification and authentication;
5. 識別と認証;
6. trusted path; and
6. 信頼できるパス。そして
7. security testing.
7. セキュリティテスト。
This subcomponent may also address requirements for product assurance, product evaluation analysis, testing, profiling, product certification, and/or product accreditation.
このサブコンポーネントは、製品保証、製品評価分析、テスト、プロファイリング、製品認証、および/または製品認定の要件にも対処できます。
This subcomponent addresses network security related controls, including firewalls, routers, and remote access.
このサブコンポーネントは、ファイアウォール、ルーター、リモートアクセスなどのネットワークセキュリティ関連の制御を扱います。
This subcomponent addresses requirements or practices relating to the use of timestamps on various data. It may also discuss whether or not the timestamping application must use a trusted time source.
このサブコンポーネントは、さまざまなデータでのタイムスタンプの使用に関する要件または慣行に対処します。また、タイムスタンプアプリケーションが信頼できるタイムソースを使用する必要があるかどうかについても説明します。
This subcomponent addresses system development controls and security management controls.
このサブコンポーネントは、システム開発管理とセキュリティ管理管理を扱います。
System development controls include development environment security, development personnel security, configuration management security during product maintenance, software engineering practices, software development methodology, modularity, layering, use of fail-safe design and implementation techniques (e.g., defensive programming), and development facility security.
システム開発管理には、開発環境のセキュリティ、開発担当者のセキュリティ、製品メンテナンス中の構成管理セキュリティ、ソフトウェアエンジニアリングの実践、ソフトウェア開発方法論、モジュール性、階層化、フェイルセーフ設計および実装技術（防御的プログラミングなど）の使用、および開発施設が含まれます。セキュリティ。
Security management controls include execution of tools and procedures to ensure that the operational systems and networks adhere to configured security. These tools and procedures include checking the integrity of the security software, firmware, and hardware to ensure their correct operation.
セキュリティ管理コントロールには、運用システムとネットワークが構成されたセキュリティを確実に遵守するためのツールと手順の実行が含まれます。これらのツールと手順には、セキュリティソフトウェア、ファームウェア、ハードウェアの整合性をチェックして、正しく動作することを確認することが含まれます。
This component covers all aspects of zone signing, including the cryptographic specification surrounding the signing keys, signing scheme, and methodology for key rollover and the actual zone signing. Child zones and other relying parties may depend on the information in this section to understand the expected data in the signed zone and determine their own behavior. In addition, this section will be used to state the compliance to the cryptographic and operational requirements pertaining to zone signing, if any.
このコンポーネントは、署名キーを取り巻く暗号仕様、署名スキーム、およびキーロールオーバーの方法と実際のゾーン署名を含む、ゾーン署名のすべての側面をカバーします。子ゾーンおよびその他の証明書利用者は、このセクションの情報に依存して、署名済みゾーンで予期されるデータを理解し、独自の動作を決定できます。さらに、このセクションは、ゾーンの署名に関連する暗号化要件と運用要件への準拠を示すために使用されます（ある場合）。
This subcomponent describes the key generation algorithm, the key types used for signing the key set and zone data, and key lengths used to create the keys. It should also cover how changes to these key lengths, key types, and algorithms may be performed.
このサブコンポーネントは、キー生成アルゴリズム、キーセットとゾーンデータの署名に使用されるキータイプ、およびキーの作成に使用されるキーの長さについて説明します。また、これらのキーの長さ、キーの種類、およびアルゴリズムの変更がどのように実行されるかについても説明する必要があります。
Authenticated denial of existence refers to the usage of NSEC [RFC4034], NSEC3 [RFC5155], or any other mechanism defined in the future that is used to authenticate the denial of existence of resource records. This subcomponent describes what mechanisms are used, any parameters associated with that mechanism, and how these mechanisms and parameters may be changed.
認証された存在の拒否とは、NSEC [RFC4034]、NSEC3 [RFC5155]、またはリソースレコードの存在の拒否を認証するために将来的に定義されるその他のメカニズムの使用法を指します。このサブコンポーネントでは、使用されるメカニズム、そのメカニズムに関連付けられているパラメーター、およびこれらのメカニズムとパラメーターを変更する方法について説明します。
This subcomponent is used to describe the signing method and algorithms used for the zone signing.
このサブコンポーネントは、ゾーン署名に使用される署名方法とアルゴリズムを記述するために使用されます。
This subcomponent explains the key rollover scheme for each key type.
このサブコンポーネントは、各キータイプのキーロールオーバースキームを説明します。
This subcomponent describes the life cycle of the Resource Record Signature (RRSIG) record.
このサブコンポーネントは、リソースレコード署名（RRSIG）レコードのライフサイクルを記述します。
This subsection addresses the controls around the verification of the resource records in order to validate and authenticate the data to be signed. This may include a separate key set verification process if using a split key signing scheme.
このサブセクションでは、署名するデータを検証および認証するための、リソースレコードの検証に関する制御について説明します。分割鍵署名方式を使用している場合、これには別個の鍵セット検証プロセスが含まれる場合があります。
This subcomponent specifies the resource records' time-to-live (TTL) for all types relevant to DNSSEC, as well as any global parameters that affect the caching mechanisms of the resolvers.
このサブコンポーネントは、DNSSECに関連するすべてのタイプのリソースレコードの存続可能時間（TTL）と、リゾルバーのキャッシュメカニズムに影響を与えるグローバルパラメーターを指定します。
To prove the compliance with a Policy or the statements in the Practice Statement, a compliance audit can be conducted. This component describes how the audit is to be conducted at the zone operator and, possibly, at other involved entities.
ポリシーまたは実践ステートメントのステートメントへのコンプライアンスを証明するために、コンプライアンス監査を実施できます。このコンポーネントは、ゾーンオペレータ、および場合によっては他の関係するエンティティで監査がどのように行われるかを記述します。
This subcomponent describes the frequency of the compliance audit.
このサブコンポーネントは、コンプライアンス監査の頻度を記述します。
This subcomponent addresses what qualifications are required of the auditor. For instance, it may be that an auditor must belong to a specific association or that they have certain certifications.
このサブコンポーネントは、監査人に必要な資格を扱います。たとえば、監査人は特定の協会に所属している必要がある場合や、特定の認証を取得している場合があります。
This subcomponent is used to clarify the relationship between the auditor and the entity being audited. This becomes important if there are any requirements or guidelines for the selection of the auditor.
このサブコンポーネントは、監査人と監査対象のエンティティの間の関係を明確にするために使用されます。これは、監査人の選択に関する要件やガイドラインがある場合に重要になります。
Topics covered by audit depends on the scope of the audit. Since the DNSSEC Policy and Practice Statement is the document to be audited against, it is ideal to set the scope of the audit to the scope of the DP/DPS. However, the scope may be narrowed down or expanded as needed, for example, if there are not enough resources to conduct a full audit or if some portion is under development and not ready for the audit.
監査の対象となるトピックは、監査の範囲によって異なります。 DNSSECポリシーと実践ステートメントは監査対象のドキュメントであるため、監査の範囲をDP / DPSの範囲に設定することが理想的です。ただし、たとえば、完全な監査を実施するための十分なリソースがない場合、または一部が開発中であり、監査の準備ができていない場合など、必要に応じて範囲を絞り込んだり、拡大したりできます。
This subcomponent specifies the action taken in order to correct any discrepancy that has a security impact. This could be the remediation process for the audit findings or any other action to correct any discrepancy with the DNSSEC Policy or Practice Statement.
このサブコンポーネントは、セキュリティに影響を与える不一致を修正するために実行されるアクションを指定します。これは、監査結果またはDNSSECポリシーまたは実務声明との不一致を修正するためのその他のアクションの修正プロセスになる可能性があります。
This subcomponent specifies how the results of the audit are communicated to the stakeholders.
このサブコンポーネントは、監査の結果を利害関係者に伝達する方法を指定します。
The introduction of DNSSEC into a zone may have legal implications. Consequently, it may be appropriate to declare the legal status of the binding embodied in the DNSSEC digital signatures and to clarify on any limitations of liability asserted by the registry manager.
ゾーンへのDNSSECの導入は、法的な意味を持つ場合があります。したがって、DNSSECデジタル署名で具体化されたバインディングの法的ステータスを宣言し、レジストリマネージャーが主張する責任の制限を明確にすることが適切な場合があります。
In most cases, the DPS is not a contract or part of a contract; instead, it is laid out so that its terms and conditions are applied to the parties by separate documents, such as registrar or registrant agreements. In other cases, its contents may form part of a legal contract between parties (either directly or via other agreements). In this case, legal expertise should be consulted when drawing up sections of the document that may have contractual implications.
ほとんどの場合、DPSは契約または契約の一部ではありません。代わりに、その条件が、レジストラや登録者の合意などの個別のドキュメントによって当事者に適用されるようにレイアウトされています。他の場合では、その内容は当事者間の法的契約の一部を形成する場合があります（直接または他の合意を介して）。この場合、契約に影響を与える可能性のあるドキュメントのセクションを作成するときは、法的専門知識を参照する必要があります。
At a minimum, the Legal Matters section should indicate under what jurisdiction the registry is operated and provide references to any associated agreements that are in force. It may also be appropriate to inform of any identified implications on the protection of personally identifiable private information.
少なくとも、法的事項のセクションでは、レジストリが運用されている管轄区域の下で、有効な関連契約への参照を提供する必要があります。また、個人を特定できる個人情報の保護に関して特定された含意を通知することも適切な場合があります。
This section contains a recommended outline for a set of provisions, intended to serve as a checklist or a standard template for use by DP or DPS writers. Such a common outline will facilitate:
このセクションには、DPまたはDPSライターが使用するチェックリストまたは標準テンプレートとして機能することを目的とした、一連の規定の推奨される概要が含まれています。このような共通のアウトラインにより、以下が容易になります。
(a) Comparison of a DPS with a DP to ensure that the DPS faithfully implements the policy.
（a）DPSとDPの比較により、DPSがポリシーを忠実に実装していることを確認します。
(b) Comparison of two DPSs.
（b）2つのDPSの比較。
Section 4 of this document is structured so that it provides guidance for each corresponding component and subcomponent of the outline.
このドキュメントのセクション4は、アウトラインの対応するコンポーネントおよびサブコンポーネントごとにガイダンスを提供するように構成されています。
1. INTRODUCTION 1.1. Overview 1.2. Document name and identification 1.3. Community and applicability 1.4. Specification administration 1.4.1. Specification administration organization 1.4.2. Contact information 1.4.3. Specification change procedures 2. PUBLICATION AND REPOSITORIES 2.1. Repositories 2.2. Publication of public keys 3. OPERATIONAL REQUIREMENTS 3.1. Meaning of domain names 3.2. Identification and authentication of child zone manager 3.3. Registration of delegation signer (DS) resource records 3.4. Method to prove possession of private key 3.5. Removal of DS resource records 3.5.1. Who can request removal 3.5.2. Procedure for removal request 3.5.3. Emergency removal request 4. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS 4.1. Physical controls 4.1.1. Site location and construction 4.1.2. Physical access 4.1.3. Power and air conditioning 4.1.4. Water exposures 4.1.5. Fire prevention and protection 4.1.6. Media storage 4.1.7. Waste disposal 4.1.8. Off-site backup 4.2. Procedural controls 4.2.1. Trusted roles 4.2.2. Number of persons required per task 4.2.3. Identification and authentication for each role 4.2.4. Tasks requiring separation of duties 4.3. Personnel controls 4.3.1. Qualifications, experience, and clearance requirements 4.3.2. Background check procedures 4.3.3. Training requirements 4.3.4. Job rotation frequency and sequence 4.3.5. Sanctions for unauthorized actions 4.3.6. Contracting personnel requirements 4.3.7. Documentation supplied to personnel 4.4. Audit logging procedures 4.4.1. Types of events recorded 4.4.2. Frequency of processing log 4.4.3. Retention period for audit log information 4.4.4. Protection of audit log 4.4.5. Audit log backup procedures 4.4.6. Audit collection system 4.4.7. Vulnerability assessments 4.5. Compromise and disaster recovery 4.5.1. Incident and compromise handling procedures 4.5.2. Corrupted computing resources, software, and/or data 4.5.3. Entity private key compromise procedures 4.5.4. Business continuity and IT disaster recovery capabilities 4.6. Entity termination
1.はじめに1.1。概要1.2。文書名と識別1.3。コミュニティと適用性1.4。仕様管理1.4.1。仕様管理組織1.4.2。連絡先情報1.4.3。仕様変更手順2.公開とリポジトリ2.1。リポジトリ2.2。公開鍵の公開3.運用要件3.1。ドメイン名の意味3.2。子ゾーンマネージャーの識別と認証3.3。委任署名者（DS）リソースレコードの登録3.4。秘密鍵の所持を証明する方法3.5。 DSリソースレコードの削除3.5.1。誰が削除をリクエストできるか3.5.2。削除依頼の手順3.5.3。緊急削除リクエスト4.施設、管理、および運用管理4.1。物理的制御4.1.1。サイトの場所と建設4.1.2。物理的アクセス4.1.3。電力および空調4.1.4。水への暴露4.1.5。防火および保護4.1.6。メディアストレージ4.1.7。廃棄物処理4.1.8。オフサイトバックアップ4.2。手続き管理4.2.1。信頼されたロール4.2.2。タスクごとに必要な人数4.2.3。各ロールの識別と認証4.2.4。職務の分離を必要とするタスク4.3。人事管理4.3.1。資格、経験、およびクリアランスの要件4.3.2。バックグラウンドチェックの手順4.3.3。トレーニング要件4.3.4。ジョブローテーションの頻度と順序4.3.5。不正行為に対する制裁4.3.6。契約要員の要件4.3.7。担当者に提供されるドキュメント4.4。監査ロギング手順4.4.1。記録されたイベントのタイプ4.4.2。ログの処理頻度4.4.3。監査ログ情報の保存期間4.4.4。監査ログの保護4.4.5。監査ログのバックアップ手順4.4.6。監査収集システム4.4.7。脆弱性の評価4.5。妥協と災害復旧4.5.1。インシデントと妥協の取り扱い手順4.5.2。コンピューティングリソース、ソフトウェア、データの破損4.5.3。エンティティの秘密鍵の侵害手順4.5.4。ビジネス継続性とIT災害復旧機能4.6。エンティティの終了
5. TECHNICAL SECURITY CONTROLS 5.1. Key pair generation and installation 5.1.1. Key pair generation 5.1.2. Public key delivery 5.1.3. Public key parameters generation and quality checking 5.1.4. Key usage purposes 5.2. Private key protection and cryptographic module engineering controls 5.2.1. Cryptographic module standards and controls 5.2.2. Private key (m-of-n) multi-person control 5.2.3. Private key escrow 5.2.4. Private key backup 5.2.5. Private key storage on cryptographic module 5.2.6. Private key archival 5.2.7. Private key transfer into or from a cryptographic module 5.2.8. Method of activating private key 5.2.9. Method of deactivating private key 5.2.10. Method of destroying private key 5.3. Other aspects of key pair management 5.4. Activation data 5.4.1. Activation data generation and installation 5.4.2. Activation data protection 5.4.3. Other aspects of activation data 5.5. Computer security controls 5.6. Network security controls 5.7. Timestamping 5.8. Life cycle technical controls 6. ZONE SIGNING 6.1. Key lengths, key types, and algorithms 6.2. Authenticated denial of existence 6.3. Signature format 6.4. Key rollover 6.5. Signature lifetime and re-signing frequency 6.6. Verification of resource records 6.7. Resource records time-to-live 7. COMPLIANCE AUDIT 7.1. Frequency of entity compliance audit 7.2. Identity/qualifications of auditor 7.3. Auditor's relationship to audited party 7.4. Topics covered by audit 7.5. Actions taken as a result of deficiency 7.6. Communication of results 8. LEGAL MATTERS
5. 技術的なセキュリティ管理5.1。鍵ペアの生成とインストール5.1.1。鍵ペアの生成5.1.2。公開鍵の配信5.1.3。公開鍵パラメーターの生成と品質チェック5.1.4。キーの使用目的5.2。秘密鍵の保護と暗号化モジュールのエンジニアリング管理5.2.1。暗号モジュールの標準と管理5.2.2。秘密鍵（m-of-n）マルチパーソンコントロール5.2.3。秘密鍵エスクロー5.2.4。秘密鍵のバックアップ5.2.5。暗号化モジュールの秘密鍵ストレージ5.2.6。秘密鍵のアーカイブ5.2.7。暗号化モジュールとの間の秘密鍵の転送5.2.8。秘密鍵をアクティベートする方法5.2.9。秘密鍵を非アクティブ化する方法5.2.10。秘密鍵を破棄する方法5.3。鍵ペア管理の他の側面5.4。アクティベーションデータ5.4.1。アクティベーションデータの生成とインストール5.4.2。アクティベーションデータ保護5.4.3。アクティベーションデータの他の側面5.5。コンピュータのセキュリティ管理5.6。ネットワークセキュリティ管理5.7。タイムスタンプ5.8。ライフサイクル技術管理6.ゾーン署名6.1。鍵の長さ、鍵のタイプ、およびアルゴリズム6.2。認証された存在の拒否6.3。署名フォーマット6.4。キーのロールオーバー6.5。署名の有効期間と再署名の頻度6.6。リソースレコードの検証6.7。リソースは存続時間を記録します。7.コンプライアンス監査7.1。エンティティコンプライアンス監査の頻度7.2。監査人のアイデンティティ/資格7.3。監査人と被監査者との関係7.4。監査の対象となるトピック7.5。欠陥の結果として取られた措置7.6。結果の伝達8.法的事項
The sensitivity of the information protected by DNSSEC at different tiers in the DNS tree varies significantly. In addition, there are no restrictions as to what types of information (i.e., DNS records) that can be protected using DNSSEC. Each relying party must evaluate its own environment and the chain of trust originating from a trust anchor, the associated threats and vulnerabilities, to determine the level of risk it is willing to accept when relying on DNSSEC-protected objects.
DNSSECによって保護された情報の機密性は、DNSツリーのさまざまな層で大きく異なります。さらに、DNSSECを使用して保護できる情報のタイプ（DNSレコード）に関する制限はありません。各依存パーティは、DNSSECで保護されたオブジェクトに依存するときに受け入れることができるリスクのレベルを決定するために、独自の環境と、トラストアンカーから発生する信頼の連鎖、関連する脅威と脆弱性を評価する必要があります。
This document is inspired by RFC 3647 and its predecessor (RFC 2527), and the authors acknowledge the work in the development of these documents.
この文書はRFC 3647とその前身（RFC 2527）に触発されており、著者はこれらの文書の開発における成果を認めています。
In addition, the authors would like to acknowledge the contributions made by Richard Lamb, Jakob Schlyter, and Stephen Morris.
さらに、著者は、Richard Lamb、Jakob Schlyter、およびStephen Morrisの貢献に謝意を表します。
[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.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの概要と要件」、RFC 4033、2005年3月。
[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.、Larson、M.、Massey、D。、およびS. Rose、「DNS Security Extensionsのリソースレコード」、RFC 4034、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.、Larson、M.、Massey、D。、およびS. Rose、「DNS Security Extensionsのプロトコル変更」、RFC 4035、2005年3月。
[FIPS-140-2] NIST, "Security Requirements for Cryptographic Modules", June 2005, <http://csrc.nist.gov/ publications/fips/fips140-2/fips1402.pdf>.
[FIPS-140-2] NIST、「暗号化モジュールのセキュリティ要件」、2005年6月、<http://csrc.nist.gov/ publications / fips / fips140-2 / fips1402.pdf>。
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", RFC 3647, November 2003.
[RFC3647] Chokhani、S.、Ford、W.、Sabett、R.、Merrill、C.、and S. Wu、 "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework"、RFC 3647、November 2003。
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008.
[RFC5155] Laurie、B.、Sisson、G.、Arends、R。、およびD. Blacka、「DNS Security（DNSSEC）Hashed Authenticated Denial of Existence」、RFC 5155、2008年3月。
Authors' Addresses
著者のアドレス
Fredrik Ljunggren Kirei AB P.O. Box 53204 Goteborg SE-400 16 Sweden
Ｆれｄりｋ Ｌじゅんっｇれん きれい あＢ Ｐ。お。 ぼｘ ５３２０４ ごてぼｒｇ せー４００ １６ すぇでん
EMail: fredrik@kirei.se
Anne-Marie Eklund Lowinder .SE (The Internet Infrastructure Foundation) P.O. Box 7399 Stockholm SE-103 91 Sweden
Anne-Marie Eklund Lowinder .SE（The Internet Infrastructure Foundation）P.O.ボックス7399ストックホルムSE-103 91スウェーデン
EMail: amel@iis.se
Tomofumi Okubo Internet Corporation For Assigned Names and Numbers 4676 Admiralty Way, Suite 330 Marina del Ray, CA 90292 USA
大久保知文インターネット株式会社割り当てられた名前と番号について4676 Admiralty Way、Suite 330 Marina del Ray、CA 90292 USA
EMail: tomofumi.okubo@icann.org