RFC4310 日本語訳
4310 Domain Name System (DNS) Security Extensions Mapping for theExtensible Provisioning Protocol (EPP). S. Hollenbeck. December 2005. (Format: TXT=46326 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Hollenbeck Request for Comments: 4310 VeriSign, Inc. Category: Standards Track November 2005
Hollenbeckがコメントのために要求するワーキンググループS.をネットワークでつないでください: 4310年のベリサインInc.カテゴリ: 標準化過程2005年11月
Domain Name System (DNS) Security Extensions Mapping
for the Extensible Provisioning Protocol (EPP)
広げることができる食糧を供給するドメインネームシステム(DNS)セキュリティ拡大マッピングは議定書を作ります。(エップ)
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(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)を写像するExtensible Provisioningプロトコル(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
1. 序論…2 1.1. このドキュメントで中古のコンベンション…2 2. オブジェクト属性…3 2.1. 委譲署名者情報…3 2.1.1. 公開鍵情報…3 2.2. 論理演算子…3 2.3. 最大の署名生涯値…4 3. EPPはマッピングを命令します…4 3.1. EPPはコマンドについて質問します…4 3.1.1. EPP<チェック>命令…4 3.1.2. EPP<インフォメーション>コマンド…4 3.1.3. EPP<転送>命令…8 3.2. EPPはコマンドを変えます…8 3.2.1. EPP<は>コマンドを作成します…8 3.2.2. EPP<は>コマンドを削除します…11 3.2.3. EPP<は>コマンドを更新します…11 3.2.4. EPP<転送>命令…11
Hollenbeck Standards Track [Page 1] RFC 4310 EPP DNS Security Extensions Mapping November 2005
2005年11月を写像するHollenbeck標準化過程[1ページ]RFC4310EPP DNSセキュリティ拡張子
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
3.2.5. EPP<アップデート>命令…11 4. 正式な構文…15 5. 国際化問題…18 6. IANA問題…18 7. セキュリティ問題…18 8. 承認…20 9. 参照…20 9.1. 標準の参照…20 9.2. 有益な参照…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]).
このドキュメントはExtensible Provisioningのバージョン1.0のためにRFC3730[1]で説明されたプロトコル(EPP)を写像する拡大について説明します。 このマッピング(RFC3731[2]で説明されたドメイン名マッピングの拡大)は拡張マークアップ言語(XML)1.0[3]とXML Schema記法([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コマンドと応答構造の完全な記述を提供します。 ベースプロトコル仕様の徹底的な理解が、本書では説明されたマッピングを理解するのに必要です。 ドメインネームシステム(DNS)への親しみはRFC1034[11]とRFC1035[12]とDNSセキュリティでRFC4033[13]で説明された拡大について説明しました、RFC4034[6]、RFC4035[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セキュリティ拡張子の食糧を供給するのと管理にメカニズムを指定します。 RFC4034[6]で説明されるようにDNSSEC委譲署名者(DS)リソース記録を発表するのにこのマッピングで交換された情報は、倉庫から抜粋して、使用できます。
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[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:」 系列はプロトコルサーバで. 」 ////を返しました。「表す、」 より一層ページ・バウンダリに合うように短くされた要素値に注意するために、使用されます。 刻み目と白いスペースは、例に提供しますが、要素関係を例証して、このプロトコルの義務的な特徴ではありません。
Hollenbeck Standards Track [Page 2] RFC 4310 EPP DNS Security Extensions Mapping November 2005
2005年11月を写像するHollenbeck標準化過程[2ページ]RFC4310EPP DNSセキュリティ拡張子
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.
この拡大は[2]を写像するEPPドメイン名に追加要素を追加します。 新しい要素記述だけがここで説明されます。
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木にオンラインでこの重要なデータを持っているのは、RECOMMENDEDです。 重要なデータSHOULDはRFC3757[9]で説明されるようにSecure Entry Point(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つの分野を含んでいます: 主要なタグ・フィールド、主要なアルゴリズム数の八重奏、使用されるダイジェストアルゴリズムを特定する八重奏、およびダイジェスト分野。 特定のフィールド形式のためのRFC4034[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.
クライアントによって提供された公開鍵情報はRFC4034[6]のセクション2.2で説明されたプレゼンテーションフィールド形式をDNSKEY RRに写像します。 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 Schema推薦[5]のPart2で説明されたXML Schema形式でブール値を表さなければなりません。
Hollenbeck Standards Track [Page 3] RFC 4310 EPP DNS Security Extensions Mapping November 2005
2005年11月を写像するHollenbeck標準化過程[3ページ]RFC4310EPP DNSセキュリティ拡張子
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 Schema"int"形式を使用して、秒に最大の署名生涯値を表さなければなりません。 ベース"int"形式(負数を許容する)はW3C XML Schema推薦[5]のPart2で説明されます。 この形式は、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コアプロトコル仕様[1]でEPP構文と意味論の詳述を見つけることができます。 ここで説明されたコマンドマッピングは特に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<へのどんな要素も[2]を写像するEPPドメインで説明された>コマンドか<チェック>応答をチェックすると言い足しません。
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<resData>要素は[2]を写像するEPPドメインで説明されるように子供要素を含まなければなりません。 さらに、EPP<拡大>要素は子供<secDNSを含まなければなりません: 拡大名前空間と拡大図式の位置を特定するinfData>要素。 <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].
<secDNS: .1セクション5.1RFC4034[6]で説明されるようにキー・タグ値を含むkeyTag>要素。
Hollenbeck Standards Track [Page 4] RFC 4310 EPP DNS Security Extensions Mapping November 2005
2005年11月を写像するHollenbeck標準化過程[4ページ]RFC4310EPP DNSセキュリティ拡張子
A <secDNS:alg> element that contains an algorithm value as
described in section 5.1.2 of RFC 4034 [6].
<secDNS: .2セクション5.1RFC4034[6]で説明されるようにアルゴリズム値を含むalg>要素。
A <secDNS:digestType> element that contains a digest type value
as described in section 5.1.3 of RFC 4034 [6].
<secDNS: .3セクション5.1RFC4034[6]で説明されるようにダイジェストタイプ価値を含むdigestType>要素。
A <secDNS:digest> element that contains a digest value as
described in section 5.1.4 of RFC 4034 [6].
<secDNS: .4セクション5.1RFC4034[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.
OPTIONAL<secDNS: DS情報における親の署名が提供されたとき署名世代の後に秒数のための子供の好みを示すmaxSigLife>要素が子供で期限が切れるでしょう。 クライアントSHOULDは同じ<secDNS: maxSigLife>価値をすべての<secDNSに指定します: ドメインに関連しているdsData>要素。 <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:
OPTIONAL<secDNS: DSハッシュ計算で入力されるように使用される重要なデータについて説明するkeyData>要素。 <secDNS: keyData>要素は以下の子供要素を含んでいます:
A <secDNS:flags> element that contains a flags field value
as described in section 2.1.1 of RFC 4034 [6].
<secDNS: .1セクション2.1RFC4034[6]で説明されるように旗の分野価値を含む>要素に旗を揚げさせます。
A <secDNS:protocol> element that contains a protocol field
value as described in section 2.1.2 of RFC 4034 [6].
<secDNS: .2セクション2.1RFC4034[6]で説明されるようにプロトコル分野価値を含む>要素について議定書の中で述べてください。
A <secDNS:alg> element that contains an algorithm number
field value as described in sections 2.1.3 of RFC 4034 [6].
<secDNS: .3セクション2.1RFC4034[6]で説明されるようにアルゴリズムナンバーフィールド価値を含むalg>要素。
A <secDNS:pubKey> element that contains an encoded public
key field value as described in sections 2.1.4 of RFC 4034
[6].
<secDNS: .4セクション2.1RFC4034[6]で説明されるようにコード化された公開鍵分野価値を含むpubKey>要素。
Example <info> Response for a Secure Delegation:
安全な委譲のための例の<インフォメーション>応答:
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: <?xmlバージョン=「=「UTF-8インチのスタンドアロン=」ノー、をコード化する1インチ」?>S: <epp xmlnsが等しい、「つぼ:ietf:params:xml:ナノ秒: epp-1インチS:、」 xmlns: xsiは" http://www.w3.org/2001/XMLSchema-instance "Sと等しいです: xsi: schemaLocationが等しい、「つぼ:ietf:params:xml:ナノ秒: epp-1.0秒間:、」 epp-1.0.xsd、「>S:」 <応答>S: <結果コードが等しい、「1000、「>S:」 <msg>Commandは首尾よく</msg>Sを完成しました: </結果>。
Hollenbeck Standards Track [Page 5] RFC 4310 EPP DNS Security Extensions Mapping November 2005
2005年11月を写像するHollenbeck標準化過程[5ページ]RFC4310EPP DNSセキュリティ拡張子
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:ナノ秒: ドメイン1インチS:、」 xsi: schemaLocationが等しい、「つぼ:ietf:params:xml:ナノ秒: ドメイン1.0秒間:、」 ドメイン-1.0.xsd、「>S:」 <ドメイン: 名前>example.com</ドメイン: >をSと命名してください: <ドメイン: roid>EXAMPLE1-レップ</ドメイン: roid>S: <ドメイン: 状態sは「OK」/>Sと等しいです: <ドメイン: 記入者>jd1234</ドメイン: 記入者>S: <ドメイン: タイプ=に連絡してください、「アドミン、「>sh8013</ドメイン: >Sに連絡してください」 <ドメイン: タイプ=に連絡してください、「科学技術、「>sh8013</ドメイン: >Sに連絡してください」 <ドメイン: ナノ秒>S: <ドメイン: hostObj>ns1.example.com</ドメイン: hostObj>S: <ドメイン: hostObj>ns2.example.com</ドメイン: hostObj>S: </ドメイン: ナノ秒>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が等しい、「つぼ:ietf:params:xml:ナノ秒: secDNS-1インチS:、」 xsi: schemaLocationが等しい、「つぼ:ietf:params:xml:ナノ秒: secDNS-1.0秒間:、」 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: ダイジェスト>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>。
Hollenbeck Standards Track [Page 6] RFC 4310 EPP DNS Security Extensions Mapping November 2005
2005年11月を写像するHollenbeck標準化過程[6ページ]RFC4310EPP DNSセキュリティ拡張子
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バージョン=「=「UTF-8インチのスタンドアロン=」ノー、をコード化する1インチ」?>S: <epp xmlnsが等しい、「つぼ:ietf:params:xml:ナノ秒: epp-1インチS:、」 xmlns: xsiは" http://www.w3.org/2001/XMLSchema-instance "Sと等しいです: xsi: schemaLocationが等しい、「つぼ:ietf:params:xml:ナノ秒: epp-1.0秒間:、」 epp-1.0.xsd、「>S:」 <応答>S: <結果コードが等しい、「1000、「>S:」 <msg>Commandは首尾よく</msg>Sを完成しました: </結果>S: <resData>S: <ドメイン: infData S: xmlns: ドメイン=、「つぼ:ietf:params:xml:ナノ秒: ドメイン1インチS:、」 xsi: schemaLocationが等しい、「つぼ:ietf:params:xml:ナノ秒: ドメイン1.0秒間:、」 ドメイン-1.0.xsd、「>S:」 <ドメイン: 名前>example.com</ドメイン: >をSと命名してください: <ドメイン: roid>EXAMPLE1-レップ</ドメイン: roid>S: <ドメイン: 状態sは「OK」/>Sと等しいです: <ドメイン: 記入者>jd1234</ドメイン: 記入者>S: <ドメイン: タイプ=に連絡してください、「アドミン、「>sh8013</ドメイン: >Sに連絡してください」 <ドメイン: タイプ=に連絡してください、「科学技術、「>sh8013</ドメイン: >Sに連絡してください」 <ドメイン: ナノ秒>S: <ドメイン: hostObj>ns1.example.com</ドメイン: hostObj>S: <ドメイン: hostObj>ns2.example.com</ドメイン: hostObj>S: </ドメイン: ナノ秒>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が等しい、「つぼ:ietf:params:xml:ナノ秒: secDNS-1インチS:、」 xsi: schemaLocationが等しい、「つぼ:ietf:params:xml:ナノ秒: secDNS-1.0秒間:、」 secDNS-1.0.xsd、「>S:」 <secDNS: dsData>S: <secDNS: keyTag>12345</secDNS: keyTag>S: <secDNS: alg>3</secDNS: alg>。
Hollenbeck Standards Track [Page 7] RFC 4310 EPP DNS Security Extensions Mapping November 2005
2005年11月を写像するHollenbeck標準化過程[7ページ]RFC4310EPP DNSセキュリティ拡張子
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</secDNS: >Sを読みこなしてください: <secDNS: maxSigLife>604800</secDNS: maxSigLife>S: <secDNS: keyData>S: <secDNS: 旗の>256</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>。
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.
EPP<が[2]を写像する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:
EPP<はコマンドがクライアントがドメインオブジェクトを作成できる変換操作を供給する>を作成します。 [2]を写像するEPPドメインで説明されたEPP指揮機関に加えて、コマンドは<拡大>要素を含まなければなりません。 <拡大>要素は子供<secDNSを含まなければなりません: 拡大名前空間と拡大図式の位置を特定する>要素を作成してください。 <secDNS:
Hollenbeck Standards Track [Page 8] RFC 4310 EPP DNS Security Extensions Mapping November 2005
2005年11月を写像するHollenbeck標準化過程[8ページ]RFC4310EPP DNSセキュリティ拡張子
create> element MUST contain one or more <secDNS:dsData> elements. Child elements of the <secDNS:dsData> element are described in Section 3.1.2.
>要素を作成してください。1<secDNS: dsData>要素を含まなければなりません。 <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>要素はOPTIONAL<secDNSを含んでいます: maxSigLife>と<secDNS: keyData>要素。 構文か方針理由でクライアントによって提供された値を受け入れることができないなら、サーバは、適切なEPP誤りでコマンド処理を中止して、反応しなければなりません。
Example <create> Command for a Secure Delegation:
例の<は安全な委譲のための>コマンドを作成します:
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バージョン=「=「UTF-8インチのスタンドアロン=」ノー、をコード化する1インチ」?>C: <epp xmlnsが等しい、「つぼ:ietf:params:xml:ナノ秒: epp1インチC:、」 xmlns: xsiは" http://www.w3.org/2001/XMLSchema-instance "Cと等しいです: xsi: schemaLocationが等しい、「つぼ:ietf:params: xml:ナノ秒:epp-1.0C:、」 epp-1.0.xsd、「>C:」 <コマンド>C: <は>Cを作成します: <ドメイン: Cを作成してください: xmlns: ドメイン=、「つぼ:ietf:params:xml:ナノ秒: ドメイン1インチC:、」 xsi: schemaLocationが等しい、「つぼ:ietf:params:xml:ナノ秒: ドメイン-1.0C:、」 ドメイン-1.0.xsd、「>C:」 <ドメイン: 名前>example.com</ドメイン: >をCと命名してください: <ドメイン: 期間の単位=、「y、「>2</ドメイン: 期間の>C:、」 <ドメイン: ナノ秒>C: <ドメイン: hostObj>ns1.example.com</ドメイン: hostObj>C: <ドメイン: hostObj>ns2.example.com</ドメイン: hostObj>C: </ドメイン: ナノ秒>C: <ドメイン: 記入者>jd1234</ドメイン: 記入者>C: <ドメイン: タイプ=に連絡してください、「アドミン、「>sh8013</ドメイン: >Cに連絡してください」 <ドメイン: タイプ=に連絡してください、「科学技術、「>sh8013</ドメイン: >Cに連絡してください」 <ドメイン: authInfo>C: <ドメイン: pw>2fooBAR</ドメイン: pw>C: </ドメイン: authInfo>C: </ドメイン: >Cを作成してください: </は>Cを作成します: <拡大>C: <secDNS: Cを作成してください: xmlns: secDNSが等しい、「つぼ:ietf:params:xml:ナノ秒: secDNS1インチC:、」 xsi: schemaLocationが等しい、「つぼ:ietf:params: xml:ナノ秒:secDNS-1.0C:、」 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: ダイジェスト>49FD46E6C4B45C55D4AC</secDNS: >Cを読みこなしてください: </secDNS: dsData>C: </secDNS: >を作成してください。
Hollenbeck Standards Track [Page 9] RFC 4310 EPP DNS Security Extensions Mapping November 2005
2005年11月を写像するHollenbeck標準化過程[9ページ]RFC4310EPP DNSセキュリティ拡張子
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:
例の<はSecure DelegationのためにOPTIONALデータで>Commandを作成します:
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: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:<?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: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>
Hollenbeck Standards Track [Page 10] RFC 4310 EPP DNS Security Extensions Mapping November 2005
Hollenbeck Standards Track [Page 10] RFC 4310 EPP DNS Security Extensions Mapping November 2005
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:keyData> C: </secDNS:dsData> C: </secDNS:create> C: </extension> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp>
When a <create> command has been processed successfully, the EPP response is as described in the EPP domain mapping [2].
When a <create> command has been processed successfully, the EPP response is as described in the EPP domain mapping [2].
3.2.2. EPP <delete> Command
3.2.2. EPP <delete> Command
This extension does not add any elements to the EPP <delete> command or <delete> response described in the EPP domain mapping [2].
This extension does not add any elements to the EPP <delete> command or <delete> response described in the EPP domain mapping [2].
3.2.3. EPP <renew> Command
3.2.3. EPP <renew> Command
This extension does not add any elements to the EPP <renew> command or <renew> response described in the EPP domain mapping [2].
This extension does not add any elements to the EPP <renew> command or <renew> response described in the EPP domain mapping [2].
3.2.4. EPP <transfer> Command
3.2.4. EPP <transfer> Command
This extension does not add any elements to the EPP <transfer> command or <transfer> response described in the EPP domain mapping [2].
This extension does not add any elements to the EPP <transfer> command or <transfer> response described in the EPP domain mapping [2].
3.2.5. EPP <update> Command
3.2.5. EPP <update> Command
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.
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.
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.
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.
The <secDNS:update> element also contains an OPTIONAL "urgent" attribute that a client can use to ask the server operator to
The <secDNS:update> element also contains an OPTIONAL "urgent" attribute that a client can use to ask the server operator to
Hollenbeck Standards Track [Page 11] RFC 4310 EPP DNS Security Extensions Mapping November 2005
Hollenbeck Standards Track [Page 11] RFC 4310 EPP DNS Security Extensions Mapping November 2005
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Example <update> Command, Adding DS Data:
Example <update> Command, Adding DS Data:
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: <update> C: <domain:update 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:update> C: </update> C: <extension> C: <secDNS:update
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: <update> C: <domain:update 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:update> C: </update> C: <extension> C: <secDNS:update
Hollenbeck Standards Track [Page 12] RFC 4310 EPP DNS Security Extensions Mapping November 2005
Hollenbeck Standards Track [Page 12] RFC 4310 EPP DNS Security Extensions Mapping November 2005
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: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, Removing DS Data:
Example <update> Command, Removing DS Data:
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: <update> C: <domain:update 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: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:rem> C: <secDNS:keyTag>12345</secDNS:keyTag> C: </secDNS:rem> C: </secDNS:update> C: </extension> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp>
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: <update> C: <domain:update 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: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:rem> C: <secDNS:keyTag>12345</secDNS:keyTag> C: </secDNS:rem> C: </secDNS:update> C: </extension> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp>
Hollenbeck Standards Track [Page 13] RFC 4310 EPP DNS Security Extensions Mapping November 2005
Hollenbeck Standards Track [Page 13] RFC 4310 EPP DNS Security Extensions Mapping November 2005
Example Urgent <update> Command, Changing DS Data:
Example Urgent <update> Command, Changing DS Data:
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: <update> C: <domain:update 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:update> C: </update> C: <extension> C: <secDNS:update urgent="1" 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:dsData> C: </secDNS:chg> C: </secDNS:update> C: </extension> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp>
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: <update> C: <domain:update 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:update> C: </update> C: <extension> C: <secDNS:update urgent="1" 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:dsData> C: </secDNS:chg> C: </secDNS:update> C: </extension> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp>
Example <update> Command, Changing Data to Include OPTIONAL Data:
Example <update> Command, Changing Data to Include OPTIONAL Data:
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: <update> C: <domain:update 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:<?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: <update> C: <domain:update 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">
Hollenbeck Standards Track [Page 14] RFC 4310 EPP DNS Security Extensions Mapping November 2005
Hollenbeck Standards Track [Page 14] RFC 4310 EPP DNS Security Extensions Mapping November 2005
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: <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>
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.
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.
4. Formal Syntax
4. Formal Syntax
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.
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.
Hollenbeck Standards Track [Page 15] RFC 4310 EPP DNS Security Extensions Mapping November 2005
Hollenbeck Standards Track [Page 15] RFC 4310 EPP DNS Security Extensions Mapping November 2005
BEGIN <?xml version="1.0" encoding="UTF-8"?>
BEGIN <?xml version="1.0" encoding="UTF-8"?>
<schema 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/XMLSchema"
elementFormDefault="qualified">
<schema 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/XMLSchema" elementFormDefault="qualified">
<annotation>
<documentation>
Extensible Provisioning Protocol v1.0
domain name extension schema for provisioning
DNS security (DNSSEC) extensions.
</documentation>
</annotation>
<annotation> <documentation> Extensible Provisioning Protocol v1.0 domain name extension schema for provisioning DNS security (DNSSEC) extensions. </documentation> </annotation>
<!--
Child elements found in EPP commands.
-->
<element name="create" type="secDNS:dsType"/>
<element name="update" type="secDNS:updateType"/>
<!-- Child elements found in EPP commands. --> <element name="create" type="secDNS:dsType"/> <element name="update" type="secDNS:updateType"/>
<!--
Child elements of the <create> command.
-->
<complexType name="dsType">
<sequence>
<element name="dsData" type="secDNS:dsDataType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
<!-- Child elements of the <create> command. --> <complexType name="dsType"> <sequence> <element name="dsData" type="secDNS:dsDataType" maxOccurs="unbounded"/> </sequence> </complexType>
<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="maxSigLife" type="secDNS:maxSigLifeType"
minOccurs="0"/>
<element name="keyData" type="secDNS:keyDataType"
minOccurs="0"/>
</sequence>
</complexType>
<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="maxSigLife" type="secDNS:maxSigLifeType" minOccurs="0"/> <element name="keyData" type="secDNS:keyDataType" minOccurs="0"/> </sequence> </complexType>
<simpleType name="maxSigLifeType">
<restriction base="int">
<minInclusive value="1"/>
<simpleType name="maxSigLifeType"> <restriction base="int"> <minInclusive value="1"/>
Hollenbeck Standards Track [Page 16] RFC 4310 EPP DNS Security Extensions Mapping November 2005
Hollenbeck Standards Track [Page 16] RFC 4310 EPP DNS Security Extensions Mapping November 2005
</restriction>
</simpleType>
</restriction> </simpleType>
<complexType name="keyDataType">
<sequence>
<element name="flags" type="unsignedShort"/>
<element name="protocol" type="unsignedByte"/>
<element name="alg" type="unsignedByte"/>
<element name="pubKey" type="secDNS:keyType"/>
</sequence>
</complexType>
<complexType name="keyDataType"> <sequence> <element name="flags" type="unsignedShort"/> <element name="protocol" type="unsignedByte"/> <element name="alg" type="unsignedByte"/> <element name="pubKey" type="secDNS:keyType"/> </sequence> </complexType>
<simpleType name="keyType">
<restriction base="base64Binary">
<minLength value="1"/>
</restriction>
</simpleType>
<simpleType name="keyType"> <restriction base="base64Binary"> <minLength value="1"/> </restriction> </simpleType>
<!--
Child elements of the <update> command.
-->
<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>
<!-- Child elements of the <update> command. --> <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 name="remType">
<sequence>
<element name="keyTag" type="unsignedShort"
maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="remType"> <sequence> <element name="keyTag" type="unsignedShort" maxOccurs="unbounded"/> </sequence> </complexType>
<!--
Child response elements.
-->
<element name="infData" type="secDNS:dsType"/>
<!-- Child response elements. --> <element name="infData" type="secDNS:dsType"/>
<!-- End of schema. --> </schema> END
<!-- End of schema. --> </schema> END
Hollenbeck Standards Track [Page 17] RFC 4310 EPP DNS Security Extensions Mapping November 2005
Hollenbeck Standards Track [Page 17] RFC 4310 EPP DNS Security Extensions Mapping November 2005
5. Internationalization Considerations
5. Internationalization Considerations
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 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.
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.
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.
6. IANA Considerations
6. IANA Considerations
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.
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.
Registration request for the extension namespace:
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
Registrant Contact: IESG
XML: None. Namespace URIs do not represent an XML specification.
XML: None. Namespace URIs do not represent an XML specification.
Registration request for the extension XML schema:
Registration request for the extension XML schema:
URI: urn:ietf:params:xml:schema:secDNS-1.0
URI: urn:ietf:params:xml:schema:secDNS-1.0
Registrant Contact: IESG
Registrant Contact: IESG
XML: See the "Formal Syntax" section of this document.
XML: See the "Formal Syntax" section of this document.
7. Security Considerations
7. Security Considerations
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.
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.
Hollenbeck Standards Track [Page 18] RFC 4310 EPP DNS Security Extensions Mapping November 2005
Hollenbeck Standards Track [Page 18] RFC 4310 EPP DNS Security Extensions Mapping November 2005
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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
Hollenbeck Standards Track [Page 19] RFC 4310 EPP DNS Security Extensions Mapping November 2005
Hollenbeck Standards Track [Page 19] RFC 4310 EPP DNS Security Extensions Mapping November 2005
operators SHOULD seriously consider adopting implementation rules to limit the range of acceptable signature lifetime values to counter potential adverse situations.
operators SHOULD seriously consider adopting implementation rules to limit the range of acceptable signature lifetime values to counter potential adverse situations.
8. Acknowledgements
8. Acknowledgements
The author would like to thank the following people who have provided significant contributions to the development of this document:
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.
David Blacka, Olafur Gudmundsson, Mark Kosters, Ed Lewis, Dan Massey, Marcos Sanz, Sam Weiler, and Ning Zhang.
9. References
9. References
9.1. Normative References
9.1. Normative References
[1] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
RFC 3730, March 2004.
[1] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", RFC 3730, March 2004.
[2] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain
Name Mapping", RFC 3731, March 2004.
[2] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", RFC 3731, March 2004.
[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] 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.
[4] Maloney, M., Beech, D., Mendelsohn, N., and H. Thompson, "XML
Schema Part 1: Structures", W3C REC REC-xmlschema-1-20010502,
May 2001.
[4] Maloney, M., Beech, D., Mendelsohn, N., and H. Thompson, "XML Schema Part 1: Structures", W3C REC REC-xmlschema-1-20010502, May 2001.
[5] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes", W3C
REC REC-xmlschema-2-20010502, May 2001.
[5] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes", W3C REC REC-xmlschema-2-20010502, May 2001.
[6] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
[6] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[7] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Protocol Modifications for the DNS Security Extensions",
RFC 4035, March 2005.
[7] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[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., and E. Lewis, "Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", RFC 3757, April 2004.
Hollenbeck Standards Track [Page 20] RFC 4310 EPP DNS Security Extensions Mapping November 2005
2005年11月を写像するHollenbeck標準化過程[20ページ]RFC4310EPP DNSセキュリティ拡張子
[10] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[10] 食事、M.、「IETF XML登録」、BCP81、RFC3688、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.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[12] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[12]Mockapetris、P.、「ドメイン名--、実現と仕様、」、STD13、RFC1035、11月1987日
[13] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033,
March 2005.
[13]はArendsします、R.、Austein、R.、ラーソン、M.、マッシー、D.、S.ローズと、「DNSセキュリティ序論と要件」(RFC4033)は2005を行進させます。
[14] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
STD 63, RFC 3629, November 2003.
[14]Yergeau、F.、「UTF-8、ISO10646インチ、STD63、RFC3629、11月2003日の変化形式
[15] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646",
RFC 2781, February 2000.
[15] ホフマン、P.とF.Yergeau、「UTF-16、ISO10646のコード化」RFC2781、2000年2月。
Author's Address
作者のアドレス
Scott Hollenbeck VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 US
スコットHollenbeckベリサインInc.21345屋根の頂円のヴァージニア20166-6503ダレス(米国)
EMail: shollenbeck@verisign.com
メール: shollenbeck@verisign.com
Hollenbeck Standards Track [Page 21] RFC 4310 EPP DNS Security Extensions Mapping November 2005
2005年11月を写像するHollenbeck標準化過程[21ページ]RFC4310EPP DNSセキュリティ拡張子
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Hollenbeck Standards Track [Page 22]
Hollenbeck標準化過程[22ページ]
一覧
スポンサーリンク
