Internet Engineering Task Force (IETF) J. Gould Request for Comments: 5910 S. Hollenbeck 廃止(Obsoletes): 4310 VeriSign, Inc. 分類: 標準化過程(Standards Track) 2010年5月 ISSN: 2070-1721 拡張可能な資源登録プロトコル (EPP) ドメインネームシステムセキュリティ拡張(DNSSEC)実装 要旨 本文書は、共有集中型リポジトリのドメイン名に対してDNSセキュリティ拡張 (DNSSEC)の資源登録・管理を行う、拡張可能な資源登録プロトコル(EPP)の 拡張実装を記述する。本実装はXMLにより規定されており、EPPドメイン名実装を 拡張する。これにより、DNSSECの資源登録に必要な追加機能が提供可能となる。 本文書はRFC 4310を廃止する。 本文書の位置づけ これはインターネット標準化過程(Standards Track)文書である。 本文書は、IETF(Internet Engineering Task Force)の成果物であり、 IETFコミュニティの合意を記載したものである。本文書は公開レビューを 受け、IESG(Internet Engineering Steering Group)の発行許可を得ている。 インターネット標準については、RFC 5741のセクション2に詳細な情報がある。 本文書の現在の状態、正誤表、フィードバック提供方法に関する情報は http://www.rfc-editor.org/info/rfc5910 で得られる。 Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Gould & Hollenbeck Standards Track [Page 1] RFC 5910 EPP DNS Security Extensions Mapping May 2010 This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. 本文書で使用する慣例 . . . . . . . . . . . . . . . . . . . 4 2. RFC 4310からの移行 . . . . . . . . . . . . . . . . . . . . . . 4 3. オブジェクトの属性 . . . . . . . . . . . . . . . . . . . . . . 5 3.1. DS(Delegation Signer)情報 . . . . . . . . . . . . . . . . 5 3.1.1. 公開鍵情報 . . . . . . . . . . . . . . . . . . . . . . 5 3.2. 真偽値 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. 署名最大有効期間 . . . . . . . . . . . . . . . . . . . . . 5 4. DS情報インターフェースと鍵情報インターフェース . . . . . . . . 6 4.1. DS情報インターフェース . . . . . . . . . . . . . . . . . . 7 4.2. 鍵情報インターフェース . . . . . . . . . . . . . . . . . . 7 4.3. DS情報インターフェースと鍵情報インターフェースの例 . . . . 8 5. EPPコマンド実装 . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. EPP 問合わせコマンド . . . . . . . . . . . . . . . . . . . 9 5.1.1. EPP コマンド . . . . . . . . . . . . . . . . . 9 5.1.2. EPP コマンド . . . . . . . . . . . . . . . . . 9 5.1.3. EPP コマンド . . . . . . . . . . . . . . . 13 5.2. EPP 変換コマンド . . . . . . . . . . . . . . . . . . . . . 14 5.2.1. EPP コマンド . . . . . . . . . . . . . . . . 14 5.2.2. EPP コマンド . . . . . . . . . . . . . . . . 17 5.2.3. EPP コマンド . . . . . . . . . . . . . . . . . 18 5.2.4. EPP コマンド . . . . . . . . . . . . . . . 18 5.2.5. EPP コマンド . . . . . . . . . . . . . . . . 18 6. 規格形式 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7. 国際化対応に関する考慮点 . . . . . . . . . . . . . . . . . . . 29 8. IANAに関する考慮点 . . . . . . . . . . . . . . . . . . . . . . 29 9. セキュリティに関する考慮点 . . . . . . . . . . . . . . . . . . 30 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 11.1. Normative References . . . . . . . . . . . . . . . . . . . 31 11.2. Informative References . . . . . . . . . . . . . . . . . . 32 付録A. RFC 4310からの変更点 . . . . . . . . . . . . . . . . . . . 33 Gould & Hollenbeck Standards Track [Page 2] RFC 5910 EPP DNS Security Extensions Mapping May 2010 1. はじめに 本文書は、RFC 5730[RFC5730]記載の拡張可能な資源登録プロトコル(EPP) バージョン1.0の拡張実装を記述する。本実装は、RFC 5731[RFC5731]記載の ドメイン名実装の拡張であり、XML(Extensible Markup Language) 1.0 [W3C.REC-xml-20001006]およびXMLスキーマ記法[W3C.REC-xmlschema-1-20010502] [W3C.REC-xmlschema-2-20010502]で規定される。 EPP中核プロトコル仕様[RFC5730]にEPPコマンドと応答の構造に関する完全な 記述がある。本文書の実装を理解するためには、この中核プロトコル仕様を 完全に理解していることが必要である。同様に、本文書に記述するDNSセキュリティ の概念を理解するためには、RFC 1034[RFC1034]とRFC 1035[RFC1035]に記述される DNSおよびRFC 4033[RFC4033]、RFC 4034[RFC4034]、RFC 4035[RFC4035]に 記述されるDNSSECに精通していることが必要である。 本文書に記述するEPP実装は、共有集中型リポジトリにDNSSECの資源登録 を行い、管理するための仕組みを規定する。本実装により交換される情報は リポジトリから取得可能で、それを用いてRFC 4034[RFC4034]記載のDNSSECの DS RR(Delegation Signer resource record)を公開することができる。 本文書はRFC 4310[RFC4310]を廃止する。従って、本文書で定義される secDNS-1.1によりsecDNS-1.0[RFC4310]は廃止見込みとなる。 RFC 4310[RFC4310]を廃止する動機となったものは以下の通りである。 ・要素を一意に指定しなくてもDS情報が削除できてしまう 問題を解決する。クライアントは、一意性が保証されたの 4要素全て(訳注:,,, )を使用して、削除するDS情報を明示的に指定すべきである。 ・単一コマンドで要素の追加・削除ができる機能を追加する。 これにより、RFC 5731[RFC5731]と整合が取れるようになる。 ・要素の使用法の明確化と修正を行う。RFC 4310[RFC4310]では、 はDS情報を置き換える際に使用されるものと定義した。 これは、要素をドメイン情報の属性値の変更時に使用するものと しているRFC 5731[RFC5731]と整合しない。 ・ 鍵情報のみを受理し、それを元にDS情報を生成する"手厚い"DNSSECサーバ 向けに、セクション4.2で記述する鍵情報インターフェースをサポートする。 Gould & Hollenbeck Standards Track [Page 3] RFC 5910 EPP DNS Security Extensions Mapping May 2010 1.1. 本文書で使用する慣例 本文書におけるキーワード"しなければならない(MUST)"、"してはならない (MUST NOT)"、"要求される(REQUIRED)"、"するものとする(SHALL)"、"しな いものとする(SHALL NOT)"、"すべきである(SHOULD)"、"すべきでない (SHOULD NOT)"、"推奨される(RECOMMENDED)"、"してもよい/することがで きる(MAY)"、"任意である(OPTIONAL)"は、BCP 14、RFC 2119[RFC2119]に 記述されているとおりに解釈するものとする。 例において、"C:"表記はプロトコルクライアントから送信される行を示し、 "S:"表記はプロトコルサーバから応答される行を示す。"////"表記は、 ページ内に収まるよう短縮表記された要素値を示すために用いられる。 インデント及びスペースは要素の関係を図示するためにのみ使用されるもの であり、本プロトコルに必須の仕様ではない。 XMLは大文字小文字を区別する。特に断りがなければ、本文書において提供される XML仕様および例示は、本仕様に準拠した実装の開発の際に、記述どおりの 文字型で解釈されなければならない(MUST)。 urn:ietf:params:xml:ns:secDNS-1.0の省略形としてsecDNS-1.0を用いる。 urn:ietf:params:xml:ns:secDNS-1.1の省略形としてsecDNS-1.1を用いる。 2. RFC 4310からの移行 本セクションでは、secDNS-1.0[RFC4310]からsecDNS-1.1に移行する際の、 クライアントとサーバに対する実装上の推奨事項を記述する。 本文書によりRFC 4310[RFC4310]は廃止見込みとなるので、サーバが secDNS-1.0 [RFC4310]とsecDNS-1.1の双方をサポートすると EPP で表明 している場合、両方のバージョンをサポートするクライアントはsecDNS-1.1の 使用を優先すべきである(SHOULD)。 サーバは、クライアントがsecDNS-1.0[RFC4310]から本文書で定義される secDNS-1.1に移行する際の助けとなるよう、以下のことをすべきである(SHOULD)。 1. secDNS-1.0[RFC4310]からsecDNS-1.1に移行中のサーバは、妥当な移行期間 の間、両バージョン(secDNS-1.0とsecDNS-1.1)をサポートすべきである (SHOULD)。 2. 応答においてサーバが返すべき要素の バージョンは、クライアントがEPP コマンドに含めていた (secDNS拡張を示す)要素の記述に従うべきである(SHOULD)。 この際、応答には下記の実装を用いる。 ・ EPP コマンドの要素中に urn:ietf:params:xml:ns:secDNS-1.1 が含まれている場合、 要素においてバージョンsecDNS-1.1を返す。 これは、EPP コマンドの要素中に urn:ietf:params:xml:ns:secDNS-1.0も含まれるかどうかに依存しない。 Gould & Hollenbeck Standards Track [Page 4] RFC 5910 EPP DNS Security Extensions Mapping May 2010 ・ EPP コマンドの要素中に urn:ietf:params:xml:ns:secDNS-1.0は含まれているが urn:ietf:params:xml:ns:secDNS-1.1は含まれていない場合、 要素においてバージョンsecDNS-1.0を返す。 ・ EPP コマンドの要素中に urn:ietf:params:xml:ns:secDNS-1.0と urn:ietf:params:xml:ns:secDNS-1.1のどちらも含まれない場合、 要素を返さない。 3. オブジェクトの属性 本拡張は、EPPドメイン名実装[RFC5731]に要素の追加を行う。ここでは新規 に追加する要素のみ記述する。 3.1. DS(Delegation Signer)情報 DS(Delegation Signer)情報は、子ゾーンがデジタル署名されており、また 子ゾーンの提示する鍵が子ゾーンの有効な署名鍵であると親ゾーンが認知 していることを示すために、親ゾーンのDNSサーバによって公開される。 DSリソースレコード(RR)は、鍵タグフィールド、鍵アルゴリズム番号オクテット、 ダイジェストアルゴリズムを指定するオクテット、ダイジェストフィールド という4つのフィールドを持つ。個々のフィールド形式については、 RFC 4034[RFC4034]を参照のこと。 3.1.1. 公開鍵情報 クライアントから提供された公開鍵情報は、RFC 4034[RFC4034]セクション 2.2で記述されるDNSKEY RRの表記フィールド形式で実装する。DNSKEY RRは、 フラグ、プロトコルオクテット、アルゴリズム番号オクテット、公開鍵という 4つのフィールドを持つ。 3.2. 真偽値 真偽値は、W3CによるXMLスキーマに関する推奨[W3C.REC-xmlschema-2-20010502] の 第2部に記述されるXMLスキーマ形式で表記されなければならない(MUST)。 3.3. 署名最大有効期間 署名最大有効期間(maxSigLife)は、子が提供したDS情報に対する親の署名の 有効期間(秒単位)に関する、任意(OPTIONAL)の子側の要求である。 maxSigLifeの値は、DS RRsetに対するRRSIGリソースレコード(RR)に適用される。 RRSIGリソースレコード(RR)の情報については、RFC 4034[RFC4034]のセクション3 を参照してほしい。 Gould & Hollenbeck Standards Track [Page 5] RFC 5910 EPP DNS Security Extensions Mapping May 2010 署名最大有効期間は要素に表記する。maxSigLifeの値は、 拡張XMLスキーマの"int"形式を用いて秒単位で表記しなければならない(MUST)。 基本"int"形式は、W3CによるXMLスキーマに関する推奨 [W3C.REC-xmlschema-2-20010502] の第2部に記述されるように、負の値を 取り得る。この値(署名最大有効期間)は更に制約が厳しく、最小値は1となる。 クライアントがmaxSigLifeを提供しない場合、またはサーバがクライアントの 指定するmaxSigLife値をサポートしていない場合は、サーバ管理者が使用する 署名期限ポリシー(本プロトコル外の仕組みで決定される)の定めるデフォルト値が 適用される。 4. DS情報インターフェースと鍵情報インターフェース 本文書は、ドメイン名のDS情報または鍵情報をクライアントが生成・追加・削除 可能な運用シナリオを記述する。サーバがサポート可能なインターフェースとして 異なる2つの形式が存在する。1つめは"DS情報インターフェース"と称するもので、 クライアントはDS情報の生成・追加・削除に責任を持つ。サーバは、 応答においてDS情報を返すことができる必要がある。2つめのものは"鍵情報 インターフェース"と称するもので、クライアントは鍵情報の生成・追加・削除に 責任を持つ。サーバは、応答において鍵情報を返すことができる 必要がある。 サーバが1つのコマンド・応答の中でサポートするのは、1つのインターフェース 形式でなければならない(MUST)。したがって、サーバ側での検証のために をの子要素とする場合を除いて、 とを混在させてはならない(MUST NOT)。 サーバは、両形式をサポートすることができる(MAY)移行期間中を除いて、 、、要素全てについて、 サポートするのはどちらか1つのインターフェース形式でなければならない (MUST)。つまり、移行期間中は、サーバはドメイン単位でDS情報インターフェース と鍵情報インターフェースのいずれをサポートしてもよく(MAY)、これにより クライアントのインターフェース移行を可能としている。 クライアントは、true要素 を用いて古いインターフェースの全情報を削除し、要素を用いて 新しいインターフェースの情報(DS情報インターフェースの場合は、 鍵情報インターフェースの場合は)を追加することで、 使用インターフェースを移行できる。サーバは、サポートしていない インターフェースのコマンドを受信した場合、EPPエラーコード2306を 返さなければならない(MUST)。 Gould & Hollenbeck Standards Track [Page 6] RFC 5910 EPP DNS Security Extensions Mapping May 2010 4.1. DS情報インターフェース DS情報インターフェースは、情報の生成・追加・削除と応答で 要素を使用する。クライアントは、DS情報に対応する鍵情報も 提供できる(MAY)が、サーバに当該鍵情報の使用を強制するものではない。 サーバ管理者は、受理したDS情報を検証する目的から、当該ドメイン名の ゾーン頂点の鍵情報を得るために、EPPの範囲外の(訳注: 通常のDNSプロトコルを 使用した)DNS検索を行ってもよい(MAY)。子ゾーン管理者は、親ゾーン管理者が 必要に応じて検証できるよう、DNSツリーにおいて当該鍵情報をオンラインで 保持する(訳注: DNSKEYとして公開する)ことが推奨される(RECOMMENDED)。 鍵情報には、RFC 3757[RFC3757]・RFC 4034 [RFC4034]の記述どおりにセキュア エントリーポイント(SEP)ビットを設定すべきである(SHOULD)。 要素は、次の子要素を含む。 ・ RFC 4034[RFC4034]のセクション5.1.1に記述される鍵タグ値を含む 要素。要素は "unsignedShort" [W3C.REC-xmlschema-2-20010502]で記述する。 ・ RFC 4034[RFC4034]のセクション5.1.2に記述されるアルゴリズム値を 含む要素。 ・ RFC 4034[RFC4034]のセクション5.1.3に記述されるダイジェストタイプ値を 含む要素。 ・ RFC 4034[RFC4034]のセクション5.1.4に記述されるダイジェスト値を含む 要素。要素は "hexBinary" [W3C.REC-xmlschema-2-20010502]で記述する。 ・ サーバ側の検証で行われるDSハッシュ計算への入力値として使用される 鍵情報を記述する任意の(OPTIONAL)要素。 要素はセクション4.2で定義される子要素を含む。 4.2. 鍵情報インターフェース 鍵情報インターフェースは、情報の生成・追加・削除と応答で 要素を使用する。クライアントはDS情報を提供せず、サーバが これを生成する。DS情報の生成で使用されるパラメータはサーバのポリシーに 基づいて決定されるので、クライアント-サーバ間でやりとりされるものは 鍵情報のみとなる。 Gould & Hollenbeck Standards Track [Page 7] RFC 5910 EPP DNS Security Extensions Mapping May 2010 要素は、次の子要素を含む。 ・ RFC 4034[RFC4034]のセクション2.1.1に記述されるフラグフィールド値を 含む要素。 ・ RFC 4034[RFC4034]のセクション2.1.2に記述されるプロトコルフィールド値を 含む要素。 ・ RFC 4034[RFC4034]のセクション2.1.3に記述されるアルゴリズム番号 フィールド値を含む要素。 ・ RFC 4034[RFC4034]のセクション2.1.4に記述されるエンコードされた公開鍵 フィールド値を含む要素。要素は最短長が 1の"base64Binary"[W3C.REC-xmlschema-2-20010502]で記述する。 4.3. DS情報インターフェースと鍵情報インターフェースの例 secDNS-1.1のDS情報インターフェースにおけるDS情報の生成例： 12345 3 1 49FD46E6C4B45C55D4AC secDNS-1.1のDS情報インターフェースにおける任意の(OPTIONAL) 鍵情報を伴うDS情報の生成例： 12345 3 1 49FD46E6C4B45C55D4AC 257 3 1 AQPJ////4Q== Gould & Hollenbeck Standards Track [Page 8] RFC 5910 EPP DNS Security Extensions Mapping May 2010 secDNS-1.1の鍵情報インターフェースにおける鍵情報の生成例： 257 3 1 AQPJ////4Q== 5. EPPコマンド実装 EPPの形式(syntax)・意味(semantics)の詳細についてはEPP中核プロトコル仕様 [RFC5730]に記載がある。ここで記述するコマンド実装は、EPPによるDNSSECの 資源登録・管理に特化したものである。 5.1. EPP 問合わせコマンド EPPはオブジェクト情報を検索する3つのコマンドを提供する。オブジェクトの 情報をサーバが保持しているかを確認するコマンド、オブジェクトの 詳細情報を取得するコマンド、オブジェクトの移転状況に関する情報を 取得するコマンドである。 5.1.1. EPP コマンド 本拡張では、EPPドメイン実装[RFC5731]に記述されるEPP コマンド、 応答に対し、要素の追加は行わない。 5.1.2. EPP コマンド 本拡張では、EPPドメイン実装[RFC5731]に記述されるEPP コマンドに対し、 要素の追加は行わない。ただし、応答については追加要素を定義する。 コマンドが正常に処理された場合、EPP 要素は、EPPドメイン 実装[RFC5731]に記述される子要素を含まなければならない(MUST)。 更に、ドメインオブジェクトが本拡張に関連するサーバポリシーに基づく情報を 持つ場合、要素は拡張名前空間を特定する子要素を 含むべきである(SHOULD)。要素は以下の子要素を含む。 ・ 子が提供したDS情報に対する親の署名の有効期間(秒単位)に関する、 子の要求を示す任意の(OPTIONAL)要素。 maxSigLifeについてはセクション3.3に記載がある。 Gould & Hollenbeck Standards Track [Page 9] RFC 5910 EPP DNS Security Extensions Mapping May 2010 ・ 1つ以上のまたはのいずれかの要素。 セクション4の定義に従い、どちらか一方で両方同時には含まれない。 要素は、クライアントが提示する当該ドメインのDS情報を 記述する。要素は、クライアントが提示する当該ドメインの 鍵情報を記述する。要素の子要素についてはセクション4.1に 記載がある。同様に、要素の子要素についてはセクション4.2 に記載がある。 DS情報インターフェースにおいて"Secure"な委任情報を返す応答の例： S: S: S: S: S: Command completed successfully S: S: S: S: example.com S: EXAMPLE1-REP S: S: jd1234 S: sh8013 S: sh8013 S: S: ns1.example.com S: ns2.example.com S: S: ns1.example.com S: ns2.example.com S: ClientX S: ClientY S: 1999-04-03T22:00:00.0Z S: ClientX S: 1999-12-03T09:00:00.0Z S: 2005-04-03T22:00:00.0Z S: 2000-04-08T09:00:00.0Z S: S: 2fooBAR S: S: S: S: S: S: S: 12345 S: 3 S: 1 S: 49FD46E6C4B45C55D4AC S: S: S: S: S: ABC-12345 S: 54322-XYZ S: S: S: DS情報インターフェースにおいて、任意の(OPTIONAL)鍵情報を伴う"Secure"な 委任情報を返す応答の例： S: S: S: S: S: Command completed successfully S: S: S: S: example.com S: EXAMPLE1-REP S: S: jd1234 S: sh8013 S: sh8013 S: S: ns1.example.com S: ns2.example.com S: S: ns1.example.com S: ns2.example.com S: ClientX S: ClientY S: 1999-04-03T22:00:00.0Z S: ClientX S: 1999-12-03T09:00:00.0Z S: 2005-04-03T22:00:00.0Z S: 2000-04-08T09:00:00.0Z Gould & Hollenbeck Standards Track [Page 11] RFC 5910 EPP DNS Security Extensions Mapping May 2010 S: S: 2fooBAR S: S: S: S: S: S: 604800 S: S: 12345 S: 3 S: 1 S: 49FD46E6C4B45C55D4AC S: S: 257 S: 3 S: 1 S: AQPJ////4Q== S: S: S: S: S: S: ABC-12345 S: 54322-XYZ S: S: S: 鍵情報インターフェースにおいて、"Secure"な委任情報を返す応答の例： S: S: S: S: S: Command completed successfully S: S: S: S: example.com S: EXAMPLE1-REP S: S: jd1234 S: sh8013 Gould & Hollenbeck Standards Track [Page 12] RFC 5910 EPP DNS Security Extensions Mapping May 2010 S: sh8013 S: S: ns1.example.com S: ns2.example.com S: S: ns1.example.com S: ns2.example.com S: ClientX S: ClientY S: 1999-04-03T22:00:00.0Z S: ClientX S: 1999-12-03T09:00:00.0Z S: 2005-04-03T22:00:00.0Z S: 2000-04-08T09:00:00.0Z S: S: 2fooBAR S: S: S: S: S: S: S: 257 S: 3 S: 1 S: AQPJ////4Q== S: S: S: S: S: ABC-12345 S: 54322-XYZ S: S: S: コマンドが何らかの理由により処理できなかった場合、EPPエラー応答を 返さなければならない(MUST)。 5.1.3. EPP コマンド 本拡張では、EPPドメイン実装[RFC5731]に記述されるEPP コマンド、 応答に対し、要素の追加は行わない。 Gould & Hollenbeck Standards Track [Page 13] RFC 5910 EPP DNS Security Extensions Mapping May 2010 5.2. EPP 変換コマンド EPPはオブジェクトを変換する5つのコマンドを提供する。オブジェクトの インスタンスを生成するコマンド、オブジェクトのインスタンスを 削除するコマンド、オブジェクトの有効期間を延長するコマンド、 オブジェクトの管理権限の変更を管理するコマンド、オブジェクトに 関連する情報を変更するコマンドである。 5.2.1. EPP コマンド 本拡張では、EPPドメイン実装[RFC5731]に記述されるEPP コマンドに 対し、追加の要素を定義する。EPP 応答に対しては、追加の要素を 定義しない。 EPP コマンドは、クライアントに対して、ドメインオブジェクトを 生成する変換処理を提供する。クライアントが、本拡張仕様が定義する情報を ドメインオブジェクトに関連づけたい場合、EPPドメイン実装[RFC5731]に記述 されるEPPコマンド要素に加えて、本コマンドは要素を含まなければ ならず(MUST)、また要素は拡張名前空間を特定する 子要素を含まなければならない(MUST)。 要素は以下の子要素を含む。 ・ 子が提供したDS情報に対する親の署名の有効期間(秒単位)に関する、 子の要求を示す任意の(OPTIONAL)要素。 maxSigLifeについてはセクション3.3に記載がある。サーバが 要素をサポートしていない場合、EPPエラーコード2102を 返さなければならない(MUST)。 ・ セクション4で定義される0個以上のまたは のいずれかの要素。要素の子要素に ついてはセクション4.1に記載がある。要素の子要素に ついてはセクション4.2に記載がある。 Gould & Hollenbeck Standards Track [Page 14] RFC 5910 EPP DNS Security Extensions Mapping May 2010 DS情報インターフェースにおいて、"Secure"な委任情報を生成する コマンドの例： C: C: C: C: C: C: example.com C: 2 C: C: ns1.example.com C: ns2.example.com C: C: jd1234 C: sh8013 C: sh8013 C: C: 2fooBAR C: C: C: C: C: C: 604800 C: C: 12345 C: 3 C: 1 C: 49FD46E6C4B45C55D4AC C: C: C: C: ABC-12345 C: C: Gould & Hollenbeck Standards Track [Page 15] RFC 5910 EPP DNS Security Extensions Mapping May 2010 DS情報インターフェースにおいて、任意の(OPTIONAL)鍵情報を伴う"Secure"な 委任情報を生成するコマンドの例： C: C: C: C: C: C: example.com C: 2 C: C: ns1.example.com C: ns2.example.com C: C: jd1234 C: sh8013 C: sh8013 C: C: 2fooBAR C: C: C: C: C: C: 604800 C: C: 12345 C: 3 C: 1 C: 49FD46E6C4B45C55D4AC C: C: 257 C: 3 C: 1 C: AQPJ////4Q== C: C: C: C: C: ABC-12345 C: C: Gould & Hollenbeck Standards Track [Page 16] RFC 5910 EPP DNS Security Extensions Mapping May 2010 鍵情報インターフェースにおいて、"Secure"な委任情報を生成するコマンド の例： C: C: C: C: C: C: example.com C: 2 C: C: ns1.example.com C: ns2.example.com C: C: jd1234 C: sh8013 C: sh8013 C: C: 2fooBAR C: C: C: C: C: C: C: 257 C: 3 C: 1 C: AQPJ////4Q== C: C: C: C: ABC-12345 C: C: コマンドの処理が成功した際のEPP応答は、EPPドメイン実装[RFC5731] の記載どおりのものになる。 5.2.2. EPP コマンド 本拡張では、EPPドメイン実装[RFC5731]に記述されるEPP コマンド、 応答に対し、要素の追加は行わない。 Gould & Hollenbeck Standards Track [Page 17] RFC 5910 EPP DNS Security Extensions Mapping May 2010 5.2.3. EPP コマンド 本拡張では、EPPドメイン実装[RFC5731]に記述されるEPP コマンド、 応答に対し、要素の追加は行わない。 5.2.4. EPP コマンド 本拡張では、EPPドメイン実装[RFC5731]に記述されるEPP コマンド、 応答に対し、要素の追加は行わない。 5.2.5. EPP コマンド 本拡張では、EPPドメイン実装[RFC5731]に記述されるEPP コマンド に対し、追加の要素を定義する。EPP 応答に対しては、追加の要素は 定義しない。 EPP コマンドは、クライアントに対して、ドメインオブジェクトの 属性を変更する変換処理を提供する。クライアントが、本拡張仕様が定義する 情報を含むドメインオブジェクトを更新したい場合、EPPドメイン実装に記述 されるEPPコマンド要素に加えて、本コマンドは要素を含まなければ ならず(MUST)、また要素は拡張名前空間を特定する 子要素を含まなければならない(MUST)。要素は、 ゾーン委任にDNSSEC情報を追加する要素、ゾーン委任から DNSSEC情報を削除する要素、既存のDNSSEC情報を変更する 要素のいずれかを含む。要素、要素、 または要素のうち、少なくとも1つは提供されなければならない (MUST)。サーバは、新しい要素の追加に先立ち既存の要素を削除しなければ ならない(MUST)ので、要素と要素の順序は重要である。 また、要素は、任意の(OPTIONAL)"urgent"属性を含む。 これを使用して、クライアントは当該更新要求の処理を、高い優先度で行うよう サーバ管理者に依頼することができる。この属性はセクション3.2の記載どおり 真偽値を取り、デフォルト値は"false"である。"高い優先度"とは、EPPの範囲外の 仕組みで決定されるサーバ管理者の標準的なポリシーの枠内で優先度が高い という意味である。"urgent"属性に"true"が指定されているが、サーバがこれを サポートしていない場合、EPPエラーコード2102を返さなければならない(MUST)。 サーバが"urgent"属性をサポートしているが、("urgent"属性に"true"が指定 されている)緊急更新要求の処理を高い優先度で実行できない場合、EPPエラー コード2306を返さなければならない(MUST)。 Gould & Hollenbeck Standards Track [Page 18] RFC 5910 EPP DNS Security Extensions Mapping May 2010 要素は以下の子要素を含む。 ・ 委任からDNSSEC情報を削除するために使用する、任意の(OPTIONAL) 要素。この要素は要素、もしくは1つ以上の 要素または要素を含む。 要素の真偽値を"true"に指定することで、全てのDS情報と 鍵情報を削除することができる。真偽値を"false"に指定した場合、何も 実行されない。DS情報を全て削除すると、親ゾーンから子ゾーンへの委任が "Secure"なものではなくなる。 要素はDS情報インターフェースに属するものであり、 削除すべき DSレコードを一意に指定するために用いる。この指定においては、 、、、 の4要素全てを使用することで一意性を保証する。 要素は鍵情報インターフェースに属するものであり、削除すべき 鍵情報を一意に指定するために用いる。この指定においては、 、、、 の4要素全てを使用することで一意性を保証する。1つの鍵に対して複数の DSレコードが生成されることがあるため、1つの鍵情報を削除すると複数の DSレコードが削除される可能性がある。 ・ 既存の情報に対してDNSSEC情報を追加するために使用する、任意の(OPTIONAL) 要素。要素には、1つ以上の 要素または要素を含めなければならない(MUST)。 要素の子要素についてはセクション4.1に記載がある。 要素の子要素についてはセクション4.2に記載がある。 ・ 変更すべきDNSSEC情報を含む任意の(OPTIONAL)要素。 要素は以下の子要素を含む。 * 子が提供したDS情報に対する親の署名の有効期間(秒単位)に関する、 任意(OPTIONAL)の子側の要求を示す 要素。 maxSigLifeについてはセクション3.3に記載がある。サーバが 要素をサポートしていない場合、 EPPエラーコード2102を返さなければならない(MUST)。 Gould & Hollenbeck Standards Track [Page 19] RFC 5910 EPP DNS Security Extensions Mapping May 2010 DS情報インターフェースにおいてDS情報の追加・削除を行うコマンド の例： C: C: C: C: C: C: example.com C: C: C: C: C: C: C: 12345 C: 3 C: 1 C: 38EC35D5B3A34B33C99B C: C: C: C: C: 12346 C: 3 C: 1 C: 38EC35D5B3A34B44C39B C: C: C: C: C: ABC-12345 C: C: Gould & Hollenbeck Standards Track [Page 20] RFC 5910 EPP DNS Security Extensions Mapping May 2010 maxSigLifeを更新するコマンドの例： C: C: C: C: C: C: example.com C: C: C: C: C: C: 605900 C: C: C: C: ABC-12345 C: C: Gould & Hollenbeck Standards Track [Page 21] RFC 5910 EPP DNS Security Extensions Mapping May 2010 鍵情報インターフェースにおいて鍵情報の追加・削除とmaxSigLifeの設定を 行うコマンドの例： C: C: C: C: C: C: example.com C: C: C: C: C: C: C: 257 C: 3 C: 1 C: AQPJ////4QQQ C: C: C: C: C: 257 C: 3 C: 1 C: AQPJ////4Q== C: C: C: C: 605900 C: C: C: C: ABC-12345 C: C: Gould & Hollenbeck Standards Track [Page 22] RFC 5910 EPP DNS Security Extensions Mapping May 2010 DS情報インターフェースにおいて要素を用いてDS情報の削除を 行うコマンドの例： C: C: C: C: C: C: example.com C: C: C: C: C: C: C: 12346 C: 3 C: 1 C: 38EC35D5B3A34B44C39B C: C: C: C: C: ABC-12345 C: C: Gould & Hollenbeck Standards Track [Page 23] RFC 5910 EPP DNS Security Extensions Mapping May 2010 要素の子要素を用いて全てのDS情報・鍵情報の 削除を行うコマンドの例： C: C: C: C: C: C: example.com C: C: C: C: C: C: true C: C: C: C: ABC-12345 C: C: Gould & Hollenbeck Standards Track [Page 24] RFC 5910 EPP DNS Security Extensions Mapping May 2010 DS情報インターフェースにおいて全てのDS情報の緊急更新を行う コマンドの例： C: C: C: C: C: C: example.com C: C: C: C: C: C: true C: C: C: C: 12346 C: 3 C: 1 C: 38EC35D5B3A34B44C39B C: C: C: C: C: ABC-12345 C: C: コマンドの処理が成功した際のEPP応答は、EPPドメイン実装 [RFC5731]の記載どおりのものになる。 6. 規格形式 EPPオブジェクト実装はXMLスキーマ記法により規定される。ここで提示する 規格形式は、EPPのXMLインスタンスを自動検証するのに適した、本オブジェクト 実装の完全なスキーマ表記である。BEGIN/ENDタグはスキーマに含まれない。 これらはURI登録の際に、スキーマの初めと終りを記述するために使用される。 Copyright (c) 2010 IETF Trust and the persons identified as authors of the code. All rights reserved. Gould & Hollenbeck Standards Track [Page 25] RFC 5910 EPP DNS Security Extensions Mapping May 2010 Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: - Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. - Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. - Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. BEGIN Extensible Provisioning Protocol v1.0 domain name extension schema for provisioning DNS security (DNSSEC) extensions. Gould & Hollenbeck Standards Track [Page 26] RFC 5910 EPP DNS Security Extensions Mapping May 2010 Gould & Hollenbeck Standards Track [Page 27] RFC 5910 EPP DNS Security Extensions Mapping May 2010 Gould & Hollenbeck Standards Track [Page 28] RFC 5910 EPP DNS Security Extensions Mapping May 2010 END 7. 国際化対応に関する考慮点 EPPはXMLで記述されており、XMLはUnicode文字集合によるエンコーディング 情報と更にコンパクトなUTF-8[RFC3629]などの表記を元来サポートしている。 XML準拠の処理系は、UTF-8とUTF-16[RFC2781]の双方を認識する。XMLでは、 宣言中のencoding属性により、他エンコーディングの指定・使用が 可能であるが、パーサがサポートするエンコーディングの互換性が不十分な 環境では、UTF-8を使用することが推奨される(RECOMMENDED)。 EPPドメイン実装[RFC5731]の拡張として、EPPドメイン実装[RFC5731]の国際化 対応に関する要求は、本拡張仕様においても引き継がれる。本拡張仕様は、 EPPドメイン実装[RFC5731]の国際化対応に関するいかなる仕様も変更しない。 8. IANAに関する考慮点 本文書では、RFC 3688[RFC3688]に記述されるレジストリの仕組みに準拠した XML名前空間・XMLスキーマを記述するためにURNを使用している。IANAによって 2つのURI割当が行われている。 拡張名前空間についての登録要求: URI: urn:ietf:params:xml:ns:secDNS-1.1 登録担当者: IESG XML: なし。名前空間のURIはXML仕様を表さない。 拡張XMLスキーマについての登録要求: URI: urn:ietf:params:xml:schema:secDNS-1.1 Gould & Hollenbeck Standards Track [Page 29] RFC 5910 EPP DNS Security Extensions Mapping May 2010 登録担当者: IESG XML: 本文書の"規格形式"セクションを参照のこと。 9. セキュリティに関する考慮点 本文書に記述する拡張実装は、EPP[RFC5730]、EPPドメイン名実装[RFC5731]、 およびEPPが使用するプロトコル層で記述される以上のいかなるセキュリティ サービスをも提供しない。これらの仕様で記述されたセキュリティに関する 考慮点は、本仕様に対しても適用される。 本文書に記述するEPP変換処理は、他のドメインオブジェクト変換と同様に、 RFC 5730[RFC5730]のセクション2.9.1.1およびセクション7に記述される方式で 認証された管理クライアントだけに制限しなければならない(MUST)。 管理クライアントでないクライアントからのドメインオブジェクトに対する あらゆる変換処理の試みは、適切なEPP認証エラーにより拒否しなければならない (MUST)。 本文書に記述する資源登録サービスは、DNSの運用に影響を与え得る情報の 交換を行う。したがって、EPPクライアントとサーバの間には信頼関係が成立して いなければならず(MUST)、また公開鍵情報の資源登録は、強力な認証の仕組みを 使用してクライアント・サーバ双方の正当性を確認した後にだけ行えるように しなければならない(MUST)。 EPPクライアントは、ゾーン管理者がゾーン委任情報をサーバ管理者に送付し、 署名・公開してもらいたいような場合に、仲介役として機能する可能性がある。 したがって、クライアント上で直接何らかの処理をしたり、不用意にデータ 操作を行う場合、中間者(man-in-the-middle)攻撃が発生し得る。 サーバ管理者が不正な鍵を受理してしまうと、深刻な運用上の問題を 引き起こす。子ゾーンと親ゾーンは、委任情報の適切な保全において一貫して いなければならない(MUST)。署名された委任情報に一貫性がない場合、 そのゾーン委任はDNSSECの名前空間には現れず、問合わせに対し信頼できない (訳注: Bogus(検証失敗：信頼禁止)と認識される)応答が返される。 鍵が漏洩した場合、クライアントは漏洩した鍵情報を削除するか、 "urgent"属性を指定したEPPコマンドを使用して委任情報の更新を行うか、 どちらかを選択することができる。 "Secure"なドメイン委任を短時間で削除する運用シナリオは、2段階の処理で 実装できる。はじめに、上述の"urgent"属性を"true"に指定した更新を使用して、 セキュリティ情報を削除する。次に、ドメインの状態値をEPPの "clientHold" または"serverHold"に変更することにより、当該ドメインを親ゾーンから 削除できるようになる。当該ドメインをEPP コマンドを用いて 削除することもできるが、これは注意深い検討が必要となる思い切った 処理段階である。 Gould & Hollenbeck Standards Track [Page 30] RFC 5910 EPP DNS Security Extensions Mapping May 2010 サーバにおけるデータ検証やDSレコード生成には計算リソースを必要とする。 クライアントがサーバの処理能力を超えるような数の更新処理要求を行うことで、 故意または不慮によるサービス不能攻撃(denial-of-service attack)が可能 である。サーバ管理者は、サービス不能攻撃の危険性を最小化するために、 コマンド負荷やコマンド処理要求の管理について対策を講じるべきである (SHOULD)。 クライアントから示される署名最大有効期間への要求は拒否できる。 サーバ管理者が分別無しに受理を行うと、サーバの処理能力に悪影響を及ぼす 可能性がある。サーバ管理者は、潜在的な問題の発生を防ぐために、署名最大 有効期間値の許容範囲を制限する実装ルールの採用を真剣に検討すべきである (SHOULD)。 10. Acknowledgements The authors would like to thank the following people who have provided significant contributions to the development of this document: David Blacka, Howard Eland, Patrik Faltstrom, Olafur Gudmundsson, Bernie Hoeneisen, Ed Lewis, Klaus Malorny, Alexander Mayrhofer, Patrick Mevzek, David Smith, Andrew Sullivan, and Srikanth Veeramachaneni. This document replaces RFC 4310 [RFC4310]. Please see the Acknowledgements section in that RFC for additional acknowledgements. This document incorporates feedback from early implementers on the PROVREG mailing list and users. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", RFC 3757, April 2004. Gould & Hollenbeck Standards Track [Page 31] RFC 5910 EPP DNS Security Extensions Mapping May 2010 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, August 2009. [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", STD 69, RFC 5731, August 2009. [W3C.REC-xml-20001006] Maler, E., Sperberg-McQueen, C., Bray, T., and J. Paoli, "Extensible Markup Language (XML) 1.0 (Second Edition)", World Wide Web Consortium FirstEdition REC-xml-20001006, October 2000, . [W3C.REC-xmlschema-1-20010502] Beech, D., Thompson, H., Mendelsohn, N., and M. Maloney, "XML Schema Part 1: Structures", World Wide Web Consortium FirstEdition REC-xmlschema-1-20010502, May 2001, . [W3C.REC-xmlschema-2-20010502] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes", World Wide Web Consortium FirstEdition REC-xmlschema-2- 20010502, May 2001, . 11.2. Informative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. Gould & Hollenbeck Standards Track [Page 32] RFC 5910 EPP DNS Security Extensions Mapping May 2010 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4310] Hollenbeck, S., "Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)", RFC 4310, December 2005. Gould & Hollenbeck Standards Track [Page 33] RFC 5910 EPP DNS Security Extensions Mapping May 2010 付録A. RFC 4310からの変更点 1. セクション1にRFC 4310[RFC4310]を廃止する動機を追加した。 2. セクション1を更新し、RFC 4310が廃止見込みであることを明記した。 3. セクション1.1にsecDNS-1.0、secDNS-1.1の省略形表記の定義を追加した。 4. セクション9の"サーバにおけるデータ検証には...という記述を "サーバにおけるデータ検証やDSレコード生成には..."に更新した。 5. セクション2を追加した。 6. セクション7の2段落目を更新し、国際化対応に関する要求が[RFC5731]に従う ことを明記した。 7. をの前に移動した。これにより、EPPの順序制約に 準拠する形で、全データを削除する際にの子要素として をサポートしたり、これまでが担っていた 置き換え機能をサポートできるようになった。 8. の子要素として真偽値を取る要素のサポートを 追加した。これにより、の代わりに全てのDS情報・鍵情報の 削除ができるようになった。 9. 、、の機能を更新し、他のEPPに 関するRFCと整合をとった。 10. のみを使用するのサポートを中止した。 11. 要素を及び 要素の配下から外し、要素、要素の 子要素、要素の直下に移動した。 セクション3.3の記述を更新してをより正しく記述し、 また文書全体を通してに関する記述を更新した。 12. セクション8の記述を更新し、IANAによって割り当てられたURIを urn:ietf:params:xml:schema:secDNS-1.0 から urn:ietf:params:xml:schema:secDNS-1.1 に置き換えた。 Gould & Hollenbeck Standards Track [Page 34] RFC 5910 EPP DNS Security Extensions Mapping May 2010 13. セクション4.1に "要素は"unsignedShort" [W3C.REC-xmlschema-2-20010502]で記述する"という説明を追加した。 14. セクション4.1に "要素は"hexBinary" [W3C.REC-xmlschema-2-20010502]で記述する"という説明を追加した。 15. セクション4.2に "要素は最短長が1である"base64Binary" [W3C.REC-xmlschema-2-20010502]で記述する"という説明を追加した。 16. セクション5.2.1とセクション5.2.5に "本コマンドは要素を 含まなければならず(MUST)"という説明を追加した。 17. セクション5.2.1とセクション5.2.5に "サーバが要素を サポートしていない場合、EPPエラーコード2102を返さなければならない (MUST)"という説明を追加した。 18. セクション10に "本文書はRFC 4310を置き換える。本文書に記述した人々に 加えて謝意を表されるべき人々については該当RFCを参照してもらいたい" という説明を追加した。 19. "謝辞" セクションに、"本文書はPROVREGメーリングリストの実装者と ユーザからのフィードバックを採り入れている" という記述を追加し、 また要旨に "本文書はRFC 4310を廃止する"という記述を追加した。 20. xsi:schemaLocationの記述を削除し、他のEPP関連のRFCと整合をとった。 21. "DS情報インターフェースと鍵情報インターフェース"セクションを 追加した。 22. "DS(Delegation Signer)情報の生成、追加、削除、置換"に関する段落を "オブジェクトの属性"セクションから"DS情報インターフェース" セクションに移動した。 23. "EPP コマンド"セクションにおける要素の記述を変更し、 "DS情報インターフェース"セクションの要素と "鍵情報インターフェース"セクションの要素の記述を 参照するようにした。 24. "EPP コマンド"セクションの例を更新し、DS情報インターフェース および鍵情報インターフェースの両方を含むようにした。 25. "EPP コマンド"セクションの記述を変更し、"DS情報インター フェース" セクションの要素と、"鍵情報インターフェース" セクションの 要素の両方を参照するようにした。 26. "EPP コマンド"セクションの例を更新し、DS情報インターフェース と鍵情報インターフェースの両方を含むようにした。 Gould & Hollenbeck Standards Track [Page 35] RFC 5910 EPP DNS Security Extensions Mapping May 2010 27. "EPP コマンド"セクションを更新し、、、 要素の使用法を一緒に記述した。 28. "EPP コマンド"セクションの例を更新し、DS情報インターフェース と鍵情報インターフェースの両方を含むようにした。またDS情報または鍵情報 の追加・削除の例を追加した。 29. "規格形式"セクションを更新し、新しいXMLスキーマに対応した。 30. "謝辞"セクションを更新し、最新の貢献者リストとした。 31. 参考文献として挙げられていたRFC 3730をRFC 5730に変更した。 32. 参考文献として挙げられていたRFC 3731をRFC 5731に変更した。 33. どのような場合に、各コマンド・応答(、 、)を拡張しなければならない (MUST)かを明確化する記述を追加した。 34. "更に、EPP 要素は、拡張名前空間と拡張スキーマの 配置場所を指定する子要素を含まなければならない(MUST)" という記述を "更に、ドメインオブジェクトが本拡張に関連するサーバ ポリシーに基づく情報を持つ場合、拡張名前空間を特定する 子要素を含むべきである(SHOULD)。"に変更した。 Authors' Addresses James Gould VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 US EMail: jgould@verisign.com Scott Hollenbeck VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 US EMail: shollenbeck@verisign.com Gould & Hollenbeck Standards Track [Page 36]