Internet Engineering Task Force (IETF) S. Hollenbeck Request for Comments: 7481 Verisign Labs Category: Standards Track N. Kong ISSN: 2070-1721 CNNIC March 2015 Registration Data Access Protocol（RDAP）のための セキュリティサービス Abstract RDAP（Registration Data Access Protocol）は、ドメイン名レジストリ及 び地域インターネットレジストリから登録されたメタデータを検索する 「RESTful」なWebサービスを提供する。本ドキュメントでは、アクセス制御、 認証、認可、可用性、データ機密性、データ完全性またはRDAPなどを含む情 報セキュリティサービスについて説明している。 Status of This Memo 本ドキュメントは、インターネット標準化過程のドキュメントである。 本ドキュメントは、IETF（Internet Engineering Task Force）の成果物で ある。 IETFコミュニティのコンセンサスを代表するものである。また、本ドキュメ ントは、公開レビューを受けており、IESG（Internet Engineering Steering Group）から公開・発行することを許可されている。インターネッ ト標準に関する詳細は、RFC 5741のSection 2で提供されている。 本ドキュメントに関する最新の状態、正誤、フィードバックの方法などに関 する情報は、下記URLを参照。 http://www.rfc-editor.org/info/rfc7481 Copyright Notice Copyright (c) 2015 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. Hollenbeck & Kong Standards Track [Page 1] RFC 7481 RDAP Security Services March 2015 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions Used in This Document . . . . . . . . . . . . . . 2 2.1. Acronyms and Abbreviations . . . . . . . . . . . . . . . 3 3. Information Security Services and RDAP . . . . . . . . . . . 3 3.1. Access Control . . . . . . . . . . . . . . . . . . . . . 3 3.2. Authentication . . . . . . . . . . . . . . . . . . . . . 3 3.2.1. Federated Authentication . . . . . . . . . . . . . . 4 3.3. Authorization . . . . . . . . . . . . . . . . . . . . . . 6 3.4. Availability . . . . . . . . . . . . . . . . . . . . . . 6 3.5. Data Confidentiality . . . . . . . . . . . . . . . . . . 7 3.6. Data Integrity . . . . . . . . . . . . . . . . . . . . . 7 4. Privacy Threats Associated with Registration Data . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Normative References . . . . . . . . . . . . . . . . . . 10 6.2. Informative References . . . . . . . . . . . . . . . . . 11 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction RDAP（Registration Data Access Protocol）は、複数のドキュメントで仕 様が規定されており、"Registration Data Access Protocol（RDAP）Query Format" [RFC7482]、"JSON Responses for the Registration Data Access Protocol（RDAP）" [RFC7483] 及び"HTTP Usage in the Registration Data Access Protocol（RDAP）" [RFC7480] を含む。 RDAPの一つのゴールは、アクセス制御、認証、認可、可用性、データ機密性、 データ完全性などを含むWHOIS [RFC3912] プロトコルに存在しないセキュリ ティサービスを提供することである。本ドキュメントは、それらの各サービ スが他のプロトコル階層で利用可能な機能を用いて、RDAPでどのように達成 されているかを説明する。追加または代替するメカニズムが、将来的に追加 される可能性がある。該当する場合、WHOIS置換サービス [RFC3707] に関す る要件への有益な参考文献に記述されている。 2. Conventions Used in This Document 本ドキュメントにおける次の各キーワード「しなければならない（MUST）」、 「してはならない（MUST NOT）」、「要求されている（REQUIRED）」、「す ることになる（SHALL）」、「することはない（SHALL NOT）」、「すべきで ある（SHOULD）」、「すべきではない（SHOULD NOT）」、「推奨される （RECOMMENDED）」、「してもよい（MAY）」、「任意である（OPTIONAL）」 は、[RFC2119] で説明されているように解釈されるべきものである。 Hollenbeck & Kong Standards Track [Page 2] RFC 7481 RDAP Security Services March 2015 2.1. Acronyms and Abbreviations 本ドキュメントで使用されている頭字語及び略語： DNR：ドメイン名レジストリ HTTP：Hypertext Transfer Protocol JSON：JavaScript Object Notation RDAP：Registration Data Access Protocol RIR：地域インターネットレジストリ TLS：Transport Layer Security 3. Information Security Services and RDAP RDAPそのものは、それ独自のセキュリティサービスを含まない。その代わり、 RDAPは必要なセキュリティサービス（アクセス制御、認証、認可、可用性、 データ機密性、データ完全性など）を提供するために、その他のプロトコル 階層上で利用可能な機能に依存する。 これらのセキュリティサービス個々については、"Internet Security Glossary, Version 2" [RFC4949] で確認できる。その他のセキュリティサー ビスに関する要件は、特定されていない。 3.1. Access Control WHOISは、登録情報へのアクセスを制御するための特定の機能を備えていな い。この後のセクションで説明されているように、RDAPは、サーバーオペレー ターにクライアントのアイデンティティーの基となる情報や関連する認可情 報へのアクセス制御を許可することで、クライアントを識別、認証、認可す る機能を含んでいる。クライアントに返される情報は、そのクライアントに アクセスが認められていることを識別するステータス値（[RFC7483] Section 10.2.2を参照）を明確に付けることができる。 3.2. Authentication 本セクションでは、セキュリティ認証メカニズム及び認可ポリシーを含むこ との必要性について説明している。その中では、クライアント及びサーバー の実装要件を説明しているが、サーバーオペレーターのポリシーを指示する 訳ではない。例えば、データへの分化型または階層型アクセスに関するポリ シーがないサーバーオペレーターは、認可メカニズムも無く、いかなる認証 の必要もない。分化型アクセスに関するポリシーを持つサーバーオペレーター は、認可スキームを組み立てる必要があり、また規定された認証要件に従わ なくてはならない。 Hollenbeck & Kong Standards Track [Page 3] RFC 7481 RDAP Security Services March 2015 WHOISは、クライアントを識別したり、認証する機能は提供していない。 "Cross Registry Internet Service Protocol（CRISP）Requirements" [RFC3707] のSection 3.1.4.2で記述されているように、サーバーオペレー ターが"ポリシーや要求に応じて、さまざまなアクセスの度合い"を提供する ためのユーティリティーが存在する。ユーティリティーを提供するためには、 クライアントは、識別され、かつ、認証されなくてはならない。 RDAPの認証フレームワークは、匿名のアクセス及びある範囲の認証方法や認 証情報提供サービスなどを採用した身元照合に対応しなくてはならない。そ のような目的でRDAPクライアント及びサーバーは、"Hypertext Transfer Protocol（HTTP/1.1）: Authentication" [RFC7235] で仕様が規定されてい る認証フレームワークを展開しなければならない（MUST）。 "Basic（認証）"スキームは、クライアントのユーザー名及びパスワード （base64形式の文字列エンコード）を平文でサーバーに送信することに使用 できる。"Digest（認証）"スキームは、クライアントの平文パスワードを晒 すことなくクライアントを認証できる。"Basic（認証）"スキームが使用さ れた場合、HTTP over TLS [RFC2818] は、クライアントの認証情報がデータ 送信中に開示されないよう守るために使用されなければならない（MUST） （Section 3.5を参照）。 サーバーは、BasicまたはDigest認証をサポートしなければならない （MUST）。両方をサポートすることは要求されない。クライアントは、一つ または他をサポートするサーバーとの相互運用のため、両方の認証方法をサ ポートしなければならない（MUST）。サーバーは、HTTP認証のきっかけとな るログイン画面を提供してもよい。クライアントは、HTTPサーバーから最初 の401（Unauthorized、無認可）応答を受信し、URLのスキーム部分が変更し ない限り、HTTP認証ヘッダーを送り続けるべきである。 TLS（Transport Layer Security）プロトコル [RFC5246] は、有効なX.509 電子証明書 [RFC5280] を保有・提示するクライアントを識別及び認証する ための任意の機能を含む。この機能のサポートは、任意である（OPTIONAL）。 RDAPは、ユニークなサーバーへの認証要件を課していない。TLSによって提 供されるサーバー認証は、RDAPに完全に対応している。一般的に、RDAP上の データ転送は、TLSで保護されたデータ転送（例：HTTPS）、またはサーバー 認証と同等レベルを提供する何らかのメカニズム、のどちらか一つを提供し なくてはならない。 今後も、HTTP認証方式に関する取組みは継続される。RDAPは、追加の方式な どが定義された際にサポートするため、十分な迅速性があるように設計され ている。 3.2.1. Federated Authentication 従来型のクライアントサーバー認証は、すべてのRDAPサーバーに対しクライ アントに確かな認証情報を維持することを要求する。この状況は、RDAPサー バー数の増加に伴い扱いにくくなる。 Hollenbeck & Kong Standards Track [Page 4] RFC 7481 RDAP Security Services March 2015 連携認証メカニズムは、クライアントが複数のRDAPサーバーにアクセスする ために一つの認証情報を使用することを許可し、クライアント認証管理の複 雑さを軽減する。RDAPは、クライアントが一つの認証情報で連携する複数の RDAPサーバーへのアクセスすることを可能にする連携認証メカニズムを含ん でもよい（MAY）。 RDAPが使用する認証連携メカニズムは、HTTPによって完全にサポートされて いなくてはならない（MUST）。OAuth、OpenID、SAML（Security Assertion Markup Language）並びに認証局（Certification Authority：CA）に基づく メカニズムは、すべて認証連携の提供を可能とする方法である。本ドキュメ ントの公開時点では、認証連携サービスのネゴシエーションまたは広告・宣 伝は、まだ、著名な連携認証プロトコルで未定義のメカニズムである。この メカニズムの開発は、本ドキュメントの範囲を超えている。 OAuth認可フレームワーク [RFC6749] は、ユーザーが認証情報を手渡すこと なしに保護されたWebリソースにアクセスする方法を説明している。その代 わり、クライアントは、リソース所有者の許可により、認可サーバーからア クセストークンの発行を受ける。OAuthを使用し、複数のRDAPサーバーは連 携を確立させることができ、またクライアントは、その連携内にあるどのサー バーにでも登録された一つの認証情報を提供すれば、その連携にあるどのサー バーでもアクセスすることができる。OAuth認可フレームワークは、HTTPと 併用できるよう設計されており、従って、RDAPとも使用できる。 OpenID [OpenID] は、分散型シングルサインオン認証システムであり、ユー ザーが複数のユニークなアカウントを作成する代わりに、一つのIDで複数の Webサイトへログインすることを可能にする。エンドユーザーは、どの OpenIDプロバイダーを使用するか自由に選べ、またOpenIDプロバイダーを乗 り換えても彼らの識別子を維持することができる。 OAuth及びOpenIDは、プロバイダーと消費者間の相互作用を保護するための データ機密性確保サービスを常に要求しないことに注意する。HTTP over TLS [RFC2818] は、中間者攻撃からの防御を提供するために、必要に応じて 使用できる。 SAML 2.0 [SAML] は、XMLベースのプロトコルであり、シングルサインオン を含むWebベースの認証及び認可サービスに実装できる。それは、アイデン ティティープロバイダーとサービスプロバイダー間において、エンドユーザー に関する情報交換に関する判定を含むセキュリティトークンを使用する。 TLS（Transport Layer Security）プロトコルは、クライアント証明書に関 する仕様について、[RFC5246] のSection 7.4.6で説明している。CAが発行 する有効なX.509電子証明書を保有・提示するクライアントは、それに対応 するCAを信頼するサーバーによって識別並びに認証される。証明書の認証方 法は、複数のRDAPサーバーすべてによってCAが信頼された場合、認証連携を 確立するために使用でき、またそれによって信頼されたCAによって発行され た証明書を持つクライアントは、連携しているどのRDAPサーバーでもアクセ スできる。 Hollenbeck & Kong Standards Track [Page 5] RFC 7481 RDAP Security Services March 2015 この証明書ベースのメカニズムは、HTTPSによってサポートされており、 RDAPと併用できる。 3.3. Authorization WHOISは、クライアントの認証済みアイデンティティーを基にした、異なる アクセスレベルをクライアントに付与するサービスを提供しない。"Cross Registry Internet Service Protocol（CRISP）Requirements" [RFC3707] のSection 3.1.4.2に記述されているように、サーバーオペレーターが"ポリ シーや要求に応じて、さまざまなアクセスの度合い"を提供するためのユー ティリティーが存在する。アクセス制御の決定は、クライアントのアイデン ティティーが確立・認証された時点で（Section 3.2を参照）行うことがで きる。 サーバーオペレーターは、Section 3.2で説明されている各種認証方法と併 用して、ポリシーや要求に応じてさまざまなアクセスの度合いを提供するこ とができる（MAY）。もし、そのようなさまざまなアクセスの度合いがサポー トされている場合、RDAPサーバーは、認可ポリシーを実装するために、きめ 細かなアクセス制御（すなわち、登録データオブジェクトごとに）を提供し なくてはならない（MUST）。以下は、その例である。 - クライアントは、関連性のあるデータにのみアクセスが可能となる - 未認証または匿名のアクセスステータスは、コンタクト情報を得られな いかもしれない - 認証済みクライアントの特別なグループへは、完全なアクセスが認めら れるかもしれない サーバーが許可するアクセスタイプは、それぞれのオペレーターによって異 なる。 異なる認可レベルと関係する応答プライバシーの考察に関する説明は、 [RFC7483] のSection 13で確認できる。 3.4. Availability RDAPサービスは、有用、かつ利用可能である必要がある。可用性を提供する ためのRDAP特有の要件はないが、一般的なセキュリティ上の考察として、サー ビスオペレーターは、サービス妨害に関連する課題について注意する必要が ある。[RFC4732] の"Internet Denial-of-Service Considerations"を完全 に読むことを勧める。 RDAPサービスは、ある一定の時間内に単一のクライアントが送信できるクエ リ数を制限するためにHTTPスロットリングメカニズムを使用してもよい （MAY）。もしそれを使用する場合、"Additional HTTP Status Codes" [RFC6585] で説明しているように、サーバーはHTTP 429（Too Many Requests）応答コードを返すべきである（SHOULD）。429応答を受信したク ライアントは、そのクエリレートを減少させ、かつRetry-Afterヘッダー Hollenbeck & Kong Standards Track [Page 6] RFC 7481 RDAP Security Services March 2015 フィールドがある場合は、それに従うべきである（SHOULD）。 悪意のあるクライアントは、コードを無視し、高いレートでクエリを送信し 続けてしまうことがあるので、これがDoS（denial-of-service）攻撃に対す る防御ではないことに注意する。サーバーは、クライアントに対しレート制 限が応答拒否の理由であることを明らかにしたくない場合は、別の応答コー ドを使用することができる。 3.5. Data Confidentiality WHOISは、通信中のデータを不注意な開示から保護する能力を提供していな い。RDAPは、HTTP over TLS [RFC2818] を利用し、クライアントとサーバー 間の通信におけるすべてのトラヒックを暗号化することでデータ保護を提供 する。HTTP over TLSは、すべてのクライアントサーバー間の情報交換を保 護するために使用しなければならない（MUST）。ただし、運用上の制限でそ の要件を満たすことが不可能な場合を除く。また、離散的なオブジェクト （例えば、コマンドパス部やJSON形式にエンコードされた応答オブジェクト） を一つのエンドポイントで暗号化し、それを保護されていない転送プロトコ ル経由でもう一方のエンドポイントに送信し、そして受信次第そのオブジェ クトを復号することも可能である。"Internet Security Glossary, Version 2" [RFC4949] で説明されている暗号アルゴリズムは、オブジェクトレベル におけるデータ機密性を提供するために一般的に使用されている。 暗号化を用いたオブジェクトレベルのデータ機密性に関する現在の要件は、 存在しない。この機能のサポートは、将来的にRDAPに追加される可能性があ る。 Section 3.2で記述されているように、HTTP"basic"認証スキームは、クライ アントを認証するために使用される。このスキームが使用された場合は、通 信中にクライアントの認証情報を開示から保護するためにHTTP over TLSを 使用しなければならない（MUST）。もしサーバーオペレーターのポリシー が、クライアントサーバー間のデータ交換（例えば、クライアント識別や認 証をしなければアクセスできない非公開データ）を保護するために暗号化を 要求する場合は、その情報交換を保護するためにHTTP over TLSを使用しな ければならない（MUST）。 機密性確保サービスで示されているプライバシーの脅威に関する説明は、 Section 4で確認できる。[RFC7483] のSection 10.2.2は、無認可のクライ アントに応答データを開示することから保護するために使用されるオペレー ターの行為の説明に利用できるステータス値を説明している。 3.6. Data Integrity WHOISは、通信中のデータを変更から保護する能力を提供していない。RDAP のようなWebサービスは、HTTP over TLS [RFC2818] を一般的に利用し、デー タの変更を検知するためにキーメッセージ認証コード（Message Authentication Code：MAC）を用いた保護を提供する。また、離散的なオブ ジェクト（例えば、コマンドパス部やJSON形式にエンコードされた応答オブ Hollenbeck & Kong Standards Track [Page 7] RFC 7481 RDAP Security Services March 2015 ジェクト）を一つのエンドポイントで署名し、それを転送プロトコル経由で もう一方のエンドポイントに送信し、そして受信次第そのオブジェクトの署 名を検証することも可能である。"Internet Security Glossary, Version 2" [RFC4949] で説明されている電子署名アルゴリズムは、オブジェクトレ ベルにおけるデータ完全性を提供するために一般的に使用されている。 電子署名を用いたオブジェクトレベルにおけるデータ完全性に関する現在の 要件は、存在しない。この機能のサポートは、将来的にRDAPに追加される可 能性がある。 このサービスの最も具体的なニーズは、HTTP 30xリダイレクト応答のヒント [RFC7231]、及び、サーバーから返された応答要素が通信中にデータ変更さ れないことの保証を提供することである。もしサーバーオペレーターのポリ シーが、クライアントサーバー間のデータ交換におけるメッセージの完全性 を要求する場合は、情報交換を保護するためにHTTP over TLSを使用しなけ ればならない（MUST）。 4. Privacy Threats Associated with Registration Data 登録データは、歴史的経緯により登録者の個人データを含んでいる。WHOIS サービスは、歴史的経緯によりこの情報を一般公開しており、登録者の個人 情報の詳細を開示することによってプライバシーのリスクを作り出している。 WHOISサービスは、登録データへアクセスするための認証やアクセス制御メ カニズムを利用できなかった。その結果、プロキシーやプライバシーサービ スなどが、登録者のアイデンティティーを保護するために台頭した。 RDAPの標準化は、オペレーターが登録者から収集することが要求されるデー タを変更したり影響を及ぼすことはないが、登録者のプライバシーに対する 脅威を緩和するために、オペレーターが選択すべき多数のメカニズムのサポー トを提供する。 RDAPは、クライアントを認証するために使用できるメカニズムを含み、サー バーが、ローカルポリシーに基づく階層型アクセスをサポートできるように する。つまり、すべての登録データはもはや一般公開される必要が無く、ま た個人データまたはより機密と見なされるデータへのアクセスは、特権を持 つクライアントに対して制限付きで可能となる。 RDAPデータ構造は、クライアントに返されるデータが非公開にされたり （Private）、編集されたり（Redacted）、覆い隠されたり（Obscured）、 またはプロキシーで登録されたりする際に、サーバーがステータス値を通し て示すことを許可する。"Private"とは、データが一般公開用に指定されて いないことを示す。"Redacted"とは、一部の登録データフィールドは利用可 能ではないことを示す。"Obscured"とは、データが実際の登録情報を容易に は開示しないことを目的に変更されていることを示す。登録者のプライバシー リスクを軽減するためにオペレーターが利用可能な一つのオプションは、一 つまたはすべてのクライアントと共有される登録者データをそのデータの感 受性、クライアントの権限、またはその他のヒューリスティックに従って制 限するために、これらのステータス値を利用できるポリシーを採用すること である。 Hollenbeck & Kong Standards Track [Page 8] RFC 7481 RDAP Security Services March 2015 RDAPは、エンティティーの表現にjCard [RFC7095] 標準フォーマットを使用 する。オペレーターは、jCardフィールドの多くがレジストリオペレーショ ンの目的に無関係である、またはあるフィールドについては登録者から情報 を収集する理由がないと考えるかもしれない。登録者のプライバシーリスク を軽減したいと考えるオペレーターは、どの情報を収集するか、応答内にど のフィールドを格納するか、その両方またはいずれか一方を制限することが できる。 登録者のプライバシーリスクに加えて、登録データを問い合わせする側の潜 在的なプライバシーリスクも存在する。例えば、レジストリの従業員が特定 のクエリを実行することで、その従業員が非公開を望んだ活動に関する情報 を開示してしまうことになるかもしれない。 RDAPは、HTTP over TLS を利用し登録者データを問い合わせる側、並びに登 録者のプライバシー保護を提供することをサポートする。ただし、運用上の 制限でその要件を満たすことが不可能な場合は除く。 5. Security Considerations RDAPの一つのゴールは、WHOISプロトコルには存在しないセキュリティサー ビスを提供することである。本ドキュメントは、RDAPが提供するセキュリティ サービス及び認証、認可、可用性、データ機密性、データ完全性を含む関連 するプロトコルの階層を説明する。 否認防止サービスも考慮されたが、要件が不足していることが原因で最終的 に却下された。 しかしながら、現在実装されているWHOISサーバーで、生成元を証明し否認 防止を提供し、署名された応答を返すものも存在する。RDAPが、将来的に拡 張し、このサービスを提供することが必要になるかもしれない。 HTTPベースのプロトコルのため、RDAPはコードインジェクション攻撃の影響 を受けやすい。 コードインジェクションは、実行方針を改ざんするためにコンピューターシ ステムまたはプログラムに対しコードを追加してしまうことを指す。数ある 中でも、SQLインジェクション、動的変数やファンクションインジェクショ ン、インクルードファイルインジェクション、シェルインジェクション、及 びHTMLスクリプトインジェクションなどを含め、数多くのコードインジェク ションタイプがある。データの機密性及び完全性に関するサービスは、中間 者攻撃に対する防御手段を提供するが、クライアント及びサーバー側両方の ソフトウェアの脆弱性によってインジェクション攻撃を成功させてしまう。 常にサーバーの認証情報をチェック及び検証することで、中間者攻撃を検知 できる。 Section 3.2.1で記述されているように、電子証明書は、認証連携を実装す るために使用される。TLSサーバーがTLSクライアント認証ハンドシェイク、 またCAによって署名された証明書に信頼という外観を与えることの一環とし てクライアントに送信する受け入れ可能なCAリストの中には、乱雑過ぎる、 もしくは不正な、CAが含まれるリスクが存在する。 RDAPサーバーがクライアント認証のために信頼するCAリストの定期的な監視 は、このリスクを軽減できる。 Hollenbeck & Kong Standards Track [Page 9] RFC 7481 RDAP Security Services March 2015 TLS（Transport Layer Security）プロトコル [RFC5246] は、データの暗号 化を行わず、データ機密性も確保しないnull暗号スイートを含む。このオプ ションは、データ機密性確保サービスが必要な際は、使用してはならない （MUST NOT）。TLSのセキュアな使用に関する追加の考察については、 [SECURE-TLS-DTLS] で説明されている。 データ完全性確保サービスは、時々データ精度に焦点を合わせたディレクト リサービスの運用ポリシー要件と誤って関連付けられることがある。 "Accuracy"は、特定のディレクトリオブジェクト（例えば、ドメイン名）の コンテキストにおけるデータ要素（例えば、名前、住所、電話番号）の本来 の関連付けを指す。データ精度の要求は、このプロトコルの範囲外である。 追加的なセキュリティの考察は、HTTP [RFC7231]、HTTP Basic及びDigestア クセス認証 [RFC7235]、HTTP over TLS [RFC2818]、並びに追加HTTPステー タスコード [RFC6585] の仕様の中で説明されている。連携認証システムの セキュリティの考察は、OAuth [RFC6749] 及びOpenID [OpenID] の仕様で確 認できる。 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000, . [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status Codes", RFC 6585, April 2012, . [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014, . [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014, . Hollenbeck & Kong Standards Track [Page 10] RFC 7481 RDAP Security Services March 2015 [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the Registration Data Access Protocol (RDAP)", RFC 7480, March 2015, . [RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access Protocol (RDAP) Query Format", RFC 7482, March 2015, . [RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the Registration Data Access Protocol (RDAP)", RFC 7483, March 2015, . 6.2. Informative References [OpenID] OpenID Foundation, "OpenID Authentication 2.0 - Final", December 2007, . [RFC3707] Newton, A., "Cross Registry Internet Service Protocol (CRISP) Requirements", RFC 3707, February 2004, . [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, September 2004, . [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006, . [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, August 2007, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012, . [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, January 2014, . Hollenbeck & Kong Standards Track [Page 11] RFC 7481 RDAP Security Services March 2015 [SAML] OASIS, "Security Assertion Markup Language (SAML) v2.0", March 2005, . [SECURE-TLS-DTLS] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of TLS and DTLS", Work in Progress, draft-ietf-uta-tls-bcp-09, February 2015. Hollenbeck & Kong Standards Track [Page 12] RFC 7481 RDAP Security Services March 2015 Acknowledgements The authors would like to acknowledge the following individuals for their contributions to this document: Richard Barnes, Marc Blanchet, Alissa Cooper, Ernie Dainow, Spencer Dawkins, Jean-Philippe Dionne, Byron Ellacott, Stephen Farrell, Tony Hansen, Peter Koch, Murray Kucherawy, Barry Leiba, Andrew Newton, and Linlin Zhou. Authors' Addresses Scott Hollenbeck Verisign Labs 12061 Bluemont Way Reston, VA 20190 United States EMail: shollenbeck@verisign.com URI: http://www.verisignlabs.com/ Ning Kong China Internet Network Information Center 4 South 4th Street, Zhongguancun, Haidian District Beijing 100190 China Phone: +86 10 5881 3147 EMail: nkong@cnnic.cn Hollenbeck & Kong Standards Track [Page 13] RFC7481-ja.txt revision 1.0 この翻訳文に関するお問い合わせは dnstech-info@jprs.jp までご連絡下さい。 Japan Registry Services Co., Ltd. https://jprs.jp/tech/