RFC 5910 - Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP) 日本語訳

URL : https://tools.ietf.org/html/rfc5910
タイトル : RFC 5910 - ドメインネームシステム（DNS）拡張プロビジョニングプロトコルのためのセキュリティ拡張機能のマッピング（EPP）
翻訳編集 : 自動生成

Internet Engineering Task Force (IETF)                          J. Gould
Request for Comments: 5910                                 S. Hollenbeck
Obsoletes: 4310                                           VeriSign, Inc.
Category: Standards Track                                       May 2010
ISSN: 2070-1721

          Domain Name System (DNS) Security Extensions Mapping
             for the Extensible Provisioning Protocol (EPP)

Abstract

抽象

This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of Domain Name System security (DNSSEC) extensions for domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of DNS security extensions. This document obsoletes RFC 4310.

この文書では、ドメインネームシステムセキュリティ（DNSSEC）共有中央リポジトリに保存されたドメイン名の拡張子のプロビジョニングと管理のための拡張可能なプロビジョニングプロトコル（EPP）拡張子マッピングについて説明します。 XMLで指定され、このマッピングは、DNSセキュリティ拡張のプロビジョニングに必要な追加機能を提供するために、EPPドメイン名マッピングを拡張します。この文書はRFC 4310を廃止します。

Status of This Memo

このメモのステータス

This is an Internet Standards Track document.

これは、インターネット標準化過程文書です。

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). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（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/rfc5910.

このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5910で取得することができます。

著作権表示

著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Conventions Used in This Document  . . . . . . . . . . . .  4
   2.  Migrating from RFC 4310  . . . . . . . . . . . . . . . . . . .  4
   3.  Object Attributes  . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Delegation Signer Information  . . . . . . . . . . . . . .  5
       3.1.1.  Public Key Information . . . . . . . . . . . . . . . .  5
     3.2.  Booleans . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.3.  Maximum Signature Lifetime . . . . . . . . . . . . . . . .  5
   4.  DS Data Interface and Key Data Interface . . . . . . . . . . .  6
     4.1.  DS Data Interface  . . . . . . . . . . . . . . . . . . . .  7
     4.2.  Key Data Interface . . . . . . . . . . . . . . . . . . . .  7
     4.3.  Example DS Data Interface and Key Data Interface . . . . .  8
   5.  EPP Command Mapping  . . . . . . . . . . . . . . . . . . . . .  9
     5.1.  EPP Query Commands . . . . . . . . . . . . . . . . . . . .  9
       5.1.1.  EPP <check> Command  . . . . . . . . . . . . . . . . .  9
       5.1.2.  EPP <info> Command . . . . . . . . . . . . . . . . . .  9
       5.1.3.  EPP <transfer> Command . . . . . . . . . . . . . . . . 13
     5.2.  EPP Transform Commands . . . . . . . . . . . . . . . . . . 14
       5.2.1.  EPP <create> Command . . . . . . . . . . . . . . . . . 14
       5.2.2.  EPP <delete> Command . . . . . . . . . . . . . . . . . 17
       5.2.3.  EPP <renew> Command  . . . . . . . . . . . . . . . . . 18
       5.2.4.  EPP <transfer> Command . . . . . . . . . . . . . . . . 18
       5.2.5.  EPP <update> Command . . . . . . . . . . . . . . . . . 18
   6.  Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . . 25
   7.  Internationalization Considerations  . . . . . . . . . . . . . 29
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 29
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 30
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 31
     11.2. Informative References . . . . . . . . . . . . . . . . . . 32
   Appendix A.  Changes from RFC 4310 . . . . . . . . . . . . . . . . 33

1. Introduction

1. はじめに

This document describes an extension mapping for version 1.0 of the Extensible Provisioning Protocol (EPP) described in RFC 5730 [RFC5730]. This mapping, an extension of the domain name mapping described in RFC 5731 [RFC5731], is specified using the Extensible Markup Language (XML) 1.0 [W3C.REC-xml-20001006] and XML Schema notation ([W3C.REC-xmlschema-1-20010502] [W3C.REC-xmlschema-2-20010502]).

この文書は、RFC 5730 [RFC5730]に記載の拡張可能なプロビジョニングプロトコル（EPP）のバージョン1.0の拡張マッピングを記述する。このマッピングは、RFC 5731 [RFC5731]に記載されたドメイン名のマッピングの拡張は、拡張マークアップ言語（XML）1.0 [W3C.REC-XML-20001006]とXMLスキーマ表記（[W3C.REC-xmlschema-を使用して指定されています1-20010502] [W3C.REC-XMLSCHEMA-2から20010502]）。

The EPP core protocol specification [RFC5730] provides a complete description of EPP command and response structures. A thorough understanding of the base protocol specification is necessary to understand the mapping described in this document. Familiarity with the Domain Name System (DNS) described in RFC 1034 [RFC1034] and RFC 1035 [RFC1035] and with DNS security extensions described in RFC 4033 [RFC4033], RFC 4034 [RFC4034], and RFC 4035 [RFC4035] is required to understand the DNS security concepts described in this document.

EPPコアプロトコル仕様[RFC5730]はEPPコマンドとレスポンスの構造の完全な説明を提供します。基本プロトコル仕様の完全な理解は、本書で説明したマッピングを理解する必要があります。 RFC 1034に記載のドメインネームシステム（DNS）に精通している[RFC1034]及びRFC 1035 [RFC1035]及びRFC 4033に記載されたDNSセキュリティ拡張と[RFC4033]、RFC 4034 [RFC4034]、およびRFC 4035 [RFC4035]が要求されますこのドキュメントで説明するDNSのセキュリティの概念を理解しています。

The EPP mapping described in this document specifies a mechanism for the provisioning and management of DNS security extensions in a shared central repository. Information exchanged via this mapping can be extracted from the repository and used to publish DNSSEC Delegation Signer (DS) resource records (RRs) as described in RFC 4034 [RFC4034].

この文書で説明EPPマッピングは共有中央リポジトリ内のDNSセキュリティ拡張のプロビジョニングと管理のためのメカニズムを指定します。このマッピングを介して交換される情報は、リポジトリから抽出され、RFC 4034 [RFC4034]に記載されているようにDNSSEC委任署名者（DS）リソースレコード（RR）を公開するために使用することができます。

This document obsoletes RFC 4310 [RFC4310]; thus, secDNS-1.1 as defined in this document deprecates secDNS-1.0 [RFC4310]. The motivation behind obsoleting RFC 4310 [RFC4310] includes:

この文書は、RFC 4310 [RFC4310]を廃止します。従って、secDNS-1.1本文書で定義されるようにsecDNS-1.0 [RFC4310]を非難します。時代遅れのRFC 4310 [RFC4310]の背後にある動機は含まれています：

- Addressing the issue with removing DS data based on the non-unique <secDNS:keyTag> element. The client should explicitly specify the DS data to be removed, by using all four <secDNS:dsData> elements that are guaranteed to be unique.

要素： - 非ユニーク<キータグsecDNS>に基づいて、DSのデータを削除して問題に対処します。一意であることが保証されます。<dsData secDNS>要素クライアントは、明示的にすべての4つを使用することにより、削除されるDSデータを指定する必要があります。

- Adding the ability to add and remove <secDNS:dsData> elements in a single command. This makes it consistent with RFC 5731 [RFC5731].

単一のコマンドで<dsData secDNS>要素 - 追加および削除する機能を追加します。これは、RFC 5731 [RFC5731]と、それは一貫します。

- Clarifying and correcting the usage of the <secDNS:chg> element. RFC 4310 [RFC4310] defined the <secDNS:chg> element as a replacement for the DS data. This is inconsistent with RFC 5731 [RFC5731], where a <domain:chg> element is used to change the values of the domain attributes.

- 明確化の使用補正<secDNS：CHG>要素。 DSデータの代わりにエレメント：RFC 4310 [RFC4310]は<CHG secDNS>を定義しました。 <：CHGドメイン>要素のドメイン属性の値を変更するために使用され、これは、RFC 5731 [RFC5731]と矛盾しています。

- Adding support for the Key Data Interface described in Section 4.2 for "thick" DNSSEC servers that accept only key data and generate the associated DS data.

- 主なデータインタフェースのサポートを追加すると、キーデータのみを受け入れ、関連するDS用データを生成する「厚い」DNSSECサーバについては、セクション4.2で説明します。

1.1. Conventions Used in This Document

1.1. このドキュメントの表記規則

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 BCP 14, RFC 2119 [RFC2119].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119 [RFC2119]に記載されているように解釈されます。

In examples, "C:" represents lines sent by a protocol client, and "S:" represents lines returned by a protocol server. "////" is used to note element values that have been shortened to better fit page boundaries. Indentation and white space in examples is provided only to illustrate element relationships and is not a mandatory feature of this protocol.

実施例では、「C：」は、プロトコルクライアントによって送信された行を表し、そして「S：」プロトコル・サーバーによって戻さ行を表します。「////」よりよいフィットページ境界に短縮されている要素の値を注意するために使用されます。実施例におけるくぼみとホワイトスペースは、要素の関係を説明するためにのみ提供され、このプロトコルの必須の特徴ではありません。

XML is case sensitive. Unless stated otherwise, XML specifications and examples provided in this document MUST be interpreted in the character case presented in order to develop a conforming implementation.

XMLは大文字と小文字が区別されます。特に明記しない限り、このドキュメントに記載されているXMLの仕様および実施例は、適合実装を開発するために提示された文字ケースで解釈されなければなりません。

secDNS-1.0 is used as an abbreviation for urn:ietf:params:xml:ns:secDNS-1.0, and secDNS-1.1 is used as an abbreviation for urn:ietf:params:xml:ns:secDNS-1.1.

IETF：paramsは：XML：NS：IETF：paramsは：XML：NS：secDNS-1.1 secDNS-1.0、及びsecDNS-1.1はURNの略語として使用さsecDNS-1.0はURNの略語として使用されます。

2. Migrating from

2.からの移行

This section includes implementation recommendations for clients and servers to use in migrating from secDNS-1.0 [RFC4310] to secDNS-1.1.

このセクションでは、secDNS-1.1 secDNS-1.0 [RFC4310]からの移行で使用するクライアントとサーバの実装の推奨事項が含まれています。

As this document deprecates RFC 4310 [RFC4310], if a server announces support for both secDNS-1.0 [RFC4310] and secDNS-1.1 in the EPP greeting, clients supporting both versions SHOULD prefer secDNS-1.1.

この文書はRFC 4310 [RFC4310]を非難するようサーバがsecDNS-1.0 [RFC4310]とsecDNS-1.1 EPPの挨拶で両方のサポートを発表した場合、両方のバージョンをサポートするクライアントは、secDNS-1.1を好むべきです。

A server SHOULD do the following to help clients migrate from secDNS-1.0 [RFC4310] to secDNS-1.1 as defined in this document.

サーバーは、この文書で定義されているクライアントはsecDNS-1.1にsecDNS-1.0から[RFC4310]を移行を支援するために、以下を行う必要があります。

1. A server migrating from secDNS-1.0 [RFC4310] to secDNS-1.1 SHOULD support both versions (i.e., secDNS-1.0 and secDNS-1.1) for a reasonable migration period.

secDNS-1.1 1. secDNS-1.0から移行サーバ[RFC4310]は、合理的な移行期間の両方のバージョン（すなわち、secDNS-1.0およびsecDNS-1.1）をサポートすべきです。

2. The version of the <secDNS:infData> element to be returned by the server in the response to a <domain:info> response SHOULD depend on the <extURI> elements (indicating the secDNS extension) the client included in the EPP <login> command using the following mapping:

2のバージョン：に応じてサーバによって返される<secDNS infData>要素<ドメイン：インフォメーション>応答は、<<extURI>要素（secDNS拡張を示す）にEPPに含まれるクライアントに依存すべき次のマッピングを使用してログイン>コマンドを実行します。

       -  Return version secDNS-1.1 of the <secDNS:infData> element if
          urn:ietf:params:xml:ns:secDNS-1.1 was included as an <extURI>
          element in the EPP <login> command, independent of whether urn:ietf:params:xml:ns:secDNS-1.0 is also included as an
          <extURI> element in the EPP <login> command.

- Return version secDNS-1.0 of the <secDNS:infData> element if urn:ietf:params:xml:ns:secDNS-1.0 but not urn:ietf:params:xml:ns:secDNS-1.1 was included as an <extURI> element in the EPP <login> command.

- 戻りバージョンsecDNS-1.0のIETF：のparams：XML：NS：secDNS-1.0ではなく、URN：IETF：のparams：XML：NS：secDNS-1.1 <extURI>として含まれていた<secDNS：infData>要素URNがあればEPP <ログイン>コマンド内の要素。

- Don't return the <secDNS:infData> element if neither urn:ietf:params:xml:ns:secDNS-1.0 nor urn:ietf:params:xml:ns:secDNS-1.1 was included as an <extURI> element in the EPP <login> command.

- 返さないIETF：のparams：XML：NS：secDNS-1.0もURN：IETF：のparams：XML：NS：secDNS-1.1で、<extURI>要素として含まれていた。どちらの骨壷があれば、<secDNS infData>要素をEPP <ログイン>コマンド。

3. Object Attributes

3.オブジェクトの属性

This extension adds additional elements to the EPP domain name mapping [RFC5731]. Only those new elements are described here.

この拡張は、EPPドメイン名マッピング[RFC5731]に追加要素を追加します。だけが新しい要素がここで説明されています。

3.1. Delegation Signer Information

3.1. 委任署名者情報

Delegation Signer (DS) information is published by a DNS server to indicate that a child zone is digitally signed and that the parent zone recognizes the indicated key as a valid zone key for the child zone. A DS resource record (RR) contains four fields: a key tag field, a key algorithm number octet, an octet identifying a digest algorithm, and a digest field. See RFC 4034 [RFC4034] for specific field formats.

委任署名者（DS）の情報が子ゾーンがデジタル署名と親ゾーンは、子ゾーンに対して有効なゾーンキーとして指定されたキーを認識していることを示すために、DNSサーバによって公開されています。キータグフィールド、キーアルゴリズム番号オクテット、ダイジェストアルゴリズムを識別するオクテット、およびダイジェストフィールド：DSリソースレコード（RR）は、4つのフィールドを含んでいます。特定のフィールドの形式については、RFC 4034 [RFC4034]を参照してください。

3.1.1. Public Key Information

3.1.1. 公開鍵情報

Public key information provided by a client maps to the DNSKEY RR presentation field formats described in Section 2.2 of RFC 4034 [RFC4034]. A DNSKEY RR contains four fields: flags, a protocol octet, an algorithm number octet, and a public key.

クライアントが提供する公開鍵情報は、RFC 4034 [RFC4034]の2.2節で説明したDNSKEYのRRプレゼンテーションフィールド形式にマッピングされます。フラグ、プロトコルオクテット、アルゴリズム番号オクテット、および公開鍵：DNSKEY RRは4つのフィールドが含まれています。

3.2. Booleans

3.2. ブール

Boolean values MUST be represented in the XML Schema format described in Part 2 of the W3C XML Schema recommendation [W3C.REC-xmlschema-2-20010502].

ブール値は、[W3C.REC-XMLSCHEMA-2から20010502] W3C XMLスキーマ勧告のパート2に記述されたXMLスキーマの形式で表現されなければなりません。

3.3. Maximum Signature Lifetime

3.3. 最大署名の有効期間

Maximum signature lifetime (maxSigLife) is an OPTIONAL child preference for the number of seconds after signature generation when the parent's signature on the DS information provided by the child will expire. The maxSigLife value applies to the RRSIG resource record (RR) over the DS RRset. See Section 3 of RFC 4034 [RFC4034] for information on the RRSIG resource record (RR).

最大署名の有効期間（maxSigLife）子によって提供さDS情報の親の署名が失効する署名生成後の秒数のオプションの子の好みです。 maxSigLife値はDS RRセット以上RRSIGリソースレコード（RR）に適用されます。 RRSIGリソースレコード（RR）の詳細は、RFC 4034 [RFC4034]のセクション3を参照。

The maximum signature lifetime is represented using the <secDNS: maxSigLife> element. The maxSigLife value MUST be represented in seconds, using an extended XML Schema "int" format. The base "int" format, which allows negative numbers, is described in Part 2 of the W3C XML Schema recommendation [W3C.REC-xmlschema-2-20010502]. This format is further restricted to enforce a minimum value of 1.

<：maxSigLife secDNS>要素最大署名寿命を用いて表されます。 maxSigLife値は、拡張されたXMLスキーマ「INT」の形式を使用して、秒単位で表現されなければなりません。負の数を可能にする塩基「INT」フォーマットは、[W3C.REC-XMLSCHEMA-2から20010502] W3C XMLスキーマ勧告の第2部に記載されています。このフォーマットは、1の最小値を強制するためにさらに制限されます。

If maxSigLife is not provided by the client, or if the server does not support the client-specified maxSigLife value, the default signature expiration policy of the server operator (as determined using an out-of-band mechanism) applies.

maxSigLifeがクライアントによって提供されていない場合、サーバはクライアント指定maxSigLife値をサポートしていない場合（アウトオブバンドメカニズムを使用して決定される）、または、サーバのオペレータのデフォルトの署名の有効期限ポリシーが適用されます。

4. DS Data Interface and Key Data Interface

4. DSデータインターフェースとキーデータインタフェース

This document describes operational scenarios in which a client can create, add, and remove Delegation Signer (DS) information or key data information for a domain name. There are two different forms of interfaces that a server can support. The first is called the "DS Data Interface", where the client is responsible for the creation of the DS information and is required to pass DS information when performing adds and removes. The server is required to pass DS information for <domain:info> responses. The second is the "Key Data Interface," where the client is responsible for passing the key data information when performing adds and removes. The server is responsible for passing key data information for <domain:info> responses.

この文書では、クライアントがドメイン名の委任署名者（DS）の情報や、キーデータ情報を作成、追加、および削除が可能な動作シナリオを説明します。サーバーがサポートできるインターフェースの2つの異なる形式があります。最初は、クライアントがDS情報の作成を担当し、追加と削除を実行するときにDS情報を渡すために必要とされる「DSデータインタフェース」、と呼ばれています。 <：情報ドメイン>応答サーバがためにDS情報を渡すために必要とされます。第二は、クライアントが実行を追加し、削除したときにキーデータ情報を渡すための責任がある「キーデータインタフェース、」です。 <：情報ドメイン>応答サーバがための鍵データ情報を渡すための責任があります。

The server MUST support one form of interface within a single command or response, where <secDNS:dsData> and <secDNS:keyData> MUST NOT be mixed, except for when <secDNS:keyData> is a child element of <secDNS:dsData> for server validation. The server MUST support the use of only one form of interface across all <secDNS:create>, <secDNS:update>, and <secDNS:infData> elements, except during a transition period, during which the server MAY support both. For instance, during a transition period, the server MAY support either the DS Data Interface or the Key Data Interface on a per-domain basis and allow the client to migrate to the target interface. The client can replace the interface used by utilizing the <secDNS:rem><secDNS: all>true</secDNS:all></secDNS:rem> element to remove all data of the old interface, and by utilizing the <secDNS:add> to add data using the new interface (<secDNS:dsData> for the DS Data Interface and <secDNS:keyData> for the Key Data Interface). The server MUST return an EPP error result code of 2306 if the server receives a command using an unsupported interface.

<：dsData secDNS>と<：dsData secDNS>：<キーデータsecDNS>は、の子要素である<secDNSキーデータ>の場合を除いて、混合されてはいけませんサーバが単一のコマンドまたは応答内のインタフェースの一の形式をサポートしなければなりませんサーバーの検証のために。 <：作成secDNS>、<secDNS：更新>、および<secDNS：infData>サーバの両方をサポートすることができるの間の遷移期間中以外の要素、サーバはすべてにわたってインタフェースの一形態のみの使用をサポートしなければなりません。たとえば、移行期間中に、サーバーはドメインごとにDSデータ・インターフェースまたはキーデータ・インタフェースのいずれかをサポートし、クライアントがターゲット・インタフェースに移行することを可能にします。 <：REM secDNS> <secDNS：すべて>真</ secDNS：すべて> </ secDNS：REM>要素古いインターフェースのすべてのデータを削除し、<secDNSを利用することによって、クライアントが利用して使用するインタフェースを置き換えることができます。（：DSデータインタフェースと<secDNSためdsData>：キーデータ・インタフェースのためのキーデータ> <secDNS）>新しいインターフェースを使用してデータを追加するために追加します。サーバがサポートされていないインタフェースを使用してコマンドを受信した場合、サーバ2306のEPPエラー結果コードを返さなければなりません。

4.1. DS Data Interface

4.1. DSデータインタフェース

The DS Data Interface relies on the use of the <secDNS:dsData> element for creates, adds, removes, and <domain:info> responses. The key data associated with the DS information MAY be provided by the client, but the server is not obligated to use the key data. The server operator MAY also issue out-of-band DNS queries to retrieve the key data from the registered domain's apex in order to evaluate the received DS information. It is RECOMMENDED that the child zone operator have this key data online in the DNS tree to allow the parent zone administrator to validate the data as necessary. The key data SHOULD have the Secure Entry Point (SEP) bit set as described in RFC 3757 [RFC3757] and RFC 4034 [RFC4034].

、作成し追加、削除、およびのために：<dsData secDNS>要素<ドメイン：インフォメーション>応答DSデータインターフェイスは、の使用に依存しています。 DSの情報に関連付けられたキーデータは、クライアントによって提供されてもよいが、サーバーは、キーデータを使用する義務を負いません。サーバーオペレータは、受信したDS情報を評価するために登録されたドメインの頂点から鍵データを取得するために、アウトオブバンドDNSクエリを発行することができます。子ゾーンのオペレータが親ゾーンの管理者が必要に応じてデータを検証できるようにするためにDNSツリーにオンラインこの鍵データを持っていることが推奨されます。鍵データは、セキュアエントリーポイント（SEP）は、RFC 3757に記載されているように[RFC3757]及びRFC 4034 [RFC4034]に設定ビット持つべきです。

The <secDNS:dsData> element contains the following child elements:

<secDNS：dsData>要素は以下の子要素が含まれています。

- A <secDNS:keyTag> element that contains a key tag value as described in Section 5.1.1 of RFC 4034 [RFC4034]. The <secDNS: keyTag> element is represented as an unsignedShort [W3C.REC-xmlschema-2-20010502].

- A <secDNS：キータグ> RFC 4034 [RFC4034]のセクション5.1.1に記載したようにキータグ値を含む要素。 <secDNS：キータグ>要素がなunsignedShort [W3C.REC-XMLSCHEMA-2から20010502]として表されます。

- A <secDNS:alg> element that contains an algorithm value as described in Section 5.1.2 of RFC 4034 [RFC4034].

- A <secDNS：ALG> RFC 4034 [RFC4034]のセクション5.1.2に記載したようにアルゴリズム値を含む要素。

- A <secDNS:digestType> element that contains a digest type value as described in Section 5.1.3 of RFC 4034 [RFC4034].

- ：RFC 4034 [RFC4034]のセクション5.1.3に記載のようにダイジェストタイプ値を含む<secDNS digestType>要素。

- A <secDNS:digest> element that contains a digest value as described in Section 5.1.4 of RFC 4034 [RFC4034]. The <secDNS: digest> element is represented as a hexBinary [W3C.REC-xmlschema-2-20010502].

- A <secDNS：ダイジェスト> RFC 4034 [RFC4034]のセクション5.1.4に記載のようにダイジェスト値を含む要素。 <secDNS：ダイジェスト>要素は、hexBinaryで[W3C.REC-XMLSCHEMA-2から20010502]として表されます。

- An OPTIONAL <secDNS:keyData> element that describes the key data used as input in the DS hash calculation for use in server validation. The <secDNS:keyData> element contains the child elements defined in Section 4.2.

- オプション：サーバーの検証に使用するためのDSハッシュ計算の入力として使用される鍵データを記述する<secDNSキーデータ>要素。 <secDNS：KEYDATA>要素は、セクション4.2で定義された子要素が含まれています。

4.2. Key Data Interface

4.2. キーデータ・インタフェース

The Key Data Interface relies on the use of the <secDNS:keyData> element for creates, adds, removes, and <domain:info> responses. The DS information is not provided by the client but is generated by the server. The attributes used for DS generation are based on server policy, where only key data is passed between the client and the server.

回答：作成し追加、削除、および<情報ドメイン>のための<KEYDATA secDNS>要素のキーデータインターフェイスは、の使用に依存しています。 DS情報は、クライアントによって提供されていないが、サーバによって生成されます。 DSの生成に使用される属性は、キーデータのみがクライアントとサーバーの間で渡されるサーバーのポリシーに基づいています。

The <secDNS:keyData> element contains the following child elements:

<secDNS：KEYDATA>要素は以下の子要素が含まれています。

- A <secDNS:flags> element that contains a flags field value as described in Section 2.1.1 of RFC 4034 [RFC4034].

- A <secDNS：フラグ> RFC 4034 [RFC4034]のセクション2.1.1に記載したようにフラグフィールド値を含む要素。

- A <secDNS:protocol> element that contains a protocol field value as described in Section 2.1.2 of RFC 4034 [RFC4034].

- A <secDNS：プロトコル> RFC 4034 [RFC4034]のセクション2.1.2に記載したように、プロトコルフィールド値を含む要素。

- A <secDNS:alg> element that contains an algorithm number field value as described in Section 2.1.3 of RFC 4034 [RFC4034].

- A <secDNS：ALG> RFC 4034 [RFC4034]のセクション2.1.3に記載したようにアルゴリズム番号フィールドの値を含む要素。

- A <secDNS:pubKey> element that contains an encoded public key field value as described in Section 2.1.4 of RFC 4034 [RFC4034]. The <secDNS:pubKey> element is represented as a base64Binary [W3C.REC-xmlschema-2-20010502] with a minimum length of 1.

- A <secDNS：pubkeyで> RFC 4034 [RFC4034]のセクション2.1.4に記載したように符号化されたパブリックキーフィールド値を含む要素。 <secDNS：pubkeyで>要素は、1の最小の長さbase64Binaryの[W3C.REC-XMLSCHEMA-2から20010502]として表されます。

4.3. Example DS Data Interface and Key Data Interface

4.3. 例DSデータインターフェースとキーデータインタフェース

Example use of the secDNS-1.1 DS Data Interface for a create:

作成のためのsecDNS-1.1 DSデータインターフェースの使用例：

<secDNS:dsData> <secDNS:keyTag>12345</secDNS:keyTag> <secDNS:alg>3</secDNS:alg> <secDNS:digestType>1</secDNS:digestType> <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest> </secDNS:dsData>

Example use of secDNS-1.1 DS Data Interface with option key data for a create:

作成のためのオプションの鍵データとsecDNS-1.1 DSデータインターフェースの使用例：

<secDNS:dsData> <secDNS:keyTag>12345</secDNS:keyTag> <secDNS:alg>3</secDNS:alg> <secDNS:digestType>1</secDNS:digestType> <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest> <secDNS:keyData> <secDNS:flags>257</secDNS:flags> <secDNS:protocol>3</secDNS:protocol> <secDNS:alg>1</secDNS:alg> <secDNS:pubKey>AQPJ////4Q==</secDNS:pubKey> </secDNS:keyData> </secDNS:dsData>

<secDNS：dsData> <secDNS：キータグ> 12345 </ secDNS：キータグ> <secDNS：ALG> 3 </ secDNS：ALG> <secDNS：digestType> 1 </ secDNS：digestType> <secDNS：ダイジェスト> 49FD46E6C4B45C55D4AC </ secDNS ：ダイジェスト> <secDNS：キーデータ> <secDNS：フラグ> 257 </ secDNS：フラグ> <secDNS：プロトコル> 3 </ secDNS：プロトコル> <secDNS：ALG> 1 </ secDNS：ALG> <secDNS：pubkeyで> AQPJ //// 4Q == </ secDNS：pubkeyで> </ secDNS：KEYDATA> </ secDNS：dsData>

Example use of the secDNS-1.1 Key Data Interface for a create:

作成のためのsecDNS-1.1キーデータ・インタフェースの使用例：

<secDNS:keyData> <secDNS:flags>257</secDNS:flags> <secDNS:protocol>3</secDNS:protocol> <secDNS:alg>1</secDNS:alg> <secDNS:pubKey>AQPJ////4Q==</secDNS:pubKey> </secDNS:keyData>

<secDNS：キーデータ> <secDNS：フラグ> 257 </ secDNS：フラグ> <secDNS：プロトコル> 3 </ secDNS：プロトコル> <secDNS：ALG> 1 </ secDNS：ALG> <secDNS：pubkeyで> AQPJ /// / 4Q == </ secDNS：pubkeyで> </ secDNS：KEYDATA>

5. EPP Command Mapping

5. EPPコマンドマッピング

A detailed description of the EPP syntax and semantics can be found in the EPP core protocol specification [RFC5730]. The command mappings described here are specifically for use in provisioning and managing DNS security extensions via EPP.

EPPの構文およびセマンティクスの詳細な説明は、EPPコアプロトコル仕様[RFC5730]に見出すことができます。ここで説明するコマンドのマッピングは、具体的EPP経由でDNSセキュリティ拡張をプロビジョニングおよび管理に使用するためのものです。

5.1. EPP Query Commands

5.1. EPPクエリコマンド

EPP provides three commands to retrieve object information: <check> to determine if an object is known to the server, <info> to retrieve detailed information associated with an object, and <transfer> to retrieve object transfer status information.

オブジェクトの転送ステータス情報を取得するために、オブジェクトに関連付けられた詳細情報を取得するには、<インフォメーション>、オブジェクトがサーバに知られているかどうかを判断するために、<チェック>、および<転送>：EPPはオブジェクト情報を取得するために3つのコマンドを提供します。

5.1.1. EPP <check> Command

5.1.1. EPP <チェック>コマンド

This extension does not add any elements to the EPP <check> command or <check> response described in the EPP domain mapping [RFC5731].

この拡張は、EPP EPPドメインマッピング[RFC5731]で説明したレスポンスをチェック<>コマンドまたは<チェック>のいずれかの要素を追加しません。

5.1.2. EPP <info> Command

5.1.2. EPP <インフォメーション>コマンド

This extension does not add any elements to the EPP <info> command described in the EPP domain mapping [RFC5731]. However, additional elements are defined for the <info> response.

この拡張は、EPPのドメインマッピング[RFC5731]で説明EPP <インフォメーション>コマンドに任意の要素を追加しません。しかし、付加的な要素は、<インフォメーション>応答のために定義されています。

When an <info> command has been processed successfully, the EPP <resData> element MUST contain child elements as described in the EPP domain mapping [RFC5731]. In addition, the EPP <extension> element SHOULD contain a child <secDNS:infData> element that identifies the extension namespace if the domain object has data associated with this extension and based on server policy. The <secDNS:infData> element contains the following child elements:

<インフォメーション>コマンドが正常に処理されたときはEPPドメインマッピング[RFC5731]で説明したように、EPP <resData>要素は、子要素を含まなければなりません。ドメインオブジェクトは、データこの拡張子に関連付けられているとサーバーのポリシーに基づいている場合は、拡張名前空間を識別します。<infData secDNS>要素また、EPP <拡張子>要素は、子を含むべきです。 <secDNS：infData>要素は以下の子要素が含まれています。

- An OPTIONAL <secDNS:maxSigLife> element that indicates a child's preference for the number of seconds after signature generation when the parent's signature on the DS information provided by the child will expire. maxSigLife is described in Section 3.3.

- オプション：子によって提供さDS情報の親の署名が期限切れになる署名生成後の秒数の子供の好みを示し、<secDNS maxSigLife>要素。 maxSigLifeは、3.3節に記述されています。

- One or more <secDNS:dsData> elements or <secDNS:keyData> elements, but not both, as defined in Section 4. The <secDNS:dsData> elements describe the Delegation Signer (DS) data provided by the client for the domain. The <secDNS:keyData> elements describe the key data provided by the client for the domain. Child elements of the <secDNS:dsData> element are described in Section 4.1. Child elements of the <secDNS:keyData> element are described in Section 4.2.

- 1つ以上の<secDNS：dsData>要素または<secDNS：キーデータ>要素、両方ではなく、セクション4で定義されるように<secDNS：dsData>要素は、ドメインのクライアントによって提供委任署名者（DS）データを記述。 <secDNS：KEYDATA>要素には、ドメインのクライアントが提供する鍵データを記述する。子要素<secDNS：dsData>要素は、セクション4.1で説明されています。子要素<secDNS：キーデータ>要素は、セクション4.2に記載されています。

Example <info> Response for a Secure Delegation Using the DS Data Interface:

例<インフォメーション> DSデータ・インタフェースを使用したセキュアな委任のための対応：

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <resData> S: <domain:infData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>example.com</domain:name> S: <domain:roid>EXAMPLE1-REP</domain:roid> S: <domain:status s="ok"/> S: <domain:registrant>jd1234</domain:registrant> S: <domain:contact type="admin">sh8013</domain:contact> S: <domain:contact type="tech">sh8013</domain:contact> S: <domain:ns> S: <domain:hostObj>ns1.example.com</domain:hostObj> S: <domain:hostObj>ns2.example.com</domain:hostObj> S: </domain:ns> S: <domain:host>ns1.example.com</domain:host> S: <domain:host>ns2.example.com</domain:host> S: <domain:clID>ClientX</domain:clID> S: <domain:crID>ClientY</domain:crID> S: <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate> S: <domain:upID>ClientX</domain:upID> S: <domain:upDate>1999-12-03T09:00:00.0Z</domain:upDate> S: <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate> S: <domain:trDate>2000-04-08T09:00:00.0Z</domain:trDate> S: <domain:authInfo> S: <domain:pw>2fooBAR</domain:pw> S: </domain:authInfo> S: </domain:infData> S: </resData> S: <extension> S: <secDNS:infData

S：の<？xml version = "1.0" エンコード= "UTF-8" スタンドアロン= "なし"？> S：<EPPののxmlns = "壷：IETF：のparams：XML：NS：EPP-1.0" S：のxmlns：XSI = "http://www.w3.org/2001/XMLSchema-instance"> S：<応答> S：<結果コード= "1000"> S：<MSG>コマンド</ MSG> S正常に完了：</結果> S：<resData> S：<ドメイン：infData S：のxmlns：ドメイン= "壷：IETF：のparams：XML：NS：ドメイン-1.0"> S：<ドメイン：名> example.com </ドメイン：名前> S：<ドメイン：ROID> EXAMPLE1-REP </ドメイン：ROID> S：<ドメイン：状態S = "OK" /> S：<ドメイン：登録者> jd1234 </ドメイン：登録者> S：<ドメイン：接触タイプ= "管理者"> sh8013 </ドメイン：連絡先> S：<ドメイン：接触タイプ= "ハイテク"> sh8013 </ドメイン：連絡先> S：<ドメイン：NS> S：<ドメイン：hostObj> ns1.example。 COM </ドメイン：hostObj> S：<ドメイン：hostObj> ns2.example.com </ドメイン：hostObj> S：</ドメイン：NS> S：<ドメイン：ホスト> ns1.example.com </ドメイン：ホスト> S：<ドメイン：ホスト> ns2.example.com </ドメイン：ホスト> S：<ドメイン：CLID> ClientX </ドメイン：CLID> S：<ドメイン：CRID> clientYプロパティ</ドメイン：CRID> S：<ドメイン：のcrdate> 1999-04-03T22：00：00.0Z </ドメイン：のcrdate> S：<ドメイン：UPID> ClientX </ D omain：UPID> S：<ドメイン：更新> 1999-12-03T09：00：00.0Z </ドメイン：更新> S：<ドメイン：EXDATE> 2005-04-03T22：00：00.0Z </ドメイン：EXDATE> S：<ドメイン：trdateは> 2000-04-08T09：00：00.0Z </ドメイン：trdateは> S：<ドメイン：AUTHINFO> S：<ドメイン：PW> 2fooBAR </ドメイン：PW> S：</ドメイン： AUTHINFO> S：</ドメイン：infData> S：</ resData> S：<拡張子> S：<secDNS：infData

S: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"> S: <secDNS:dsData> S: <secDNS:keyTag>12345</secDNS:keyTag> S: <secDNS:alg>3</secDNS:alg> S: <secDNS:digestType>1</secDNS:digestType> S: <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest> S: </secDNS:dsData> S: </secDNS:infData> S: </extension> S: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54322-XYZ</svTRID> S: </trID> S: </response> S:</epp>

S：のxmlns：secDNS = "URN：IETF：paramsは：XML：NS：secDNS-1.1"> S <secDNS：dsData> S <secDNS：キータグ> 12345 </ secDNS：キータグ> S <secDNS：ALG> 3 </ secDNS：ALG> S <secDNS：digestType> 1 </ secDNS：digestType> S <secDNS：ダイジェスト> 49FD46E6C4B45C55D4AC </ secDNS：ダイジェスト> S </ secDNS：dsData> S </ secDNS：infData > S </拡張> S <TRID> S <clTRID> ABC-12345 </ clTRID> S <svTRID> 54322-XYZ </ svTRID> S </ TRID> S </レスポンス> S： </ EPP>

Example <info> Response for a Secure Delegation Using the DS Data Interface with OPTIONAL Key Data:

例<インフォメーション>オプションキーデータとDSのデータ・インタフェースを使用したセキュアな委任のための対応：

S: <domain:authInfo> S: <domain:pw>2fooBAR</domain:pw> S: </domain:authInfo> S: </domain:infData> S: </resData> S: <extension> S: <secDNS:infData S: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"> S: <secDNS:maxSigLife>604800</secDNS:maxSigLife> S: <secDNS:dsData> S: <secDNS:keyTag>12345</secDNS:keyTag> S: <secDNS:alg>3</secDNS:alg> S: <secDNS:digestType>1</secDNS:digestType> S: <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest> S: <secDNS:keyData> S: <secDNS:flags>257</secDNS:flags> S: <secDNS:protocol>3</secDNS:protocol> S: <secDNS:alg>1</secDNS:alg> S: <secDNS:pubKey>AQPJ////4Q==</secDNS:pubKey> S: </secDNS:keyData> S: </secDNS:dsData> S: </secDNS:infData> S: </extension> S: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54322-XYZ</svTRID> S: </trID> S: </response> S:</epp>

S：<ドメイン：AUTHINFO> S：<ドメイン：PW> 2fooBAR </ドメイン：PW> S：</ドメイン：AUTHINFO> S：</ドメイン：infData> S：</ resData> S：<拡張子> S： <secDNS：infData S：のxmlns：secDNS = "URN：IETF：paramsは：XML：NS：secDNS-1.1"> S <secDNS：maxSigLife> 604800 </ secDNS：maxSigLife> S <secDNS：dsData> S < secDNS：キータグ> 12345 </ secDNS：キータグ> S <secDNS：ALG> 3 </ secDNS：ALG> S <secDNS：digestType> 1 </ secDNS：digestType> S <secDNS：ダイジェスト> 49FD46E6C4B45C55D4AC </ secDNS ：ダイジェスト> S <secDNS：キーデータ> S <secDNS：フラグ> 257 </ secDNS：フラグ> S <secDNS：プロトコル> 3 </ secDNS：プロトコル> S <secDNS：ALG> 1 </ secDNS。 ALG> S：<secDNS：pubkeyで> AQPJ //// 4Q == </ secDNS：pubkeyで> S：</ secDNS：KEYDATA> S：</ secDNS：dsData> S：</ secDNS：infData> S：< /拡張> S <TRID> S <clTRID> ABC-12345 </ clTRID> S <svTRID> 54322-XYZ </ svTRID> S </ TRID> S </レスポンス> S </ EPP>

Example <info> Response for a Secure Delegation Using the Key Data Interface:

例<インフォメーション>キーデータ・インタフェースを使用したセキュアな委任のための対応：

S: <domain:contact type="tech">sh8013</domain:contact> S: <domain:ns> S: <domain:hostObj>ns1.example.com</domain:hostObj> S: <domain:hostObj>ns2.example.com</domain:hostObj> S: </domain:ns> S: <domain:host>ns1.example.com</domain:host> S: <domain:host>ns2.example.com</domain:host> S: <domain:clID>ClientX</domain:clID> S: <domain:crID>ClientY</domain:crID> S: <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate> S: <domain:upID>ClientX</domain:upID> S: <domain:upDate>1999-12-03T09:00:00.0Z</domain:upDate> S: <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate> S: <domain:trDate>2000-04-08T09:00:00.0Z</domain:trDate> S: <domain:authInfo> S: <domain:pw>2fooBAR</domain:pw> S: </domain:authInfo> S: </domain:infData> S: </resData> S: <extension> S: <secDNS:infData S: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"> S: <secDNS:keyData> S: <secDNS:flags>257</secDNS:flags> S: <secDNS:protocol>3</secDNS:protocol> S: <secDNS:alg>1</secDNS:alg> S: <secDNS:pubKey>AQPJ////4Q==</secDNS:pubKey> S: </secDNS:keyData> S: </secDNS:infData> S: </extension> S: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54322-XYZ</svTRID> S: </trID> S: </response> S:</epp>

S：<ドメイン：接触タイプ= "ハイテク"> sh8013 </ドメイン：連絡先> S：<ドメイン：NS> S：<ドメイン：hostObj> ns1.example.com </ドメイン：hostObj> S：<ドメイン：hostObj > ns2.example.com </ドメイン：hostObj> S：</ドメイン：NS> S：<ドメイン：ホスト> ns1.example.com </ドメイン：ホスト> S：<ドメイン：ホスト> ns2.example.com </ドメイン：ホスト> S <ドメイン：CLID> ClientX </ドメイン：CLID> S <ドメイン：CRID> clientYプロパティ</ドメイン：CRID> S <ドメイン：のcrdate> 1999-04-03T22：00：00.0 Z </ドメイン：のcrdate> S <ドメイン：UPID> ClientX </ドメイン：UPID> S <ドメイン：更新> 1999-12-03T09：00：00.0Z </ドメイン：更新> S <ドメイン：EXDATE > 2005-04-03T22：00：00.0Z </ドメイン：EXDATE> S <ドメイン：trdateは> 2000-04-08T09：00：00.0Z </ドメイン：trdateは> S <ドメイン：AUTHINFO> S <ドメイン：PW> 2fooBAR </ドメイン：PW> S </ドメイン：AUTHINFO> S </ドメイン：infData> S </ resData> S <拡張> S <secDNS：infData S：のxmlns：secDNS = "URN：IETF：paramsは：XML：NS：secDNS-1.1"> S <secDNS：キーデータ> S <secDNS：フラグ> 257 </ secDNS：フラグ> S <secDNS：プロトコル> 3 </ secDNS：プロトコル> S <secDNS：ALG> 1 </ secDNS：ALG> S <secDNS：pubkeyで> AQPJ //// 4Q == </ secDNS：pubkeyで> S < / secDNS：キーデータ> S </ secDNS：infData> S </拡張> S <TRID> S <clTRID> ABC-12345 </ clTRID> S <svTRID> 54322-XYZ </ svTRID> S： </ TRID> S：</レスポンス> S：</ EPP>

An EPP error response MUST be returned if an <info> command cannot be processed for any reason.

<インフォメーション>コマンドが何らかの理由で処理できない場合はEPPのエラー応答が返されなければなりません。

5.1.3. EPP <transfer> Command

5.1.3. EPP <転送>コマンド

This extension does not add any elements to the EPP <transfer> command or <transfer> response described in the EPP domain mapping [RFC5731].

この拡張は、EPP <転写>コマンドまたはEPPドメインマッピング[RFC5731]に記載の<転写>応答の任意の要素を追加しません。

5.2. EPP Transform Commands

5.2. EPPは、コマンド変換します

EPP provides five commands to transform objects: <create> to create an instance of an object, <delete> to delete an instance of an object, <renew> to extend the validity period of an object, <transfer> to manage object sponsorship changes, and <update> to change information associated with an object.

EPPは、オブジェクトを変換するための5つのコマンドが用意されていますオブジェクトの後援の変更を管理するために、<転送>、オブジェクトの有効期間を延長するために、<更新>、オブジェクトのインスタンスを削除するには、<削除>、オブジェクトのインスタンスを作成するには、<作成します> 、および<更新>オブジェクトに関連付けられた情報を変更します。

5.2.1. EPP <create> Command

5.2.1. EPP <作成>コマンド

This extension defines additional elements for the EPP <create> command described in the EPP domain mapping [RFC5731]. No additional elements are defined for the EPP <create> response.

この拡張は、EPPドメインマッピング[RFC5731]で説明されている追加のEPPための要素<作成>コマンドを定義します。追加の要素がEPP <作成>応答のために定義されていません。

The EPP <create> command provides a transform operation that allows a client to create a domain object. In addition to the EPP command elements described in the EPP domain mapping [RFC5731], the command MUST contain an <extension> element, and the <extension> element MUST contain a child <secDNS:create> element that identifies the extension namespace if the client wants to associate data defined in this extension to the domain object. The <secDNS:create> element contains the following child elements:

EPP <作成>コマンドは、クライアントがドメインオブジェクトを作成することを可能にする変換操作を提供します。 EPPドメインのマッピングに記載のEPPコマンド要素[RFC5731]に加えて、コマンドは、<拡張>要素を含まなければなりません、そして、<拡張>要素は、子<secDNS：作成>含まなければならない場合に拡張名前空間を識別する要素をクライアントは、ドメインオブジェクトに、この拡張で定義されたデータを関連させたいです。 <secDNS：作成>要素は以下の子要素が含まれています。

- オプション：子によって提供さDS情報の親の署名が期限切れになる署名生成後の秒数の子供の好みを示し、<secDNS maxSigLife>要素。 maxSigLifeは、3.3節に記述されています。サーバがサポートしていない場合、<secDNS：maxSigLife>要素を、2102エラーが返されなければなりません。

- Zero or more <secDNS:dsData> elements or <secDNS:keyData> elements, but not both, as defined in Section 4. Child elements of the <secDNS:dsData> element are described in Section 4.1. Child elements of the <secDNS:keyData> element are described in Section 4.2.

- ゼロ以上の<secDNS：dsData>要素または<secDNS：キーデータ>要素、両方ではないが、セクションで定義されるように4.子要素<secDNS：dsData>要素は、セクション4.1に記載されています。子要素<secDNS：キーデータ>要素は、セクション4.2に記載されています。

Example <create> Command for a Secure Delegation Using the DS Data Interface:

例は、DSデータ・インタフェースを使用したセキュアな委任のためのコマンドを、<作成します>：

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> C: <command> C: <create> C: <domain:create C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>example.com</domain:name> C: <domain:period unit="y">2</domain:period> C: <domain:ns> C: <domain:hostObj>ns1.example.com</domain:hostObj> C: <domain:hostObj>ns2.example.com</domain:hostObj> C: </domain:ns> C: <domain:registrant>jd1234</domain:registrant> C: <domain:contact type="admin">sh8013</domain:contact> C: <domain:contact type="tech">sh8013</domain:contact> C: <domain:authInfo> C: <domain:pw>2fooBAR</domain:pw> C: </domain:authInfo> C: </domain:create> C: </create> C: <extension> C: <secDNS:create C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"> C: <secDNS:maxSigLife>604800</secDNS:maxSigLife> C: <secDNS:dsData> C: <secDNS:keyTag>12345</secDNS:keyTag> C: <secDNS:alg>3</secDNS:alg> C: <secDNS:digestType>1</secDNS:digestType> C: <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest> C: </secDNS:dsData> C: </secDNS:create> C: </extension> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp>

C：の<？xml version = "1.0" エンコード= "UTF-8" スタンドアロン= "NO"？> C <EPP用のxmlns = "URN：IETF：paramsは：XML：NS：EPP-1.0" C：のxmlns：XSI = "http://www.w3.org/2001/XMLSchema-instance"> C：<コマンド> C：<> C作成します。<ドメイン：Cを作成します。のxmlns：ドメイン= "壷：IETF：のparams：XMLを： NS：ドメイン-1.0 "> C <ドメイン：名> example.com </ドメイン：名> C <ドメイン：期間単位=" Y "> 2 </ドメイン：期間> C <ドメイン：NS> C <ドメイン：hostObj> ns1.example.com </ドメイン：hostObj> C <ドメイン：hostObj> ns2.example.com </ドメイン：hostObj> C </ドメイン：NS> C <ドメイン：登録> jd1234 </ドメイン：登録者> C：<ドメイン：接触タイプ= "管理者"> sh8013 </ドメイン：連絡先> C：<ドメイン：接触タイプ= "ハイテク"> sh8013 </ドメイン：連絡先> C：<ドメイン： AUTHINFO> C：<ドメイン：PW> 2fooBAR </ドメイン：PW> C：</ドメイン：AUTHINFO> C：</ドメイン：> Cを作成します。</作成> C：<拡張子> C：<secDNS：Cを作成します：のxmlns：secDNS = "URN：IETF：paramsは：XML：NS：secDNS-1.1"> C <secDNS：maxSigLife> 604800 </ secDNS：maxSigLife> C <secDNS：dsData> C <secDNS：キータグ> 12345 </ secDNS：キータグ> C <secDNS：ALG> 3 </ secDNS：ALG> C <secDNS：digestType> 1 </ SE CDNS：digestType> C <secDNS：ダイジェスト> 49FD46E6C4B45C55D4AC </ secDNS：ダイジェスト> C </ secDNS：dsData> C </ secDNS：作成> C </拡張> C <clTRID> ABC-12345 </ clTRID> C：</コマンド> C：</ EPP>

Example <create> Command for a Secure Delegation Using the DS Data Interface with OPTIONAL Key Data:

例では、オプションのキーデータとDSのデータ・インタフェースを使用したセキュアな委任のためのコマンドを、<作成します>：

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> C: <command> C: <create> C: <domain:create C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>example.com</domain:name> C: <domain:period unit="y">2</domain:period> C: <domain:ns> C: <domain:hostObj>ns1.example.com</domain:hostObj> C: <domain:hostObj>ns2.example.com</domain:hostObj> C: </domain:ns> C: <domain:registrant>jd1234</domain:registrant> C: <domain:contact type="admin">sh8013</domain:contact> C: <domain:contact type="tech">sh8013</domain:contact> C: <domain:authInfo> C: <domain:pw>2fooBAR</domain:pw> C: </domain:authInfo> C: </domain:create> C: </create> C: <extension> C: <secDNS:create C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"> C: <secDNS:maxSigLife>604800</secDNS:maxSigLife> C: <secDNS:dsData> C: <secDNS:keyTag>12345</secDNS:keyTag> C: <secDNS:alg>3</secDNS:alg> C: <secDNS:digestType>1</secDNS:digestType> C: <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest> C: <secDNS:keyData> C: <secDNS:flags>257</secDNS:flags> C: <secDNS:protocol>3</secDNS:protocol> C: <secDNS:alg>1</secDNS:alg> C: <secDNS:pubKey>AQPJ////4Q==</secDNS:pubKey> C: </secDNS:keyData> C: </secDNS:dsData> C: </secDNS:create> C: </extension> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp>

C：の<？xml version = "1.0" エンコード= "UTF-8" スタンドアロン= "NO"？> C <EPP用のxmlns = "URN：IETF：paramsは：XML：NS：EPP-1.0" C：のxmlns：XSI = "http://www.w3.org/2001/XMLSchema-instance"> C：<コマンド> C：<> C作成します。<ドメイン：Cを作成します。のxmlns：ドメイン= "壷：IETF：のparams：XMLを： NS：ドメイン-1.0 "> C <ドメイン：名> example.com </ドメイン：名> C <ドメイン：期間単位=" Y "> 2 </ドメイン：期間> C <ドメイン：NS> C <ドメイン：hostObj> ns1.example.com </ドメイン：hostObj> C <ドメイン：hostObj> ns2.example.com </ドメイン：hostObj> C </ドメイン：NS> C <ドメイン：登録> jd1234 </ドメイン：登録者> C：<ドメイン：接触タイプ= "管理者"> sh8013 </ドメイン：連絡先> C：<ドメイン：接触タイプ= "ハイテク"> sh8013 </ドメイン：連絡先> C：<ドメイン： AUTHINFO> C：<ドメイン：PW> 2fooBAR </ドメイン：PW> C：</ドメイン：AUTHINFO> C：</ドメイン：> Cを作成します。</作成> C：<拡張子> C：<secDNS：Cを作成します：のxmlns：secDNS = "URN：IETF：paramsは：XML：NS：secDNS-1.1"> C <secDNS：maxSigLife> 604800 </ secDNS：maxSigLife> C <secDNS：dsData> C <secDNS：キータグ> 12345 </ secDNS：キータグ> C <secDNS：ALG> 3 </ secDNS：ALG> C <secDNS：digestType> 1 </ SE CDNS：digestType> C <secDNS：> 49FD46E6C4B45C55D4AC </ secDNSダイジェスト：ダイジェスト> C <secDNS：キーデータ> C <secDNS：フラグ> 257 </ secDNS：フラグ> C <secDNS：プロトコル> 3 </ secDNS ：プロトコル> C <secDNS：ALG> 1 </ secDNS：ALG> C <secDNS：pubkeyで> AQPJ //// 4Q == </ secDNS：pubkeyで> C </ secDNS：キーデータ> C </ secDNS：dsData> C </ secDNS：作成> C </拡張> C <clTRID> ABC-12345 </ clTRID> C </コマンド> C </ EPP>

Example <create> Command for a Secure Delegation Using the Key Data Interface:

例は、キーデータ・インタフェースを使用したセキュアな委任のためのコマンドを、<作成します>：

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> C: <command> C: <create> C: <domain:create C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>example.com</domain:name> C: <domain:period unit="y">2</domain:period> C: <domain:ns> C: <domain:hostObj>ns1.example.com</domain:hostObj> C: <domain:hostObj>ns2.example.com</domain:hostObj> C: </domain:ns> C: <domain:registrant>jd1234</domain:registrant> C: <domain:contact type="admin">sh8013</domain:contact> C: <domain:contact type="tech">sh8013</domain:contact> C: <domain:authInfo> C: <domain:pw>2fooBAR</domain:pw> C: </domain:authInfo> C: </domain:create> C: </create> C: <extension> C: <secDNS:create C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"> C: <secDNS:keyData> C: <secDNS:flags>257</secDNS:flags> C: <secDNS:protocol>3</secDNS:protocol> C: <secDNS:alg>1</secDNS:alg> C: <secDNS:pubKey>AQPJ////4Q==</secDNS:pubKey> C: </secDNS:keyData> C: </secDNS:create> C: </extension> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp>

C：の<？xml version = "1.0" エンコード= "UTF-8" スタンドアロン= "NO"？> C <EPP用のxmlns = "URN：IETF：paramsは：XML：NS：EPP-1.0" C：のxmlns：XSI = "http://www.w3.org/2001/XMLSchema-instance"> C：<コマンド> C：<> C作成します。<ドメイン：Cを作成します。のxmlns：ドメイン= "壷：IETF：のparams：XMLを： NS：ドメイン-1.0 "> C <ドメイン：名> example.com </ドメイン：名> C <ドメイン：期間単位=" Y "> 2 </ドメイン：期間> C <ドメイン：NS> C <ドメイン：hostObj> ns1.example.com </ドメイン：hostObj> C <ドメイン：hostObj> ns2.example.com </ドメイン：hostObj> C </ドメイン：NS> C <ドメイン：登録> jd1234 </ドメイン：登録者> C：<ドメイン：接触タイプ= "管理者"> sh8013 </ドメイン：連絡先> C：<ドメイン：接触タイプ= "ハイテク"> sh8013 </ドメイン：連絡先> C：<ドメイン： AUTHINFO> C：<ドメイン：PW> 2fooBAR </ドメイン：PW> C：</ドメイン：AUTHINFO> C：</ドメイン：> Cを作成します。</作成> C：<拡張子> C：<secDNS：Cを作成します：のxmlns：secDNS = "URN：IETF：paramsは：XML：NS：secDNS-1.1"> C <secDNS：キーデータ> C <secDNS：フラグ> 257 </ secDNS：フラグ> C <secDNS：プロトコル> 3 </ secDNS：プロトコル> C <secDNS：ALG> 1 </ secDNS：ALG> C <secDNS：pubkeyで> AQPJ //// 4Q == </ secDNS。 pubkeyで> C </ secDNS：キーデータ> C </ secDNS：作成> C </拡張> C <clTRID> ABC-12345 </ clTRID> C </コマンド> C </ EPP>

When a <create> command has been processed successfully, the EPP response is as described in the EPP domain mapping [RFC5731].

<作成>コマンドが正常に処理された場合EPPドメインマッピング[RFC5731]に記載されているように、EPP応答です。

5.2.2. EPP <delete> Command

5.2.2. EPP <削除>コマンド

This extension does not add any elements to the EPP <delete> command or <delete> response described in the EPP domain mapping [RFC5731].

この拡張は、EPP EPPドメインマッピング[RFC5731]で説明した応答を、<削除>コマンドまたは<削除>に任意の要素を追加しません。

5.2.3. EPP <renew> Command

5.2.3. EPP <更新>コマンド

This extension does not add any elements to the EPP <renew> command or <renew> response described in the EPP domain mapping [RFC5731].

この拡張は、EPP EPPドメインマッピング[RFC5731]で説明した応答を、<更新>コマンドまたは<更新>に任意の要素を追加しません。

5.2.4. EPP <transfer> Command

5.2.4. EPP <転送>コマンド

This extension does not add any elements to the EPP <transfer> command or <transfer> response described in the EPP domain mapping [RFC5731].

この拡張は、EPP <転写>コマンドまたはEPPドメインマッピング[RFC5731]に記載の<転写>応答の任意の要素を追加しません。

5.2.5. EPP <update> Command

5.2.5. EPP <アップデート>コマンド

This extension defines additional elements for the EPP <update> command described in the EPP domain mapping [RFC5731]. No additional elements are defined for the EPP <update> response.

この拡張は、EPP EPPドメインマッピング[RFC5731]に記載の<更新>コマンドの追加の要素を定義します。追加の要素がEPP <アップデート>応答のために定義されていません。

The EPP <update> command provides a transform operation that allows a client to modify the attributes of a domain object. In addition to the EPP command elements described in the EPP domain mapping, the command MUST contain an <extension> element, and the <extension> element MUST contain a child <secDNS:update> element that identifies the extension namespace if the client wants to update the domain object with data defined in this extension. The <secDNS:update> element contains a <secDNS:add> element to add security information to a delegation, a <secDNS:rem> element to remove security information from a delegation, or a <secDNS:chg> element to change existing security information. At least one <secDNS:add>, <secDNS: rem>, or <secDNS:chg> element MUST be provided. The order of the <secDNS:rem> and <secDNS:add> elements is significant, where the server MUST first remove the existing elements prior to adding the new elements.

EPP <アップデート>コマンドは、クライアントがドメインオブジェクトの属性を変更することを可能にする変換操作を提供します。 EPPドメインマッピングで説明EPPコマンドの要素に加えて、このコマンドは、<拡張子>要素を含まなければならない、と<拡張子>要素は、子が含まれなければならない：クライアントがしたい場合は、拡張名前空間を識別し、<secDNS更新>要素をこの拡張で定義されたデータを持つドメインオブジェクトを更新します。委任にセキュリティ情報を追加する：<追加secDNS>要素、：代表団からのセキュリティ情報を削除するには、<secDNSレム>要素、または：既存のセキュリティを変更するには、<secDNS CHG>要素<secDNS更新>要素が含まれています情報。少なくとも一つの<secDNS：追加>、<secDNS：REM>、または<secDNS：CHG>要素が提供されなければなりません。 <：REM secDNS>と<secDNS：追加>のため、サーバーが最初の前に新しい要素を追加するには、既存の要素を削除しなければならないところの要素は、重要です。

The <secDNS:update> element also contains an OPTIONAL "urgent" attribute that a client can use to ask the server operator to complete and implement the update request with high priority. This attribute accepts boolean values as described in Section 3.2; the default value is boolean false. "High priority" is relative to standard server operator policies that are determined using an out-of-band mechanism. A server MUST return an EPP error result code of 2102 if the "urgent" attribute is specified with a value of boolean true and the server does not support it. A server MUST return an EPP error result code of 2306 if the server supports the "urgent" attribute and an urgent update (noted with an "urgent" attribute value of boolean true) cannot be completed with high priority.

<secDNS：更新>要素には、オプションの「緊急」は、クライアントが完了し、優先度の高い更新要求を実現するために、サーバのオペレータに依頼するために使用できる属性が含まれています。この属性は、3.2節で説明したように、ブール値を受け入れます。デフォルト値はfalseブール値です。「高優先度」は、アウトオブバンドメカニズムを使用して決定されている標準的なサーバオペレータポリシーに対するものです。「緊急」属性をtrueブール値で指定され、サーバはそれをサポートしていない場合、サーバーは2102のEPPエラー結果コードを返さなければなりません。サーバは、サーバが「緊急」の属性と（真のブールの「緊急」属性値で示される）緊急の更新をサポートしている場合、2306のEPPエラー結果コードを返さなければならない高い優先度で完了することができません。

The <secDNS:update> element contains the following child elements:

<secDNS：更新>要素は以下の子要素が含まれています。

- An OPTIONAL <secDNS:rem> element that contains a <secDNS:all> element, or one or more <secDNS:dsData> or <secDNS:keyData> elements that are used to remove security data from a delegation.

- オプションの要素、または1つ以上の<secDNS：dsData>または：代表団からのセキュリティデータを削除するために使用されている<secDNS KEYDATA>要素：<すべてのsecDNS>を含んでいる<secDNSレム>要素。

The <secDNS:all> element is used to remove all DS and key data with a value of boolean true. A value of boolean false will do nothing. Removing all DS information can remove the ability of the parent to secure the delegation to the child zone.

<secDNS：すべて>要素はブール真の値を持つすべてのDSや鍵データを削除するために使用されます。ブール値がfalseの場合、何もしません。すべてのDS情報を削除すると、子ゾーンへの委任を確保するために、親の能力を削除することができます。

The <secDNS:dsData> element is part of the DS Data Interface and is used to uniquely define the DS record to be removed, by using all four elements -- <secDNS:keyTag>, <secDNS:alg>, <secDNS: digestType>, and <secDNS:digest> -- that are guaranteed to be unique.

<secDNS：dsData>要素は、DSデータ・インタフェースの一部であり、すべての4つの要素を使用することによって、除去する一意DSのレコードを定義するために使用されている - <secDNS：キータグ>、<secDNS：ALGを>、<secDNSを：digestType >、そして<secDNS：>ダイジェスト - ユニークであることが保証されています。

The <secDNS:keyData> element is part of the Key Data Interface and is used to uniquely define the key data to be removed, by using all four elements -- <secDNS:flags>, <secDNS:protocol>, <secDNS: alg>, and <secDNS:pubKey> -- that are guaranteed to be unique. There can be more than one DS record created for each key, so removing a key could remove more than one DS record.

<secDNS：キーデータ>要素は、主データ・インタフェースの一部であり、一意にすべての4つの要素を用いて、除去すべき鍵データを定義するために使用される - <secDNS：フラグ>、<secDNS：プロトコル>、<secDNS：ALG >、そして<secDNS：pubkeyで> - ユニークであることが保証されています。これ以上のDSレコードを削除することができ、キーを削除し、各キーのために作成された複数のDSレコードが存在する場合があります。

- An OPTIONAL <secDNS:add> element that is used to add security information to an existing set. The <secDNS:add> element MUST contain one or more <secDNS:dsData> or <secDNS:keyData> elements. Child elements of the <secDNS:dsData> element are described in Section 4.1. Child elements of the <secDNS:keyData> element are described in Section 4.2.

- オプション：既存のセットにセキュリティ情報を追加するために使用される<secDNS追加>要素。 <secDNS：追加> <：dsData secDNS>または<secDNS：KEYDATA>要素の要素が1つ以上を含まなければなりません。子要素<secDNS：dsData>要素は、セクション4.1で説明されています。子要素<secDNS：キーデータ>要素は、セクション4.2に記載されています。

- An OPTIONAL <secDNS:chg> element that contains security information to be changed. A <secDNS:chg> element contains the following child elements:

- オプションの<secDNS：CHG>変更するセキュリティ情報を含む要素。 <secDNS：CHG>要素は、次の子要素が含まれています。

Example <update> Command, Adding and Removing DS Data Using the DS Data Interface:

例<更新>コマンド、DSデータ・インタフェースを使用したDSデータの追加と削除：

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> C: <command> C: <update> C: <domain:update C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>example.com</domain:name> C: </domain:update> C: </update> C: <extension> C: <secDNS:update C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"> C: <secDNS:rem> C: <secDNS:dsData> C: <secDNS:keyTag>12345</secDNS:keyTag> C: <secDNS:alg>3</secDNS:alg> C: <secDNS:digestType>1</secDNS:digestType> C: <secDNS:digest>38EC35D5B3A34B33C99B</secDNS:digest> C: </secDNS:dsData> C: </secDNS:rem> C: <secDNS:add> C: <secDNS:dsData> C: <secDNS:keyTag>12346</secDNS:keyTag> C: <secDNS:alg>3</secDNS:alg> C: <secDNS:digestType>1</secDNS:digestType> C: <secDNS:digest>38EC35D5B3A34B44C39B</secDNS:digest> C: </secDNS:dsData> C: </secDNS:add> C: </secDNS:update> C: </extension> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp>

Example <update> Command, Updating the maxSigLife:

例<更新>コマンド、maxSigLifeの更新：

Example <update> Command, Adding and Removing Key Data Using the Key Data Interface, and Setting maxSigLife:

例<更新>コマンド、キーデータ・インタフェースを使用して、maxSigLifeを設定するキーデータの追加と削除：

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> C: <command> C: <update> C: <domain:update C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>example.com</domain:name> C: </domain:update> C: </update> C: <extension> C: <secDNS:update C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"> C: <secDNS:rem> C: <secDNS:keyData> C: <secDNS:flags>257</secDNS:flags> C: <secDNS:protocol>3</secDNS:protocol> C: <secDNS:alg>1</secDNS:alg> C: <secDNS:pubKey>AQPJ////4QQQ</secDNS:pubKey> C: </secDNS:keyData> C: </secDNS:rem> C: <secDNS:add> C: <secDNS:keyData> C: <secDNS:flags>257</secDNS:flags> C: <secDNS:protocol>3</secDNS:protocol> C: <secDNS:alg>1</secDNS:alg> C: <secDNS:pubKey>AQPJ////4Q==</secDNS:pubKey> C: </secDNS:keyData> C: </secDNS:add> C: <secDNS:chg> C: <secDNS:maxSigLife>605900</secDNS:maxSigLife> C: </secDNS:chg> C: </secDNS:update> C: </extension> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp>

C：の<？xml version = "1.0" エンコード= "UTF-8" スタンドアロン= "NO"？> C <EPP用のxmlns = "URN：IETF：paramsは：XML：NS：EPP-1.0" C：のxmlns：XSI = "http://www.w3.org/2001/XMLSchema-instance"> C <コマンド> C <更新> C <ドメイン：更新C：のxmlns：ドメイン= "URN：IETF：paramsは：XML： NS：ドメイン-1.0" > C：<ドメイン：名> example.com </ドメイン：名> C：</ドメイン：更新> C：</更新> C：<拡張子> C：<secDNS：更新C： xmlns：secDNS = "URN：IETF：paramsは：XML：NS：secDNS-1.1"> C <secDNS：REM> C <secDNS：キーデータ> C <secDNS：フラグ> 257 </ secDNS：フラグ> C： <secDNS：プロトコル> 3 </ secDNS：プロトコル> C <secDNS：ALG> 1 </ secDNS：ALG> C <secDNS：pubkeyで> AQPJ //// 4QQQ </ secDNS：pubkeyで> C </ secDNS ：キーデータ> C </ secDNS：REM> C <secDNS：追加> C <secDNS：キーデータ> C <secDNS：フラグ> 257 </ secDNS：フラグ> C <secDNS：プロトコル> 3 </ secDNS ：プロトコル> C <secDNS：ALG> 1 </ secDNS：ALG> C <secDNS：pubkeyで> AQPJ //// 4Q == </ secDNS：pubkeyで> C </ secDNS：キーデータ> C </ secDNS：追加> C <secDNS：CHG> C <secDNS：maxSigLife> 605900 </ secDNS：maxSigLife> C </ secDNS：CHG> C </ secDNS：更新> C </拡張> C < clTRID > ABC-12345 </ clTRID> C </コマンド> C </ EPP>

Example <update> Command, Removing DS Data with <secDNS:dsData> Using the DS Data Interface:

例<更新>コマンド、とDSデータの削除<secDNS：dsData> DSデータ・インタフェースを使用しました：

Example <update> Command, Removing all DS and Key Data Using <secDNS:rem> with <secDNS:all>:

例<更新>コマンド、使用しているすべてのDSと鍵データを削除：<：すべてsecDNS>と<secDNS REM>を：

Example Urgent <update> Command, Replacing all DS Data Using the DS Data Interface:

例緊急<更新>コマンド、DSデータ・インタフェースを使用したすべてのDSのデータの交換：

When an extended <update> command has been processed successfully, the EPP response is as described in the EPP domain mapping [RFC5731].

拡張<更新>コマンドが正常に処理された場合EPPドメインマッピング[RFC5731]に記載されているように、EPP応答です。

6. Formal Syntax

6.正式な構文

An EPP object mapping is specified in XML Schema notation. The formal syntax presented here is a complete schema representation of the object mapping suitable for automated validation of EPP XML instances. The BEGIN and END tags are not part of the schema; they are used to note the beginning and ending of the schema for URI registration purposes.

EPPオブジェクトマッピングは、XMLスキーマ表記で指定されています。ここで紹介する正式な構文は、EPPのXMLインスタンスの自動化された検証に適したオブジェクト・マッピングの完全なスキーマ表現です。 BEGINとENDタグは、スキーマの一部ではありません。彼らは、URIの登録目的のためのスキーマの始まりと終わりを注意するために使用されています。

著作権（C）2010 IETF信託コードの作者として特定の人物。全著作権所有。

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

再配布および、改変してまたは改変せずに、ソースおよびバイナリ形式で使用し、以下の条件が満たされていることを許可されます。

- Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

- ソースコードの再配布は、上記の著作権表示、条件のリストおよび以下の免責事項を保持しなければなりません。

- Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

- バイナリ形式で再配布は、上記の著作権表示、条件のリストおよび文書および/または分布を備えた他の材料で次の免責事項を再現しなければなりません。

- Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission.

- インターネット協会、IETFやIETFトラストの名称、また具体的な貢献者の名前はどちらも、特定の書面による事前の許可なしに、本ソフトウェアから派生した製品を推薦または促進するために使用することができます。

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

「現状のまま」、いかなる明示または黙示の保証、含むがこれらに限定されないが、特定目的に対する適合性の黙示の保証は放棄さ本ソフトウェアは著作権所有者によって提供されます。 NO EVENTの著作権所有者または貢献者は、以下を含むいかなる直接的、間接的、偶発的、特別、懲罰的、または間接的損害（についても責任を負いあってもよいが、代替商品またはサービスの調達、これらに限定されないものとし、使用、データ、または利益の損失; OR事業の中断）原因で生じた（そのような損害の可能性について知らされていた場合でも、一切このソフトウェアの使用の損失、データの損失）過失またはその他を含む責任、それが契約、厳格な責任、不法行為のどのような理論の上で。

BEGIN <?xml version="1.0" encoding="UTF-8"?> <schema targetNamespace="urn:ietf:params:xml:ns:secDNS-1.1" xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1" xmlns="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">

BEGINの<？xml version = "1.0" エンコード= "UTF-8"？> <スキーマのtargetNamespace = "壷：IETF：のparams：XML：NS：secDNS-1.1" のxmlns：secDNS = "壷：IETF：のparams：XML： NS：secDNS-1.1" のxmlns = "http://www.w3.org/2001/XMLSchema" のelementFormDefault = "資格">

<annotation> <documentation> Extensible Provisioning Protocol v1.0 domain name extension schema for provisioning DNS security (DNSSEC) extensions. </documentation> </annotation>

<注釈> <ドキュメンテーション> DNSセキュリティ（DNSSEC）の拡張機能をプロビジョニングするための拡張可能なプロビジョニングプロトコルv1.0のドメイン名の拡張子スキーマ。 </ドキュメンテーション> </注釈>

<！ - EPPコマンドで見つかった子要素。 - >

<要素名= "作成" タイプ= "secDNS：dsOrKeyType" /> <要素名= "更新" タイプ= "secDNS：UPDATETYPE" />

<complexType name="dsOrKeyType"> <sequence> <element name="maxSigLife" type="secDNS:maxSigLifeType" minOccurs="0"/> <choice> <element name="dsData" type="secDNS:dsDataType" maxOccurs="unbounded"/> <element name="keyData" type="secDNS:keyDataType" maxOccurs="unbounded"/> </choice> </sequence> </complexType>

<！ - dsDataまたはキーデータインタフェースのいずれかをサポートしている子要素。 - > <complexTypeの名= "dsOrKeyType"> <シーケンス> <要素名= "maxSigLife" タイプ= "secDNS：maxSigLifeType" のminOccurs = "0" /> <選択> <要素名= "dsData" タイプ= "secDNS： dsDataType」のmaxOccurs = "無制限" /> <要素名= "KEYDATA" タイプ= "secDNS：keyDataType" のmaxOccurs = "無制限" /> </選択> </シーケンス> </ complexTypeの>

<simpleType name="maxSigLifeType"> <restriction base="int"> <minInclusive value="1"/> </restriction> </simpleType>

<！ - 最大署名寿命（maxSigLife）のための定義 - > <単純名= "maxSigLifeType"> <制限塩基= "INT"> <のminInclusive値= "1" /> </制限> </ simpleTypeの>

<complexType name="dsDataType"> <sequence> <element name="keyTag" type="unsignedShort"/> <element name="alg" type="unsignedByte"/> <element name="digestType" type="unsignedByte"/> <element name="digest" type="hexBinary"/> <element name="keyData" type="secDNS:keyDataType" minOccurs="0"/> </sequence> </complexType>

<！ - dsDataの子要素はdsDataインタフェースに使用する - > <complexTypeの名前= "dsDataType"> <シーケンス> <要素名= "キータグ" タイプ= "なunsignedShort" /> <要素名= "ALG" タイプ=」なunsignedByteは "/> <要素名=" digestType "タイプ= "なunsignedByte"/> <要素名= "ダイジェスト" タイプ= "のhexBinary"/> <要素名= "キーデータ" タイプ= "secDNS：keyDataType" のminOccurs =" 0 「/> </シーケンス> </ complexTypeの>

<complexType name="keyDataType">

<！ - キーデータの子要素は、キーデータインターフェイスのために必要に応じてdsDataインターフェースで使用 - > <complexTypeの名前=「keyDataType」>

<シーケンス> <要素名= "フラグ" タイプ= "なunsignedShort" /> <要素名= "プロトコル" タイプ= "なunsignedByte" /> <要素名= "ALG" タイプ= "なunsignedByte" /> <要素名=」 pubkeyで」タイプ= "secDNS：キータイプ" /> </シーケンス> </ complexTypeの>

<simpleType name="keyType"> <restriction base="base64Binary"> <minLength value="1"/> </restriction> </simpleType>

<！ - 公開鍵の定義 - > <単純名= "キータイプ"> <制限ベース= "base64Binaryの"> <はminLength値= "1" /> </制限> </単純>

<complexType name="updateType"> <sequence> <element name="rem" type="secDNS:remType" minOccurs="0"/> <element name="add" type="secDNS:dsOrKeyType" minOccurs="0"/> <element name="chg" type="secDNS:chgType" minOccurs="0"/> </sequence> <attribute name="urgent" type="boolean" default="false"/> </complexType>

<！ - <更新>要素の子要素。 - > <complexTypeの名= "UPDATETYPE"> <シーケンス> <要素名= "REM" タイプ= "secDNS：remType" のminOccurs = "0" /> <要素名= "追加" タイプ= "secDNS：dsOrKeyType" minOccurs属性= "0" /> <要素名= "CHG" タイプ= "secDNS：chgType" のminOccurs = "0" /> </シーケンス> <属性名= "緊急" タイプ= "ブール" デフォルト= "false" に/> </ complexTypeの>

<complexType name="remType"> <choice> <element name="all" type="boolean"/> <element name="dsData" type="secDNS:dsDataType" maxOccurs="unbounded"/> <element name="keyData" type="secDNS:keyDataType" maxOccurs="unbounded"/> </choice> </complexType>

<！ - <レム>コマンドの子要素。 - > <complexTypeの名= "remType"> <選択> <要素名= "すべて" タイプ= "ブール" /> <要素名= "dsData" タイプ= "secDNS：dsDataType" のmaxOccurs = "無制限" /> <要素名= "KEYDATA" タイプ= "secDNS：keyDataType" のmaxOccurs = "無制限" /> </選択> </ complexTypeの>

<！ - <CHG>要素をサポートしている子要素。 - >

<complexTypeの名前= "chgType"> <シーケンス> <要素名= "maxSigLife" タイプ= "secDNS：maxSigLifeType" のminOccurs = "0" /> </配列> </ complexTypeの>

<element name="infData" type="secDNS:dsOrKeyType"/>

<！ - 子供の応答要素。 - > <要素名= "infData" タイプ= "secDNS：dsOrKeyType" />

</schema> END

</スキーマ> END

7. Internationalization Considerations

7.国際化に関する注意事項

EPP is represented in XML, which provides native support for encoding information using the Unicode character set and its more compact representations including UTF-8 [RFC3629]. Conformant XML processors recognize both UTF-8 and UTF-16 [RFC2781]. Though XML includes provisions to identify and use other character encodings through use of an "encoding" attribute in an <?xml?> declaration, use of UTF-8 is RECOMMENDED in environments where parser encoding support incompatibility exists.

EPPは、Unicode文字セットとUTF-8 [RFC3629]などのよりコンパクトな表現を用いて情報を符号化するためのネイティブサポートを提供するXMLで表現されています。準拠XMLプロセッサは、UTF-8およびUTF-16 [RFC2781]の両方を認識する。 XMLは、<？xmlの？>宣言で「エンコーディング」属性を使用して他の文字エンコーディングを識別し、使用する規定を含んでいるものの、UTF-8を使用すると、パーサエンコードのサポートの非互換性が存在する環境で推奨されます。

As an extension of the EPP domain mapping [RFC5731], the internationalization requirements in the EPP domain mapping [RFC5731] are followed by this extension. This extension does not override any of the EPP domain mapping [RFC5731] internationalization features.

EPPドメインマッピング[RFC5731]の拡張として、EPPドメインマッピング[RFC5731]での国際要件は、この拡張が続きます。この拡張は、EPPドメインマッピングのいずれかの[RFC5731]国際化機能を無効にすることはありません。

8. IANA Considerations

8. IANAの考慮事項

This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in RFC 3688 [RFC3688]. Two URI assignments have been completed by the IANA.

この文書は、RFC 3688 [RFC3688]に記載されたレジストリ・メカニズムに準拠するXML名前空間とXMLスキーマを記述するためのURNを使用します。二つのURIの割り当てはIANAによって完成されています。

Registration request for the extension namespace:

拡張名前空間の登録要求：

URI: urn:ietf:params:xml:ns:secDNS-1.1

URI：URN：IETF：のparams：XML：NS：secDNS-1.1

Registrant Contact: IESG

登録者連絡先：IESG

XML: None. Namespace URIs do not represent an XML specification.

XML：なし。名前空間URIはXMLの仕様を示すものではありません。

Registration request for the extension XML schema:

拡張XMLスキーマの登録要求：

URI: urn:ietf:params:xml:schema:secDNS-1.1

URI：URN：IETF：のparams：XML：スキーマ：secDNS-1.1

Registrant Contact: IESG

登録者連絡先：IESG

XML: See the "Formal Syntax" section of this document.

XML：このドキュメントの「正式な構文」を参照してください。

9. Security Considerations

9.セキュリティの考慮事項

The mapping extensions described in this document do not provide any security services beyond those described by EPP [RFC5730], the EPP domain name mapping [RFC5731], and protocol layers used by EPP. The security considerations described in these other specifications apply to this specification as well.

EPP [RFC5730]で説明されたものを越えたセキュリティサービスを提供していない、この文書で説明したマッピングの拡張は、EPPドメイン名マッピング[RFC5731]、およびプロトコル層は、EPPで使用されます。これらの他の仕様で説明されているセキュリティの考慮事項は、同様に、この仕様に適用されます。

As with other domain object transforms, the EPP transform operations described in this document MUST be restricted to the sponsoring client as authenticated using the mechanisms described in Sections 2.9.1.1 and 7 of RFC 5730 [RFC5730]. Any attempt to perform a transform operation on a domain object by any client other than the sponsoring client MUST be rejected with an appropriate EPP authorization error.

他のドメインのオブジェクトは変換と同様に、EPPは、[RFC5730] RFC 5730のセクション2.9.1.1及び7で説明したメカニズムを使用して認証として本書で説明した動作は、スポンサークライアントに制限されなければならない変換します。スポンサークライアント以外のクライアントによるドメインオブジェクトに変換操作を実行しようとすると、適切なEPPの認証エラーで拒否されなければなりません。

The provisioning service described in this document involves the exchange of information that can have an operational impact on the DNS. A trust relationship MUST exist between the EPP client and server, and provisioning of public key information MUST only be done after the identities of both parties have been confirmed using a strong authentication mechanism.

このドキュメントで説明プロビジョニングサービスは、DNSの運用への影響を持つことができ、情報の交換を伴います。信頼関係は、EPPのクライアントとサーバの間に存在しなければならない、と両当事者のアイデンティティは強力な認証メカニズムを用いて確認された後に公開鍵情報の提供のみを行わなければなりません。

An EPP client might be acting as an agent for a zone administrator who wants to send delegation information to be signed and published by the server operator. Man-in-the-middle attacks are thus possible as a result of direct client activity or inadvertent client data manipulation.

EPPクライアントは、サーバのオペレータによって署名され、公表されるように委任情報を送信したいゾーン管理者のためのエージェントとして働く可能性があります。 man-in-the-middle攻撃は、直接顧客の活動や不注意によるクライアントのデータ操作の結果としてことが可能です。

Acceptance of a false key by a server operator can produce significant operational consequences. The child and parent zones MUST be consistent to secure the delegation properly. In the absence of consistent signatures, the delegation will not appear in the secure namespace, yielding untrustworthy query responses. If a key is compromised, a client can either remove the compromised information or update the delegation information via EPP commands using the "urgent" attribute.

サーバーオペレータによる誤ったキーの受け入れは、重要な運用の結果を生成することができます。子と親のゾーンが適切に委任を確保するために一貫していなければなりません。一貫性のある署名がない場合には、代表団は信用できないクエリ応答を得、安全な名前空間には表示されません。キーが侵害された場合、クライアントは妥協の情報を削除するか、「緊急」属性を使用してコマンドEPP経由で委任情報を更新することができます。

Operational scenarios requiring quick removal of a secure domain delegation can be implemented using a two-step process. First, security credentials can be removed using an "urgent" update as just described. The domain can then be removed from the parent zone by changing the status of the domain to either of the EPP "clientHold" or "serverHold" domain status values. The domain can also be removed from the zone using the EPP <delete> command, but this is a more drastic step that needs to be considered carefully before use.

セキュア・ドメインの委任の迅速な除去を必要とする業務シナリオは2段階のプロセスを用いて実現することができます。まず、セキュリティ証明書は、今述べたように、「緊急」の更新プログラムを使用して除去することができます。ドメインは、その後、EPP「clientHold」または「serverHold」ドメインステータス値のいずれかにドメインの状態を変化させることにより、親ゾーンから除去することができます。ドメインは、コマンド<削除>をEPPを使用してゾーンから削除することができますが、これは使用前に慎重に検討する必要があり、より大幅なステップです。

Data validity checking and Delegation Signer record creation at the server require computational resources. A purposeful or inadvertent denial-of-service attack is possible if a client requests some number of update operations that exceed a server's processing capabilities. Server operators SHOULD take steps to manage command load and command processing requirements to minimize the risk of a denial-of-service attack.

サーバーでのデータの妥当性チェックと委任署名者レコードの作成には、計算リソースを必要とします。クライアントは、サーバの処理能力を超えて、更新操作のいくつかの数を要求した場合意図的または不注意によるサービス拒否攻撃が可能です。サーバー事業者は、サービス拒否攻撃のリスクを最小限にするために、コマンド負荷とコマンド処理要件を管理するための措置をとるべきです。

The signature lifetime values provided by clients are requests that can be rejected. Blind acceptance by a server operator can have an adverse impact on a server's processing capabilities. Server operators SHOULD seriously consider adopting implementation rules to limit the range of acceptable signature lifetime values to counter potential adverse situations.

クライアントが提供する署名寿命値は拒否できる要求されています。サーバーオペレータによるブラインド受け入れは、サーバの処理能力に悪影響を与えることができます。サーバー事業者は真剣に潜在的な有害な状況に対処するために許容可能な署名のライフタイム値の範囲を制限するために、実施細則を採用検討すべきです。

10. Acknowledgements

10.謝辞

The authors would like to thank the following people who have provided significant contributions to the development of this document:

著者は、この文書の発展に多大な貢献を提供している以下の方々に感謝したいと思います：

David Blacka, Howard Eland, Patrik Faltstrom, Olafur Gudmundsson, Bernie Hoeneisen, Ed Lewis, Klaus Malorny, Alexander Mayrhofer, Patrick Mevzek, David Smith, Andrew Sullivan, and Srikanth Veeramachaneni.

デビッドBlacka、ハワードエランド、パトリックFaltstrom、オラフルグドムンソン、バーニーHoeneisen、エド・ルイス、クラウスMalorny、アレクサンダーMayrhofer、パトリックMevzek、デビッド・スミス、アンドリュー・サリバン、およびスリカンスVeeramachaneni。

This document replaces RFC 4310 [RFC4310]. Please see the Acknowledgements section in that RFC for additional acknowledgements.

この文書は、RFC 4310 [RFC4310]を置き換えます。追加の承認のためにそのRFCでの謝辞のセクションを参照してください。

This document incorporates feedback from early implementers on the PROVREG mailing list and users.

この文書では、PROVREGメーリングリストやユーザーへの早期の実装からのフィードバックが組み込まれています。

11. References

11.参考文献

11.1. Normative References

11.1. 引用規格

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.

[RFC3688] Mealling、M.、 "IETF XMLレジストリ"、BCP 81、RFC 3688、2004年1月。

[RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", RFC 3757, April 2004.

[RFC3757] Kolkman、O.、Schlyter、J.、およびE.ルイス、 "ドメインネームシステムKEY（DNSKEY）リソースレコード（RR）セキュアエントリーポイント（SEP）フラグ"、RFC 3757、2004年4月。

[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.

[RFC4034]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ拡張機能のためのリソースレコード"、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]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ拡張のためのプロトコル変更"、RFC 4035、2005年3月。

[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, August 2009.

[RFC5730]ホレンベック、S.、 "拡張可能なプロビジョニングプロトコル（EPP）"、STD 69、RFC 5730、2009年8月。

[RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", STD 69, RFC 5731, August 2009.

[RFC5731]ホレンベック、S.、 "拡張プロビジョニングプロトコル（EPP）ドメイン名のマッピング"、STD 69、RFC 5731、2009年8月。

[W3C.REC-xml-20001006] Maler, E., Sperberg-McQueen, C., Bray, T., and J. Paoli, "Extensible Markup Language (XML) 1.0 (Second Edition)", World Wide Web Consortium FirstEdition REC-xml-20001006, October 2000, <http://www.w3.org/TR/2000/REC-xml-20001006>.

[W3C.REC-XML-20001006] MALER、E.、Sperberg-マックィーン、C.、ブレイ、T.、およびJ.パオリ、 "拡張マークアップ言語（XML）1.0（第二版）"、ワールドワイドウェブコンソーシアムFirstEdition REC-XML-20001006、2000年10月、<http://www.w3.org/TR/2000/REC-xml-20001006>。

[W3C.REC-xmlschema-1-20010502] Beech, D., Thompson, H., Mendelsohn, N., and M. Maloney, "XML Schema Part 1: Structures", World Wide Web Consortium FirstEdition REC-xmlschema-1-20010502, May 2001, <http://www.w3.org/TR/2001/REC-xmlschema-1-20010502>.

[W3C.REC-XMLSCHEMA-1から20010502]ブナ、D.、トンプソン、H.、メンデルゾーン、N.、およびM.マロニー、 "XMLスキーマパート1：構造"、ワールド・ワイド・ウェブ・コンソーシアムFirstEdition REC-XMLSCHEMA-1 -20010502、2001年5月、<http://www.w3.org/TR/2001/REC-xmlschema-1-20010502>。

[W3C.REC-xmlschema-2-20010502] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes", World Wide Web Consortium FirstEdition REC-xmlschema-2- 20010502, May 2001, <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502>.

[W3C.REC-XMLSCHEMA-2から20010502]マルホトラ、A.、およびP.ビロン、 "XMLスキーマパート2：データ型"、ワールド・ワイド・ウェブ・コンソーシアムFirstEdition REC-XMLSCHEMA -2- 20010502、2001年5月、<のhttp：// www.w3.org/TR/2001/REC-xmlschema-2-20010502>。

11.2. Informative References

11.2. 参考文献

[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.

[RFC1034] Mockapetris、P.、 "ドメイン名 - 概念と設備"、STD 13、RFC 1034、1987年11月。

[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.

[RFC1035] Mockapetris、P.、 "ドメイン名 - 実装及び仕様"、STD 13、RFC 1035、1987年11月。

[RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000.

[RFC2781]ホフマン、P.及びF. Yergeau、 "UTF-16、ISO 10646の符号化"、RFC 2781、2000年2月。

[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.

[RFC3629] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.

[RFC4033]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ序論と要件"、RFC 4033、2005年3月。

[RFC4310] Hollenbeck, S., "Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)", RFC 4310, December 2005.

[RFC4310]ホレンベック、S.、 "ドメインネームシステム（DNS）拡張プロビジョニングプロトコルのためのセキュリティ拡張機能のマッピング（EPP）"、RFC 4310、2005年12月。

Appendix A. Changes from

付録A.からの変更点

1. Added the motivation in obsoleting RFC 4310 [RFC4310] to Section 1.

1.第1に、RFC 4310 [RFC4310]を時代遅れにモチベーションを追加しました。

2. Updated Section 1 to add an explicit statement about deprecation of RFC 4310.

2.更新された第1は、RFC 4310の廃止についての明示的なステートメントを追加します。

3. Added secDNS-1.0 and secDNS-1.1 abbreviation definitions in Section 1.1.

3.追加secDNS-1.0および1.1項でsecDNS-1.1略語の定義。

4. Updated "Data validity checking at the server..." to "Data validity checking and Delegation Signer record creation at the server..." in Section 9.

4.第9章では「サーバ側でチェックし、データ妥当性...」「サーバーでのデータの妥当性チェックと委任署名者レコードの作成...」を更新しました。

5. Added Section 2.

5.追加の第2節。

6. Updated the second paragraph of Section 7 to clarify that the internationalization features of [RFC5731] are followed.

6. [RFC5731]の国際化機能が続いていることを明確にするために第7の第2段落を更新します。

7. Moved <secDNS:rem> prior to <secDNS:add> to conform to the EPP order semantics for supporting <secDNS:all> with <secDNS:rem> to remove all data, and for supporting the replace semantics previously supported by <secDNS:chg>.

7.移動<secDNS：REM> <secDNS：追加>の前に<secDNS：すべてを>サポートするためのEPPのためのセマンティクスに準拠するために、<secDNS：REM>、および以前に<でサポートされている置き換えセマンティクスをサポートするためのすべてのデータを削除しますsecDNS：CHG>。

8. Added support for the use of the <secDNS:all> boolean element under <secDNS:rem> to remove all DS or key data in place of using <secDNS:chg/>.

<：CHG / secDNS>を使用しての代わりに、すべてのDSや鍵データを削除するには：<レムsecDNS>下のブール要素：8. <すべてsecDNS>を使用するためのサポートを追加しました。

9. Updated <secDNS:add>, <secDNS:rem>, and <secDNS:chg> to function in a consistent way to the other EPP RFCs.

9.更新<secDNS：追加>、<secDNS：REM>、および<secDNS：CHG>他のEPPのRFCに一貫した方法で機能します。

10. Removed support for <secDNS:rem> using just <secDNS:keyTag>.

ちょうど使用して<secDNS：キータグ>を<REM secDNS> 10.サポートが削除されました。

11. Moved the <secDNS:maxSigLife> element out of the <secDNS:dsData> and <secDNS:keyData> elements and directly under the <secDNS: create> element, under the <secDNS:chg> element of the <secDNS: update> element, and under the <secDNS:infData> element. Section 3.3 element was updated to better describe the <secDNS: maxSigLife> element, and references to the <secDNS:maxSigLife> element were updated throughout the document.

<：maxSigLife secDNS>から要素<secDNS：dsData>と<secDNS：キーデータ>要素と直接下に11を移動<secDNSを：作成>：<secDNSの要素：更新<CHG secDNS>の下で、エレメントを>要素、および<secDNS下：infData>要素。 3.3節の要素をよりよく説明するために更新された<secDNS：maxSigLife>要素を、およびへの参照<secDNS：maxSigLife>要素は、文書全体を更新しました。

12. Replaced references to urn:ietf:params:xml:schema:secDNS-1.0 with urn:ietf:params:xml:schema:secDNS-1.1, and replaced "Two URI assignments have been completed by the IANA" with "Two URI assignments have been completed by the IANA" in Section 8.

URNする12.置き換え参照：IETF：のparams：XML：スキーマ：secDNS-1.0壷で：IETF：のparams：XML：スキーマ：secDNS-1.1、及び「二つのURIで "二つのURIの割り当てはIANAによって完成されました" に置き換え割り当ては、第8節で「IANAによって完成されています。

13. Added "The <secDNS:keyTag> element is represented as an unsignedShort [W3C.REC-xmlschema-2-20010502]" in Section 4.1.

13.追加さ：4.1で "<secDNSキータグ>要素は[W3C.REC-XMLSCHEMA-2から20010502]なunsignedShortとして表されています"。

14. Added "The <secDNS:digest> element is represented as a hexBinary [W3C.REC-xmlschema-2-20010502]" in Section 4.1.

14.追加さ：4.1で "<secDNSダイジェスト>要素は[W3C.REC-XMLSCHEMA-2から20010502]のhexBinaryとして表されています"。

15. Added "The <secDNS:pubKey> element is represented as a base64Binary [W3C.REC-xmlschema-2-20010502] with a minimum length of 1" in Section 4.2.

15.追加さ：4.2項における "<secDNS pubkeyでは>要素は、1の最小の長さbase64Binaryの[W3C.REC-XMLSCHEMA-2から20010502]として表されています"。

16. Combined "the command MUST contain an <extension> element" with the following sentence in Section 5.2.1 and Section 5.2.5.

16.複合セクション5.2.1と5.2.5で、次の文で「コマンドは、<拡張子>要素を含まなければなりません」。

17. Added sentence "If the server does not support the <secDNS: maxSigLife> element, a 2102 error MUST be returned" to Section 5.2.1 and Section 5.2.5.

17.追加文：5.2.1および5.2.5に「サーバがサポートされていない場合は、<secDNS maxSigLife>要素を、2102エラーが返されなければなりません」。

18. Added sentence "This document replaces RFC 4310. Please see the Acknowledgements section in that RFC for additional acknowledgements" in Section 10.

18.追加の文は、第10節に「この文書は、RFC 4310を置き換える追加の承認のためにそのRFCでの謝辞のセクションを参照してください」。

19. Added "This document incorporates feedback from implementers on the PROVREG mail list and users" as well as "This document obsoletes RFC 4310" in the Abstract.

19.「この文書はPROVREGメールリストの実装やユーザーからのフィードバックを取り入れ」だけでなく、要約書に「この文書はRFC 4310を廃止」を追加しました。

20. Removed all references to xsi:schemaLocation to be consistent with the other EPP RFCs.

他のEPPのRFCと一致するようにschemaLocation：20はXSIへのすべての参照を削除します。

21. Added the "DS Data Interface and Key Data Interface" section.

21.「DSデータインターフェースとキーデータ・インタフェース」セクションを追加しました。

22. Moved the "create, add, remove, and replace Delegation Signer (DS) information" paragraph from the "Object Attributes" section to the "DS Data Interface" section.

22.「作成、追加、削除、および委任署名者（DS）情報交換してください」「DSデータインタフェース」セクションに、「オブジェクト属性」セクションから段落を移動しました。

23. Replaced the element descriptions in the "EPP <info> Command" section with a reference to the <secDNS:dsData> and <secDNS: keyData> elements described in the "DS Data Interface" and "Key Data Interface" sections, respectively.

それぞれ、「DSデータインタフェース」で説明：<KEYDATA secDNS>要素と「キー・データ・インタフェース」のセクション：<dsData secDNS>と23はを参照して、「EPP <インフォメーション>コマンド」セクションの要素の説明を置き換え。

24. Updated the "EPP <info> Command" section examples to include both the DS Data Interface and the Key Data Interface.

24. DSデータインターフェースとキーデータ・インタフェースの両方を含むことが「EPP <インフォメーション>コマンド」セクションの例を更新しました。

25. Updated the "EPP <create> Command" section to refer to both the use of <secDNS:dsData> and <secDNS:keyData> described in the "DS Data Interface" and "Key Data Interface" sections, respectively.

<：dsData secDNS>と25は、の使用の両方を参照するために、「EPP <作成>コマンド」セクションを更新しました<secDNS：KEYDATA>は、それぞれ、「DSデータ・インターフェース」と「キー・データ・インタフェース」のセクションで説明。

26. Updated the "EPP <create> Command" section examples to include both the DS Data Interface and the Key Data Interface.

26.「EPPコマンド<作成>」DSデータインターフェースとキーデータ・インタフェースの両方を含むセクションの例を更新しました。

27. Updated the "EPP <update> Command" section to describe the use of <secDNS:add>, <secDNS:rem>, and <secDNS:chg> together.

27の使用を説明するために "EPP <アップデート>コマンド" セクションを更新<secDNS：追加>を、<secDNS：REM>、および<secDNS：CHG>一緒に。

28. Updated the "EPP <update> Command" section examples to include both the DS Data Interface and the Key Data Interface. Also included additional examples of adding and removing DS data or key data.

28. DSデータインターフェースとキーデータ・インタフェースの両方を含むことが「EPP <アップデート>コマンド」セクションの例を更新しました。また、DSのデータやキーデータの追加や削除の追加の例が含まれています。

29. Updated the "Formal Syntax" section with the updated XML schema.

29.更新されたXMLスキーマで「正式な構文」のセクションを更新しました。

30. Updated the Acknowledgements section with a new list of contributors.

30.貢献者の新しいリストを謝辞セクションを更新しました。

31. Replaced references to RFC 3730 with references to RFC 5730.

31. RFC 5730を参照してRFC 3730への参照を置き換えられました。

32. Replaced references to RFC 3731 with references to RFC 5731.

32. RFC 5731を参照してRFC 3731への参照を置き換えられました。

33. Added clarification on when the extension MUST be included for each of the commands and responses (<secDNS:create>, <secDNS: update>, <secDNS:infData>).

拡張コマンドおよび応答の各々のために含まなければならないときに33を追加しました浄化（<secDNS：作成>、<secDNS：更新>、<secDNS：infData>）。

34. Changed "In addition, the EPP <extension> element MUST contain a child <secDNS:infData> element" to "In addition, the EPP <extension> element SHOULD contain a child <secDNS:infData> element" and added "and based on server policy".

「さらに、EPP <拡張>要素は、子含むべきである<secDNS：infData>要素を」する：34.「<infData secDNS>要素、さらにEPP <拡張>要素の子を含まなければならない」に変更し、「追加とサーバーポリシー」に基づきます。

Authors' Addresses

著者のアドレス

James Gould VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 US

ジェームズ・グールドベリサイン社21345 Ridgetopサークルダレス、バージニア州20166から6503米

EMail: jgould@verisign.com

メールアドレス：jgould@verisign.com

Scott Hollenbeck VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 US

スコットホレンベックベリサイン社21345 Ridgetopサークルダレス、バージニア州20166から6503米

EMail: shollenbeck@verisign.com

メールアドレス：shollenbeck@verisign.com