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

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

Network Working Group                                      S. Hollenbeck
Request for Comments: 4310                                VeriSign, Inc.
Category: Standards Track                                  November 2005

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

Status of this Memo

このメモの位置付け

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。

著作権表示

著作権（C）インターネット協会（2005）。

Abstract

抽象

This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of Domain Name System security extensions (DNSSEC) 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.

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

Table of Contents

   1. Introduction ....................................................2
      1.1. Conventions Used in This Document ..........................2
   2. Object Attributes ...............................................3
      2.1. Delegation Signer Information ..............................3
           2.1.1. Public Key Information ..............................3
      2.2. Booleans ...................................................3
      2.3. Maximum Signature Lifetime Values ..........................4
   3. EPP Command Mapping .............................................4
      3.1. EPP Query Commands .........................................4
           3.1.1. EPP <check> Command .................................4
           3.1.2. EPP <info> Command ..................................4
           3.1.3. EPP <transfer> Command ..............................8
      3.2. EPP Transform Commands .....................................8
           3.2.1. EPP <create> Command ................................8
           3.2.2. EPP <delete> Command ...............................11
           3.2.3. EPP <renew> Command ................................11
           3.2.4. EPP <transfer> Command .............................11

           3.2.5. EPP <update> Command ...............................11
   4. Formal Syntax ..................................................15
   5. Internationalization Considerations ............................18
   6. IANA Considerations ............................................18
   7. Security Considerations ........................................18
   8. Acknowledgements ...............................................20
   9. References .....................................................20
      9.1. Normative References ......................................20
      9.2. Informative References ....................................21

1. Introduction

1. はじめに

This document describes an extension mapping for version 1.0 of the Extensible Provisioning Protocol (EPP) described in RFC 3730 [1]. This mapping, an extension of the domain name mapping described in RFC 3731 [2], is specified using the Extensible Markup Language (XML) 1.0 [3] and XML Schema notation ([4], [5]).

この文書は、RFC 3730に記載拡張プロビジョニングプロトコル（EPP）のバージョン1.0 [1]の拡張マッピングを記述する。このマッピングは、ドメイン名のマッピングの拡張は、RFC 3731に記載され[2]、XML（Extensible Markup Language）を使用して指定された1.0 [3]、XMLスキーマ表記（[4]、[5]）。

The EPP core protocol specification [1] 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 [11] and RFC 1035 [12] and with DNS security extensions described in RFC 4033 [13], RFC 4034 [6], and RFC 4035 [7] is required to understand the DNS security concepts described in this document.

EPPコアプロトコル仕様[1] EPPコマンドとレスポンス構造の完全な説明を提供します。基本プロトコル仕様の完全な理解は、本書で説明したマッピングを理解する必要があります。ドメインネームシステムRFC 1034に記載の（DNS）[11]およびRFC 1035 [12]及びRFC 4033に記載されたDNSセキュリティ拡張を有する[13]、RFC 4034 [6]、およびRFC 4035に精通している[7]が要求されますこのドキュメントで説明する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 as described in RFC 4034 [6].

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

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 [8].

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

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の仕様および実施例は、適合実装を開発するために提示された文字ケースで解釈されなければなりません。

2. Object Attributes

2.オブジェクトの属性

This extension adds additional elements to the EPP domain name mapping [2]. Only new element descriptions are described here.

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

This document describes operational scenarios in which a client can create, add, remove, and replace delegation signer (DS) information. 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 [9].

この文書では、クライアントが作成、追加、削除、および委任署名者（DS）情報を交換することが可能な動作シナリオを説明します。 DSの情報に関連付けられたキーデータは、クライアントによって提供されてもよいが、サーバーは、キーデータを使用する義務を負いません。サーバーオペレータは、受信したDS情報を評価するために登録されたドメインの頂点から鍵データを取得するために、アウトオブバンドDNSクエリを発行することができます。子ゾーンのオペレータが親ゾーンの管理者が必要に応じてデータを検証できるようにするためにDNSツリーにオンラインこの鍵データを持っていることが推奨されます。 RFC 3757に記載されているようにキーデータが設定セキュアエントリーポイント（SEP）ビットを有するべきである[9]。

2.1. Delegation Signer Information

2.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 RR contains four fields: a key tag field, a key algorithm number octet, an octet identifying the digest algorithm used, and a digest field. See RFC 4034 [6] for specific field formats.

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

2.1.1. Public Key Information

2.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 [6]. A DNSKEY RR contains four fields: flags, a protocol octet, an algorithm number octet, and a public key.

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

2.2. Booleans

2.2. ブール

Boolean values MUST be represented in the XML Schema format described in Part 2 of the W3C XML Schema recommendation [5].

ブール値は、W3C XMLスキーマ勧告[5]のパート2に記載されたXMLスキーマの形式で表現されなければなりません。

2.3. Maximum Signature Lifetime Values

2.3. 最大署名寿命値

Maximum signature lifetime values 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 [5]. This format is further restricted to enforce a minimum value of one.

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

3. EPP Command Mapping

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

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

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

3.1. EPP Query Commands

3.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つのコマンドを提供します。

3.1.1. EPP <check> Command

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

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

この拡張は、EPPチェック<>コマンドまたはEPPドメインマッピングに記載のチェック<>応答[2]のいずれかの要素を追加しません。

3.1.2. EPP <info> Command

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

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

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

When an <info> command has been processed successfully, the EPP <resData> element MUST contain child elements as described in the EPP domain mapping [2]. In addition, the EPP <extension> element MUST contain a child <secDNS:infData> element that identifies the extension namespace and the location of the extension schema. The <secDNS:infData> element contains the following child elements:

<インフォメーション>コマンドが正常に処理されたときはEPPドメインマッピング[2]で説明したように、EPP <resData>要素は、子要素を含まなければなりません。拡張ネームスペースと拡張スキーマのロケーションを識別する<infData secDNS>要素に加えて、EPP <拡張>要素は、子を含まなければなりません。 <secDNS：infData>要素は以下の子要素が含まれています。

One or more <secDNS:dsData> elements that describe the delegation signer data provided by the client for the domain. The <secDNS: dsData> element contains the following child elements:

1つ以上の<secDNS：dsData>ドメインのために、クライアントが提供する委任署名者のデータを記述する要素。 <secDNS：dsData>要素は以下の子要素が含まれています。

A <secDNS:keyTag> element that contains a key tag value as described in section 5.1.1 of RFC 4034 [6].

：RFC 4034のセクション5.1.1に記載したようにキータグ値を含む<secDNSキータグ>要素[6]。

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

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

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

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

A <secDNS:digest> element that contains a digest value as described in section 5.1.4 of RFC 4034 [6].

<secDNS：ダイジェスト>要素RFC 4034のセクション5.1.4に記載のようにダイジェスト値が含まれている[6]。

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. A client SHOULD specify the same <secDNS:maxSigLife> value for all <secDNS:dsData> elements associated with a domain. If the <secDNS:maxSigLife> is not present, or if multiple <secDNS:maxSigLife> values are requested, the default signature expiration policy of the server operator (as determined using an out-of-band mechanism) applies.

オプション：子によって提供さDS情報の親の署名が期限切れになる署名生成後の秒数の子供の好みを示し、<secDNS maxSigLife>要素。ドメインに関連付けられている：<dsData secDNS>要素のすべての値：クライアントが同じ<maxSigLife secDNS>を指定する必要があります。もし<secDNS：maxSigLife>は存在しない、または複数の場合<secDNS：maxSigLife>の値が要求され、サーバのオペレータのデフォルトの署名の有効期限ポリシーは、（アウトオブバンドメカニズムを使用して決定される）を印加します。

An OPTIONAL <secDNS:keyData> element that describes the key data used as input in the DS hash calculation. The <secDNS: keyData> element contains the following child elements:

オプション：DSハッシュ計算の入力として使用される鍵データを記述する<secDNSキーデータ>要素。 <secDNS：KEYDATA>要素は以下の子要素が含まれています。

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

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

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

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

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

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

A <secDNS:pubKey> element that contains an encoded public key field value as described in sections 2.1.4 of RFC 4034 [6].

：RFC 4034のセクション2.1.4に記載したように符号化された公開鍵フィールドの値が含まれている<secDNS pubkeyで>要素[6]。

Example <info> Response for a Secure Delegation:

例<インフォメーション>セキュアな委任のための対応：

S: <resData> S: <domain:infData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" S: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 S: domain-1.0.xsd"> 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: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.0" S: xsi:schemaLocation="urn:ietf:params:xml:ns:secDNS-1.0 S: secDNS-1.0.xsd"> 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：<resData> S：<ドメイン：infData S：のxmlns：ドメイン= "壷：IETF：のparams：XML：NS：ドメイン-1.0" S：XSI：のschemaLocation = "壷：IETF：のparams：XML：NS：ドメイン-1.0 S：ドメイン-1.0.xsd "> 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 </ドメイン：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.0" S：XSI：のschemaLocation = "URN：IETF：paramsは：XML：NS：secDNS-1.0 S：secDNS- 1.0.xsd "> 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 with OPTIONAL Data:

例<インフォメーション>オプションのデータを使った安全な委任のための対応：

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: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 S: epp-1.0.xsd"> 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: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 S: domain-1.0.xsd"> 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: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.0" S: xsi:schemaLocation="urn:ietf:params:xml:ns:secDNS-1.0 S: secDNS-1.0.xsd"> S: <secDNS:dsData> S: <secDNS:keyTag>12345</secDNS:keyTag> S: <secDNS:alg>3</secDNS:alg>

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：XSI：のschemaLocation = "URN：IETF：paramsは：XML：NS：EPP-1.0 S：EPP-1.0.xsd"> S <レスポンス> S：<結果コード= "1000"> S：<MSG>コマンドが正常に完了しまし</ MSG> S：</結果> S：<resData> S：<ドメイン：infData S：のxmlns：ドメイン= "壷： IETF：のparams：XML：NS：ドメイン-1.0" S：XSI：のschemaLocation = "壷：IETF：のparams：XML：NS：ドメイン-1.0 S：ドメイン-1.0.xsd"> S：<ドメイン：名>例。 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：<ドメイン：CL ID> ClientX </ドメイン：CLID> S <ドメイン：CRID> clientYプロパティ</ドメイン：CRID> S <ドメイン：のcrdate> 1999-04-03T22：00：00.0Z </ドメイン：の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 = "壷：IETF：のparams：XML：NS： secDNS-1.0" S：XSI：のschemaLocation = "壷：IETF：のparams：XML：NS：secDNS-1.0 S：secDNS-1.0.xsd"> S：<secDNS：dsData> S：<secDNS：キータグ> 12345 </ secDNS：キータグ> S：<secDNS：ALG> 3 </ secDNS：ALG>

S: <secDNS:digestType>1</secDNS:digestType> S: <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest> S: <secDNS:maxSigLife>604800</secDNS:maxSigLife> S: <secDNS:keyData> S: <secDNS:flags>256</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：<secDNS：digestType> 1 </ secDNS：digestType> S <secDNS：ダイジェスト> 49FD46E6C4B45C55D4AC：S </ secDNSダイジェスト>：<secDNS：maxSigLife> 604800 </ secDNS：maxSigLife> S <secDNS：キーデータ> S <secDNS：フラグ> 256 </ secDNS：フラグ> S <secDNS：プロトコル> 3 </ secDNS：プロトコル> S <secDNS：ALG> 1 </ secDNS：ALG> S <secDNS：pubkeyで> AQPJ / /// 4Q == </ secDNS：pubkeyで> S </ 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>

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

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

3.1.3. EPP <transfer> Command

3.1.3. EPP <転送>コマンド

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

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

3.2. EPP Transform Commands

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

3.2.1. EPP <create> Command

3.2.1. EPP <作成>コマンド

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

この拡張は、[2] EPPドメインのマッピングに記載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 [2], the command MUST contain an <extension> element. The <extension> element MUST contain a child <secDNS:create> element that identifies the extension namespace and the location of the extension schema. The <secDNS: create> element MUST contain one or more <secDNS:dsData> elements. Child elements of the <secDNS:dsData> element are described in Section 3.1.2.

EPP <作成>コマンドは、クライアントがドメインオブジェクトを作成することを可能にする変換操作を提供します。 EPPドメインマッピング[2]に記載のEPPコマンド要素に加えて、コマンドは、<拡張>要素を含まなければなりません。拡張名前空間と拡張スキーマの場所を特定する要素：<拡張子>要素は、子<作成secDNS>を含まなければなりません。 <secDNS：作成> <：dsData secDNS>要素要素が1つ以上を含まなければなりません。子要素<secDNS：dsData>要素は、3.1.2項で説明されています。

The <secDNS:dsData> element contains OPTIONAL <secDNS:maxSigLife> and <secDNS:keyData> elements. The server MUST abort command processing and respond with an appropriate EPP error if the values provided by the client can not be accepted for syntax or policy reasons.

<secDNS：dsData> <：maxSigLife secDNS>と<secDNS：KEYDATA>要素要素はオプションが含まれています。サーバーは、コマンド処理を中止し、クライアントによって提供される値は、構文やポリシーの理由で受け入れることができない場合、適切なEPP誤りで応じなければなりません。

Example <create> Command for a Secure Delegation:

例では、Secure委任のためのコマンドを、<作成します>：

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: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 C: epp-1.0.xsd"> C: <command> C: <create> C: <domain:create C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" C: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 C: domain-1.0.xsd"> 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.0" C: xsi:schemaLocation="urn:ietf:params:xml:ns:secDNS-1.0 C: secDNS-1.0.xsd"> 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：の<？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：XSI：のschemaLocation = "URN：IETF：paramsは：XML：NS：EPP-1.0 C：EPP-1.0.xsd"> C <コマンド> C：<ドメイン：Cを作成します。のxmlns：ドメイン= "壷：IETF：のparams：XML：NS：ドメイン-1.0" C：XSI：のschemaLocation = "壷：IETF：のparams：XML：NS <> Cを作成します：ドメイン-1.0 C：ドメイン1.0.xsd "> 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.0" C：XSI：schemaLocatio N = "URN：IETF：paramsは：XML：NS：secDNS-1.0 C：secDNS-1.0.xsd"> C <secDNS：dsData> C <secDNS：キータグ> 12345 </ secDNS：キータグ> C <secDNS ：ALG> 3 </ secDNS：ALG> C <secDNS：digestType> 1 </ secDNS：digestType> C <secDNS：ダイジェスト> 49FD46E6C4B45C55D4AC </ secDNS：ダイジェスト> C </ secDNS：dsData> C </ secDNS：作成>

C: </extension> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp>

C：</拡張> C <clTRID> ABC-12345 </ clTRID> C </コマンド> C </ EPP>

Example <create> Command for a Secure Delegation with OPTIONAL data:

例では、オプションのデータを使った安全な委任のためのコマンドを、<作成します>：

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：<secDNS：pubkeyで> AQPJ //// 4Q == </ secDNS：pubkeyで> C </ secDNS：キーデータ> C </ secDNS：dsData> 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 [2].

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

3.2.2. EPP <delete> Command

3.2.2. EPP <削除>コマンド

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

この拡張は、EPP <削除>コマンドまたは<削除>に任意の要素を追加しないEPPドメインのマッピングに記載応答[2]。

3.2.3. EPP <renew> Command

3.2.3. EPP <更新>コマンド

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

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

3.2.4. EPP <transfer> Command

3.2.4. EPP <転送>コマンド

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

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

3.2.5. EPP <update> Command

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

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

この拡張は、[2] EPPドメインのマッピングに記載EPP <アップデート>コマンドの追加の要素を定義します。追加の要素が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. The <extension> element MUST contain a child <secDNS:update> element that identifies the extension namespace and the location of the extension schema. 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 replace security information with new security information.

EPP <アップデート>コマンドは、クライアントがドメインオブジェクトの属性を変更することを可能にする変換操作を提供します。 EPPドメインのマッピングに記載のEPPコマンド要素に加えて、コマンドは、<拡張>要素を含まなければなりません。拡張名前空間と拡張スキーマの場所を識別します。<更新secDNS>要素、<拡張子>要素は、子を含まなければなりません。委任にセキュリティ情報を追加する：<追加secDNS>要素、：代表団からのセキュリティ情報を削除するには、<secDNSレム>要素、または：セキュリティ情報を交換する<secDNS CHG>要素<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 2.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.

<secDNS：更新>要素には、オプションの「緊急」は、クライアントが完了し、優先度の高い更新要求を実現するために、サーバのオペレータに依頼するために使用できる属性が含まれています。この属性は、2.2節で説明したように、ブール値を受け入れます。デフォルト値はfalseブール値です。「高優先度」は、アウトオブバンドメカニズムを使用して決定されている標準的なサーバオペレータポリシーに対するものです。

The <secDNS:add> element is used to add DS information to an existing set. The <secDNS:add> element MUST contain one or more <secDNS: dsData> elements as described in Section 3.1.2.

<secDNS：追加>要素は、既存のセットにDS情報を追加するために使用されます。 <secDNS：追加>：3.1.2項で説明したように、<dsData secDNS>要素の要素が1つ以上を含まなければなりません。

The <secDNS:rem> element contains one or more <secDNS:keyTag> elements that are used to remove DS data from a delegation. The <secDNS:keyTag> element MUST contain a key tag value as described in section 5.1.1 of RFC 4034 [6]. Removing all DS information can remove the ability of the parent to secure the delegation to the child zone.

<secDNS：REM>：代表団からのDSデータを削除するために使用される要素要素は、1つ以上の<キータグsecDNS>が含まれています。：RFC 4034のセクション5.1.1に記載したように、<secDNSキータグ>要素は、キータグ値を含まなければならない[6]。すべてのDS情報を削除すると、子ゾーンへの委任を確保するために、親の能力を削除することができます。

The <secDNS:chg> element is used to replace existing DS information with new DS information. The <secDNS:chg> element MUST contain one or more <secDNS:dsData> elements as described in Section 3.1.2. The data in these elements is used to replace whatever other data is currently archived for the delegation.

<secDNS：CHG>要素は、新しいDS情報を既存のDS情報を交換するために使用されます。セクション3.1.2に記載したように<dsData secDNS>要素<secDNS CHG>要素は、一つ以上を含まなければなりません。これらの要素のデータは、現在の代表団のためにアーカイブされている他のどんなデータ交換するために使用されます。

The <secDNS:update> element contains an OPTIONAL "urgent" attribute. In addition, the <secDNS:dsData> element contains OPTIONAL <secDNS: maxSigLife> and <secDNS:keyData> elements. The server MUST abort command processing and respond with an appropriate EPP error if the values provided by the client can not be accepted for syntax or policy reasons.

<secDNS：更新>要素はオプション「緊急」属性が含まれています。また、<：maxSigLife secDNS>と<secDNS：キーデータ>要素<secDNS dsData>要素はオプションを含んでいます。サーバーは、コマンド処理を中止し、クライアントによって提供される値は、構文やポリシーの理由で受け入れることができない場合、適切なEPP誤りで応じなければなりません。

Example <update> Command, Adding DS Data:

例<更新>コマンド、DSデータの追加：

C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.0" C: xsi:schemaLocation="urn:ietf:params:xml:ns:secDNS-1.0 C: secDNS-1.0.xsd"> 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>

C：のxmlns：secDNS = "URN：IETF：paramsは：XML：NS：secDNS-1.0" C：XSI：のschemaLocation = "URN：IETF：paramsは：XML：NS：secDNS-1.0 C：secDNS-1.0.xsd"> C：<secDNS：追加> C <secDNS：dsData> C <secDNS：キータグ> 12346 </ secDNS：キータグ> C <secDNS：ALG> 3 </ secDNS：ALG> C <secDNS：digestType> 1 </ secDNS：digestType> C <secDNS：ダイジェスト> 38EC35D5B3A34B44C39B </ secDNSを：ダイジェスト> C </ secDNS：dsData> C </ secDNS：追加> C </ secDNS：更新> C </拡張> C：<clTRID> ABC-12345 </ clTRID> C </コマンド> C </ EPP>

Example <update> Command, Removing DS Data:

例<更新>コマンド、DSデータの削除：

Example Urgent <update> Command, Changing DS Data:

DSデータの変更例緊急<更新>コマンド、：

Example <update> Command, Changing Data to Include OPTIONAL Data:

例<更新>コマンド、オプションのデータを含めるデータを変更します：

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.0" C: xsi:schemaLocation="urn:ietf:params:xml:ns:secDNS-1.0 C: secDNS-1.0.xsd"> C: <secDNS:chg> 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:maxSigLife>604800</secDNS:maxSigLife> C: <secDNS:keyData> C: <secDNS:flags>256</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:chg> C: </secDNS:update> C: </extension> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp>

C：<ドメイン：名> example.com </ドメイン：名> C：</ドメイン：更新> C：</更新> C：<拡張子> C：<secDNS：更新C：のxmlns：secDNS = "壷： IETF：paramsは：XML：NS：secDNS-1.0" C：XSI：のschemaLocation = "URN：IETF：paramsは：XML：NS：secDNS-1.0 C：secDNS-1.0.xsd"> C <secDNS：CHG> C： <secDNS：dsData> C <secDNS：キータグ> 12345 </ secDNS：キータグ> C <secDNS：ALG> 3 </ secDNS：ALG> C <secDNS：digestType> 1 </ secDNS：digestType> C < secDNS：ダイジェスト> C：<secDNS：maxSigLife> 604800 </ secDNS：maxSigLife> C <secDNS：キーデータ> C <secDNS：フラグ> 256 </ secDNS：フラグ> C <secDNS> 49FD46E6C4B45C55D4AC </ secDNSダイジェスト：プロトコル> 3 </ secDNS：プロトコル> C <secDNS：ALG> 1 </ secDNS：ALG> C <secDNS：pubkeyで> AQPJ //// 4Q == </ secDNS：pubkeyで> C </ secDNS ：キーデータ> C </ secDNS：dsData> C </ secDNS：CHG> C </ secDNS：更新> C </拡張> C <clTRID> ABC-12345 </ clTRID> C </コマンド> C：</ EPP>

When an extended <update> command has been processed successfully, the EPP response is as described in the EPP domain mapping [2]. A server operator MUST return an EPP error result code of 2306 if an urgent update (noted with an "urgent" attribute value of boolean true) can not be completed with high priority.

<更新>コマンドが正常に処理された伸ばされた時、EPPドメインマッピング[2]に記載されているように、EPP応答です。（ブール真の「緊急」の属性値で示される）緊急アップデートが高優先度で完了できない場合、サーバオペレータ2306のEPPエラー結果コードを返さなければなりません。

4. Formal Syntax

4.正式な構文

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の登録目的のためのスキーマの始まりと終わりを注意するために使用されています。

BEGIN <?xml version="1.0" encoding="UTF-8"?>

BEGINの<？xml version = "1.0" エンコードは= "UTF-8"？>

<スキーマのtargetNamespace = "URN：IETF：paramsは：XML：NS：secDNS-1.0" のxmlns：secDNS = "URN：IETF：paramsは：XML：NS：secDNS-1.0" のxmlns = "http://www.w3.org / 2001 / XMLスキーマ」のelementFormDefault = "資格">

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

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

<element name="create" type="secDNS:dsType"/> <element name="update" type="secDNS:updateType"/>

<！ - EPPコマンドで見つかった子要素。 - > <要素名= "作成" タイプ= "secDNS：dsType" /> <要素名= "更新" タイプ= "secDNS：UPDATETYPE" />

<complexType name="dsType"> <sequence> <element name="dsData" type="secDNS:dsDataType" maxOccurs="unbounded"/> </sequence> </complexType>

<！ - <> createコマンドの子要素。 - > <complexTypeの名= "dsType"> <シーケンス> <要素名= "dsData" タイプ= "secDNS：dsDataType" のmaxOccurs = "無制限" /> </配列> </ complexTypeの>

<complexTypeの名前= "dsDataType"> <シーケンス> <要素名= "キータグ" タイプ= "なunsignedShort" /> <要素名= "ALG" タイプ= "なunsignedByte" /> <要素名= "digestType" タイプ= "なunsignedByte "/> <要素名=" "/> <要素名= "maxSigLife" タイプ= "secDNS "タイプ=" のhexBinaryダイジェスト：maxSigLifeType" のminOccurs = "0"/> <要素名= "キーデータ" タイプ=" secDNSました： keyDataType」のminOccurs = "0" /> </配列> </ complexTypeの>

<単純名= "maxSigLifeType"> <制限塩基= "INT"> <のminInclusive値= "1" />

</restriction> </simpleType>

</制限> </単純>

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

<単純名= "キータイプ"> <制限ベース= "base64Binaryの"> <はminLength値= "1" /> </制限> </ simpleTypeの>

<complexType name="updateType"> <choice> <element name="add" type="secDNS:dsType"/> <element name="chg" type="secDNS:dsType"/> <element name="rem" type="secDNS:remType"/> </choice> <attribute name="urgent" type="boolean" default="false"/> </complexType>

<！ - <更新>コマンドの子要素。 - > <complexTypeの名= "UPDATETYPE"> <選択> <要素名= "追加" タイプ= "secDNS：dsType" /> <要素名= "CHG" タイプ= "secDNS：dsType" /> <要素名= "REM" タイプ= "secDNS：remType" /> </選択> <属性名= "緊急" タイプ= "ブール" デフォルト= "偽" /> </ complexTypeの>

<complexTypeの名前= "remType"> <シーケンス> <要素名= "キータグ" タイプ= "なunsignedShort" のmaxOccurs = "無制限" /> </配列> </ complexTypeの>

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

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

</schema> END

<！ - スキーマの終わり。 - > </スキーマ> END

5. Internationalization Considerations

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

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

As an extension of the EPP domain mapping [2], the elements, element content, attributes, and attribute values described in this document MUST inherit the internationalization conventions used to represent higher-layer domain and core protocol structures present in an XML instance that includes this extension.

EPPドメインマッピングの拡張[2]、要素、要素の内容、属性、および本文書に記載された値が含まれてXMLインスタンス中に存在する上位層のドメインとコアプロトコル構造を表すために使用される国際規則を継承する必要があり、属性としてこの拡張機能。

6. IANA Considerations

6. IANAの考慮事項

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

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

Registration request for the extension namespace:

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

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

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

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

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

Registrant Contact: IESG

登録者連絡先：IESG

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

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

7. Security Considerations

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

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

このドキュメントで説明する機能拡張は、EPPによって記載されているものを超えてすべてのセキュリティサービスを提供していないマッピング[1]、EPPドメイン名マッピング[2]、および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 3730 [1]. 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は、本書で説明した動作を変換認証として[1] RFC 3730のセクション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 name space, 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 at the server requires 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.

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

8. Acknowledgements

8.謝辞

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

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

David Blacka, Olafur Gudmundsson, Mark Kosters, Ed Lewis, Dan Massey, Marcos Sanz, Sam Weiler, and Ning Zhang.

デビッドBlacka、オラフルグドムンソン、マーク・Kosters、エド・ルイス、ダン・マッセイ、マルコス・サンス、サム・ワイラー、および寧張。

9. References

9.参考文献

9.1. Normative References

9.1. 引用規格

[1] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", RFC 3730, March 2004.

[1]ホレンベック、S.、 "拡張プロビジョニングプロトコル（EPP）"、RFC 3730、2004年3月。

[2] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", RFC 3731, March 2004.

[2]ホレンベック、S.、 "拡張プロビジョニングプロトコル（EPP）ドメイン名のマッピング"、RFC 3731、2004年3月。

[3] Paoli, J., Sperberg-McQueen, C., Bray, T., and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C FirstEdition REC-xml-20001006, October 2000.

[3]パオリ、J.、Sperberg-マックィーン、C.、ブレイ、T.、およびE. MALER、 "拡張マークアップ言語（XML）1.0（第二版）"、W3C FirstEdition REC-XML-20001006、2000年10月。

[4] Maloney, M., Beech, D., Mendelsohn, N., and H. Thompson, "XML Schema Part 1: Structures", W3C REC REC-xmlschema-1-20010502, May 2001.

[4]マロニー、M.、ブナ、D.、メンデルゾーン、N.、およびH.トンプソン、 "XMLスキーマパート1：構造"、W3C REC REC-XMLSCHEMA-1から20010502、2001年5月。

[5] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes", W3C REC REC-xmlschema-2-20010502, May 2001.

[5]マルホトラ、A.、およびP.ビロン、 "XMLスキーマパート2：データ型"、W3C REC REC-XMLSCHEMA-2から20010502、2001年5月。

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

[6]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ拡張のためのリソースレコード"、RFC 4034、2005年3月。

[7] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.

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

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

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

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

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

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

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

9.2. Informative References

9.2. 参考文献

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

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

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

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

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

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

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

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

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

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

Author's Address

著者のアドレス

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

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

EMail: shollenbeck@verisign.com

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

Full Copyright Statement

完全な著作権声明

著作権（C）インターネット協会（2005）。

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。