[要約] RFC 7070は、信頼性報告のためのアーキテクチャに関するものであり、信頼性の評価と報告を効果的に行うためのガイドラインを提供しています。その目的は、インターネット上のエンティティの信頼性を評価し、ユーザーに信頼できる情報を提供することです。
Internet Engineering Task Force (IETF) N. Borenstein
Request for Comments: 7070 Mimecast
Category: Standards Track M. Kucherawy
ISSN: 2070-1721 November 2013
An Architecture for Reputation Reporting
レピュテーションレポートのアーキテクチャ
Abstract
概要
This document describes a general architecture for a reputation-based service, allowing one to request reputation-related data over the Internet, where "reputation" refers to predictions or expectations about an entity or an identifier such as a domain name. The document roughly follows the recommendations of RFC 4101 for describing a protocol model.
このドキュメントでは、評判ベースのサービスの一般的なアーキテクチャについて説明します。これにより、インターネットを介して評判関連データをリクエストできます。「評判」とは、エンティティやドメイン名などの識別子に関する予測または期待を指します。このドキュメントは、プロトコルモデルを説明するためのRFC 4101の推奨事項にほぼ準拠しています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7070.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7070で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Overview ........................................................4
3. Related Documents ...............................................5
4. High-Level Architecture .........................................5
4.1. Example of a Reputation Service Being Used .................6
5. Terminology and Definitions .....................................7
5.1. Application ................................................7
5.2. Response Set ...............................................7
5.3. Assertions and Ratings .....................................8
5.4. Reputon ....................................................9
6. Information Represented in the Protocol .........................9
7. Information Flow in the Reputation Query Protocol ..............10
8. Privacy Considerations .........................................10
8.1. Data in Transit ...........................................10
8.2. Aggregation ...............................................11
8.3. Collection of Data ........................................11
8.4. Queries Can Reveal Information ............................11
8.5. Compromised Relationships .................................11
9. Security Considerations ........................................12
9.1. Biased Reputation Agents ..................................12
9.2. Malformed Messages ........................................12
9.3. Further Discussion ........................................13
10. Informative References ........................................13
Historically, many Internet protocols have operated between unauthenticated entities. For example, an email message's author field (From:) [MAIL] can contain any display name or address and is not verified by the recipient or other agents along the delivery path. Similarly, a server that sends email using the Simple Mail Transfer Protocol [SMTP] trusts that the Domain Name System [DNS] has led it to the intended receiving server. Both kinds of trust are easily betrayed, opening the operation to subversion of some kind, which makes spam, phishing, and other attacks even easier than they would otherwise be.
これまで、多くのインターネットプロトコルは、認証されていないエンティティ間で動作してきました。たとえば、電子メールメッセージの作成者フィールド（From :) [MAIL]には任意の表示名またはアドレスを含めることができ、配信パスに沿った受信者または他のエージェントによって検証されません。同様に、Simple Mail Transfer Protocol [SMTP]を使用して電子メールを送信するサーバーは、ドメインネームシステム[DNS]が目的の受信サーバーに送信したことを信頼します。どちらの種類の信頼も簡単に裏切られ、ある種の破壊行為が可能になり、スパム、フィッシング、その他の攻撃が他の方法よりもさらに簡単になります。
In recent years, explicit identity authentication mechanisms have begun to see wider deployment. For example, the DomainKeys Identified Mail [DKIM] protocol permits associating a validated identifier to a message. This association is cryptographically strong, and is an improvement over the prior state of affairs, but it does not distinguish between identifiers of good actors and bad. Even when it is possible to validate the domain name in an author field (e.g., "trustworthy.example.com" in "john.doe@trustworthy.example.com"), there is no basis for knowing whether it is associated with a good actor who is worthy of trust. As a practical matter, both bad actors and good adopt basic authentication mechanisms like DKIM. In fact, bad actors tend to adopt them even more rapidly than the good actors do in the hope that some receivers will confuse identity authentication with identity assessment. The former merely means that the name is being used by its owner or their agent, while the latter makes a statement about the quality of the owner.
近年、明示的なID認証メカニズムがより広範な展開を始めています。たとえば、DomainKeys Identified Mail [DKIM]プロトコルでは、検証済みの識別子をメッセージに関連付けることができます。この関連付けは暗号学的に強力であり、以前の状況よりも改善されていますが、善玉と悪役の識別子を区別していません。作成者フィールドでドメイン名を検証できる場合でも（たとえば、「john.doe@trustworthy.example.com」の「trustworthy.example.com」）、それが信頼に値する良き俳優。実際問題として、悪役と善人の両方がDKIMのような基本的な認証メカニズムを採用しています。実際、悪いアクターは、一部の受信者がアイデンティティ認証とアイデンティティ評価を混同することを期待して、善意のアクターよりもさらに迅速に採用する傾向があります。前者は単にその名前がその所有者またはその代理人によって使用されていることを意味し、後者は所有者の質について述べています。
With the advent of these authentication protocols, it is possible to satisfy the requirement for a mechanism by which mutually trusted parties can exchange assessment information about other actors. For these purposes, we may usefully define "reputation" as "the estimation in which an identifiable actor is held, especially by the community or the Internet public generally". (This is based on the definition of "reputation" in [RANDOMHOUSE].) We may call an aggregation of individual assessments "reputation input".
これらの認証プロトコルの出現により、相互に信頼できる当事者が他のアクターに関する評価情報を交換できるメカニズムの要件を満たすことが可能です。これらの目的のために、「評判」を「特定可能なアクターが保持されている推定、特にコミュニティまたはインターネット一般により一般に推定される」として有用に定義する場合があります。 （これは[ランダムハウス]の「評判」の定義に基づいています。）個々の評価の集合を「評判入力」と呼ぶ場合があります。
While the need for reputation services has been perhaps especially clear in the email world, where abuses are commonplace, other Internet services are coming under attack and may have a similar need. For instance, a reputation mechanism could be useful in rating the security of web sites, the quality of service of an Internet Service Provider (ISP), or an Application Service Provider (ASP). More generally, there are many different opportunities for use of reputation services, such as customer satisfaction at e-commerce sites, and even things unrelated to Internet protocols, such as plumbers, hotels, or books. Just as human beings traditionally rely on the recommendations of trusted parties in the physical world, so too they can be expected to make use of such reputation services in a variety of applications on the Internet.
悪用が一般的である電子メールの世界では、レピュテーションサービスの必要性がおそらく特に明確になっていますが、他のインターネットサービスも攻撃を受けており、同様のニーズがある可能性があります。たとえば、レピュテーションメカニズムは、Webサイトのセキュリティ、インターネットサービスプロバイダー（ISP）、またはアプリケーションサービスプロバイダー（ASP）のサービス品質の評価に役立ちます。より一般的には、eコマースサイトでの顧客満足度や、配管工、ホテル、本などのインターネットプロトコルに関係のないものなど、評判サービスを使用するさまざまな機会があります。人間が伝統的に現実世界の信頼できる当事者の推奨に依存しているのと同じように、インターネット上のさまざまなアプリケーションでそのような評判サービスを利用することも期待できます。
A full trust architecture encompasses a range of actors and activities, to enable an end-to-end service for creating, exchanging, and consuming trust-related information. One component of that is a query mechanism, to permit retrieval of a reputation. Not all such reputation services will need to convey the same information. Some need only to produce a basic rating, while others need to provide underlying detail. This is akin to the difference between check approval and a credit report.
完全信頼アーキテクチャには、さまざまなアクターとアクティビティが含まれ、信頼関連情報を作成、交換、および消費するためのエンドツーエンドサービスを可能にします。その1つのコンポーネントは、レピュテーションの取得を可能にするクエリメカニズムです。そのような評判サービスのすべてが同じ情報を伝える必要があるわけではありません。基本的な評価を作成するだけでよいものもあれば、基礎となる詳細を提供する必要があるものもあります。これは、小切手の承認と信用報告書の違いに似ています。
An overall reckoning of goodness versus badness can be defined generically, but specific applications are likely to want to describe reputations for multiple attributes: an e-commerce site might be rated on price, speed of delivery, customer service, etc., and might receive very different ratings on each. Therefore, the architecture defines a generic query mechanism and basic format for reputation retrieval, but allows extensions for each application.
善と悪の全体的な評価は一般的に定義できますが、特定のアプリケーションでは、複数の属性の評判を説明する必要があります。eコマースサイトは、価格、配信速度、カスタマーサービスなどで評価され、受け取る可能性があります。それぞれに非常に異なる評価。したがって、このアーキテクチャは、レピュテーション検索のための一般的なクエリメカニズムと基本フォーマットを定義しますが、各アプリケーションの拡張を許可します。
Omitted from this architecture is the means by which a reputation-reporting agent goes about collecting such data and the method for creating an evaluation. The mechanism defined here merely enables asking a question and getting an answer; the remainder of an overall service provided by such a reputation agent is specific to the implementation of that service and is out of scope here.
このアーキテクチャから省略されているのは、評判報告エージェントがそのようなデータを収集する手段と、評価を作成する方法です。ここで定義されているメカニズムは、質問をして回答を得ることを可能にするだけです。そのようなレピュテーションエージェントによって提供されるサービス全体の残りは、そのサービスの実装に固有であり、ここでは範囲外です。
The basic premise of this reputation system involves a client that is seeking to evaluate content based on an identifier associated with the content, and a reputation service provider that collects, aggregates, and makes available for consumption, scores based on the collected data. Typically, client and service operators enter into some kind of agreement during which some parameters are exchanged, such as: the location at which the reputation service can be reached, the nature of the reputation data being offered, possibly some client authentication details, and the like.
このレピュテーションシステムの基本的な前提には、コンテンツに関連付けられた識別子に基づいてコンテンツを評価しようとしているクライアントと、収集されたデータに基づいてスコアを収集、集約し、利用できるようにするレピュテーションサービスプロバイダーが含まれます。通常、クライアントとサービスのオペレーターは、レピュテーションサービスに到達できる場所、提供されているレピュテーションデータの性質、クライアント認証の詳細、お気に入り。
Upon receipt of some content the client operator wishes to evaluate (an Internet message, for example), the client extracts from the content one or more identifiers of interest to be evaluated. Examples of this include the domain name found in the From: field of a message, or the domain name extracted from a valid DKIM signature.
クライアントオペレータが評価したいコンテンツ（インターネットメッセージなど）を受信すると、クライアントはコンテンツから、評価する1つまたは複数の対象の識別子を抽出します。この例には、メッセージのFrom：フィールドにあるドメイン名、または有効なDKIM署名から抽出されたドメイン名が含まれます。
Next, the goal is to ask the reputation service provider what the reputation of the extracted identifier is. The query will contain the identifier to be evaluated and possibly some context-specific information (such as to establish the context of the query, e.g., an email message) or client-specific information. The client typically folds the data in the response into whatever local evaluation logic it applies to decide what disposition the content deserves.
次に、目的は、評判サービスプロバイダーに、抽出された識別子の評判を尋ねることです。クエリには、評価される識別子と、場合によってはいくつかのコンテキスト固有の情報（クエリのコンテキストを確立するためなど）、またはクライアント固有の情報が含まれます。クライアントは通常、応答のデータをローカルの評価ロジックに折りたたんで、コンテンツにふさわしい処理を決定します。
This document presents a high-level view of the reputation architecture.
このドキュメントでは、レピュテーションアーキテクチャの概要を示します。
For the purposes of sending and receiving reputation information, [RFC7071] defines a media type for containing responses to reputation queries, and a serialization format for these data (with examples). It also creates the registry for specific reputation contexts and the parameters related to them.
レピュテーション情報を送受信するために、[RFC7071]は、レピュテーションクエリへの応答を含むメディアタイプと、これらのデータのシリアル化形式（例を含む）を定義します。また、特定のレピュテーションコンテキストとそれに関連するパラメーターのレジストリも作成します。
[RFC7072] describes how to construct and issue reputation queries and replies in the context of this architecture using the HyperText Transport Protocol (HTTP) as the query protocol.
[RFC7072]は、レピュテーションクエリを構築して発行する方法を説明し、クエリプロトコルとしてHyperText Transport Protocol（HTTP）を使用して、このアーキテクチャのコンテキストで応答します。
Finally, [RFC7073] defines (and registers) a first, common, reputation application, namely the evaluation of portions of an email message as subjects for reputation queries and replies.
最後に、[RFC7073]は、最初の一般的なレピュテーションアプリケーションを定義（および登録）します。
This document outlines the reputation query and response mechanism. It provides the following definitions:
このドキュメントでは、レピュテーションクエリと応答メカニズムの概要を説明します。次の定義を提供します。
o Vocabulary for the current work and work of this type;
o 現在の作品とこのタイプの作品の語彙。
o The types and content of queries that can be supported;
o サポートできるクエリの種類と内容。
o The extensible range of response information that can be provided;
o 提供できる拡張可能な応答情報の範囲。
o Query/response transport conventions.
o クエリ/応答転送規約。
It provides an extremely simple query/response model that can be carried over a variety of transports, including the Domain Name System. (Although not typically thought of as a 'transport', the DNS provides generic capabilities and can be thought of as a mechanism for transporting queries and responses that have nothing to do with Internet addresses, such as is done with a DNS BlockList [DNSBL].) Each specification for Repute transport is independent of any other specification.
ドメインネームシステムを含むさまざまなトランスポートを介して実行できる非常にシンプルなクエリ/応答モデルを提供します。 （通常、「トランスポート」とは考えられていませんが、DNSは一般的な機能を提供し、DNS BlockList [DNSBL]で行われるような、インターネットアドレスとは関係のないクエリと応答を転送するメカニズムと考えることができます。）Reputeトランスポートの各仕様は、他のどの仕様からも独立しています。
The precise syntaxes of both the query and response are application specific. An application within this architecture defines the parameters available to queries of that type, and it also defines the data returned in response to any query.
クエリとレスポンスの両方の正確な構文は、アプリケーション固有です。このアーキテクチャ内のアプリケーションは、そのタイプのクエリで使用できるパラメーターを定義し、クエリに応答して返されるデータも定義します。
A reputation mechanism functions as a component of an overall service. A current example is that of an email system that uses DKIM [DKIM] to affix a stable identifier to a message and then uses that as a basis for evaluation:
レピュテーションメカニズムは、サービス全体のコンポーネントとして機能します。現在の例は、DKIM [DKIM]を使用してメッセージに安定した識別子を付加し、それを評価の基準として使用する電子メールシステムの例です。
+-------------+ +------------+
| Sender | | Recipient |
+-------------+ +------------+
| ^
V |
+-------------+ +------------+
| MSA | | MDA |
+-------------+ +------------+
| ^
| |
| +------------+
| | Handling |
| | Filter |
| +------------+
| ^
| |
| +------------+ +------------+
| | Reputation |<=====>| Identifier |
| | Service | | Assessor |
| +------------+ +------------+
| ^
V |
+------------+ Responsible Identifier +------------+
| Identifier |. . . . . . . . . . . . . .>| Identifier |
| Signer | (DKIM) | Verifier |
+------------+ +------------+
| ^
V |
+-------------+ /~~~~~~~~~~\ +------+-----+
| MTA |----->( other MTAs )------>| MTA |
+-------------+ \~~~~~~~~~~/ +------------+
Figure 1: Actors in a Trust Sequence Using DKIM
図1：DKIMを使用した信頼シーケンスのアクター
See [EMAIL-ARCH] for a general description of the Internet messaging architecture. In particular, the terms Message Submission Agent (MSA), Message Delivery Agent (MDA), and Message Transfer Agent (MTA) are described there.
インターネットメッセージングアーキテクチャの一般的な説明については、[EMAIL-ARCH]を参照してください。特に、メッセージ送信エージェント（MSA）、メッセージ配信エージェント（MDA）、メッセージ転送エージェント（MTA）という用語がここで説明されています。
In this figure, the solid lines indicate the flow of a message; the dotted line indicates transfer of validated identifiers within the message content; and the double line shows the query and response of the reputation information.
この図では、実線はメッセージの流れを示しています。点線は、メッセージコンテンツ内の検証済み識別子の転送を示します。二重線は、レピュテーション情報のクエリと応答を示しています。
Here, the DKIM Service provides one or more stable identifiers that is the basis for the reputation query. On receipt of a message from an MTA, the DKIM Service provides a (possibly empty) set of validated identifiers -- domain names, in this case -- that are the subjects of reputation queries made by the Identifier Assessor. The Identifier Assessor queries a Reputation Service to determine the reputation of the provided identifiers, and delivers the identifiers and their reputations to the Handling Filter. The Handling Filter makes a decision about whether and how to deliver the message to the recipient based on these and other inputs about the message, possibly including evaluation mechanisms in addition to DKIM.
ここで、DKIMサービスは、レピュテーションクエリの基礎となる1つ以上の安定した識別子を提供します。 MTAからのメッセージを受信すると、DKIMサービスは、IDアセッサによって行われたレピュテーションクエリの対象となる、検証された識別子（この場合はドメイン名）のセット（空の場合もある）を提供します。 Identifier Assessorは、レピュテーションサービスにクエリを実行して、提供された識別子のレピュテーションを判別し、識別子とそのレピュテーションを処理フィルターに配信します。処理フィルターは、メッセージに関するこれらの入力およびその他の入力に基づいて、メッセージを受信者に配信するかどうか、およびどのように配信するかを決定します。DKIMに加えて評価メカニズムも含まれる場合があります。
This section defines terms used in the rest of the document.
このセクションでは、ドキュメントの残りの部分で使用される用語を定義します。
An "Application" is a specific context in which reputation queries are made. Some obvious popular examples include restaurants, movies, or providers of various services.
「アプリケーション」は、レピュテーションクエリが作成される特定のコンテキストです。明らかな人気の例としては、レストラン、映画、さまざまなサービスのプロバイダーなどがあります。
Applications have different sets of attributes of interest, and so the subjects of queries and the resulting responses will vary in order to describe the reputations of entities in their respective contexts. For example, the Application "movies" would have a different set of properties of interest and associated ratings (see below) from "restaurants". It is therefore necessary for them to be formally defined.
アプリケーションにはさまざまな対象の属性セットがあるため、エンティティの評判をそれぞれのコンテキストで説明するために、クエリのサブジェクトと結果の応答が異なります。たとえば、アプリケーション「映画」には、「レストラン」とは異なる一連の興味深いプロパティと関連する評価（以下を参照）があります。したがって、それらを正式に定義する必要があります。
A "Response Set" is a representation for data that are returned in response to a reputation query about a particular entity within the context of an Application. A Response Set will always contain at least the following components:
「応答セット」は、アプリケーションのコンテキスト内の特定のエンティティーに関するレピュテーションクエリへの応答として返されるデータの表現です。応答セットには、少なくとも次のコンポーネントが常に含まれます。
o the name of the entity being rated;
o 評価されるエンティティの名前。
o the Assertion (see Section 5.3);
o アサーション（セクション5.3を参照）
o the Rating (see Section 5.3).
o 格付け（セクション5.3を参照）。
The full content of the Response Set is specific to the Application; though all Applications have these few key Response Set fields in common, some of the reputation data returned in the evaluation of email senders would be different than that returned about a movie, restaurant, or baseball player. The specific meaning of a Rating is also specific to an Application.
応答セットの完全な内容はアプリケーションに固有です。すべてのアプリケーションにはこれらのいくつかの主要な応答セットフィールドが共通していますが、電子メール送信者の評価で返されるレピュテーションデータの一部は、映画、レストラン、または野球選手について返されるものとは異なります。格付けの特定の意味は、アプリケーションにも固有です。
A Response Set is declared in a specification document, along with a symbolic name representing the Application. The specifying documents will include the details of query parameters and responses particular to that Application. The symbolic names and corresponding specifying documents are registered with IANA in the "Reputation Applications" registry in order to prevent name collisions and provide convenient references to the documents.
応答セットは、アプリケーションを表すシンボル名とともに、仕様ドキュメントで宣言されます。指定するドキュメントには、そのアプリケーションに固有のクエリパラメータと応答の詳細が含まれます。シンボル名と対応する指定ドキュメントは、名前の衝突を防ぎ、ドキュメントへの便利な参照を提供するために、「レピュテーションアプリケーション」レジストリのIANAに登録されます。
IANA registries are created in [RFC7071].
IANAレジストリは[RFC7071]で作成されます。
One of the key properties of a Response Set is called an "Assertion". Assertions are claims made about the subject of a reputation query. For example, one might assert that a particular restaurant serves good food. In the context of this architecture, the assertion would be "serves good food".
応答セットの主要なプロパティの1つは「アサーション」と呼ばれます。アサーションは、レピュテーションクエリの件名について行われたクレームです。たとえば、特定のレストランがおいしい料理を提供していると主張するかもしれません。このアーキテクチャのコンテキストでは、主張は「おいしい料理を提供する」でしょう。
Assertions are coupled with a numeric value called a "Rating", which is an indication of how much the party generating the Response Set agrees with the assertion being made. Ratings are typically expressed as a floating point value between 0.0 and 1.0 inclusive, with the former indicating no support for the assertion and the latter indicating total agreement with the assertion.
アサーションは、「評価」と呼ばれる数値と組み合わされます。これは、応答セットを生成する当事者が行われるアサーションにどの程度同意するかを示します。評価は通常、0.0〜1.0の浮動小数点値として表されます。前者はアサーションをサポートしていないことを示し、後者はアサーションとの完全な合意を示しています。
The documents that define future applications will also specify the type of scale in use when generating ratings, to which all reputation service providers for that application space must adhere. This will allow a client to change which reputation service provider is being queried without having to learn through some out-of-band method what the new provider's ratings mean. For example, a registration might state that ratings are linear, which would mean a score of "x" is twice as strong as a value of "x/2". It also allows easier aggregation of ratings collected from multiple reputation service providers.
将来のアプリケーションを定義するドキュメントでは、評価を生成するときに使用するスケールのタイプも指定します。これには、そのアプリケーションスペースのすべてのレピュテーションサービスプロバイダーが準拠する必要があります。これにより、クライアントは、新しいプロバイダーの評価が何を意味するかを帯域外の方法で学習する必要なく、照会されているレピュテーションサービスプロバイダーを変更できます。たとえば、登録は評価が線形であることを示す場合があります。これは、「x」のスコアが「x / 2」の値の2倍であることを意味します。また、複数のレピュテーションサービスプロバイダーから収集された評価を簡単に集約できます。
A "reputon" is an object that comprises the basic response to a reputation query. It contains the Response Set relevant to the subject of the query in a serialized form. Its specific encoding is left to documents that implement this architecture.
「レピュトン」は、レピュテーションクエリに対する基本的な応答を構成するオブジェクトです。クエリの件名に関連する応答セットがシリアル化された形式で含まれています。特定のエンコーディングは、このアーキテクチャを実装するドキュメントに任されています。
Regardless of the transport selected for the interchange, the basic information to be represented in the protocol is fairly simple, and normally includes at least the following data:
交換用に選択されたトランスポートに関係なく、プロトコルで表される基本情報はかなり単純であり、通常、少なくとも次のデータが含まれています。
In the query:
クエリでは：
o the subject of the query;
o クエリの件名。
o the name of the reputation context ("Application"; see Section 5.1);
o レピュテーションコンテキストの名前（「アプリケーション」、セクション5.1を参照）。
o optionally, name(s) of the specific reputation assertions of interest.
o 必要に応じて、特定のレピュテーションアサーションの名前。
Different transports, or different reputation contexts, might need additional query parameters.
トランスポートやレピュテーションコンテキストが異なると、追加のクエリパラメータが必要になる場合があります。
In the response:
応答では：
o the identity of the entity providing the reputation information;
o 評判情報を提供するエンティティのアイデンティティ;
o the identity of the entity being rated;
o 格付けされているエンティティのアイデンティティ;
o the application context for the query (e.g., email address evaluation);
o クエリのアプリケーションコンテキスト（メールアドレスの評価など）
o the overall rating score for that entity.
o そのエンティティの全体的な評価スコア。
Beyond this, arbitrary amounts of additional information might be included for specific uses of the service. The entire collection of data found in the response is the Response Set for that application and is defined in specifying documents as described above.
これ以外にも、サービスの特定の用途のために、任意の量の追加情報が含まれる場合があります。応答で見つかったデータのコレクション全体がそのアプリケーションの応答セットであり、上記のようにドキュメントの指定で定義されます。
For example, a specification might be needed for a reputation Response Set for an "email-sending-domain"; the Response Set might include information on how often spam was received from that domain.
たとえば、「email-sending-domain」のレピュテーションレスポンスセットの指定が必要になる場合があります。応答セットには、そのドメインからスパムが受信された頻度に関する情報が含まれる場合があります。
[RFC7071] defines a media type and format for reputation data, and [RFC7072] describes a protocol for exchanging such data.
[RFC7071]はレピュテーションデータのメディアタイプとフォーマットを定義し、[RFC7072]はそのようなデータを交換するためのプロトコルを記述します。
The basic Response Set could be wrapped into a new MIME media type [MIME] or a DNS Resource Record (RR), and transported accordingly. It also could be the integral payload of a purpose-built protocol. For a basic request/response scenario, one entity (the client) will ask a second entity (the server) for reputation data about a third entity (the subject), and the second entity will respond with those data.
基本的な応答セットは、新しいMIMEメディアタイプ[MIME]またはDNSリソースレコード（RR）にラップされ、それに応じて転送されます。また、専用のプロトコルに不可欠なペイロードになる可能性もあります。基本的な要求/応答シナリオでは、1つのエンティティ（クライアント）が2番目のエンティティ（サーバー）に3番目のエンティティ（サブジェクト）に関するレピュテーションデータを要求し、2番目のエンティティはそれらのデータで応答します。
An application might benefit from an extremely lightweight mechanism, supporting constrained queries and responses, while others might need to support larger and more complex responses.
アプリケーションは、非常に軽量なメカニズムの恩恵を受けることができ、制約されたクエリと応答をサポートしますが、他のアプリケーションはより大きくより複雑な応答をサポートする必要がある場合があります。
Some reputation exchanges can be sensitive, and should not be shared publicly. A client making use of this framework is explicitly revealing that it is interested in particular subjects, and the server is revealing what its information sources have reported about those subjects (in the aggregate). In the email context, for example, a client is revealing from whom it receives email, and the server is revealing what it (based on its aggregated data) believes to be true about those subjects.
一部の評判の交換は機密となる可能性があり、公に共有すべきではありません。このフレームワークを利用するクライアントは、特定のサブジェクトに関心があることを明示的に明らかにしており、サーバーは、その情報ソースがそれらのサブジェクトについて（全体として）レポートした内容を明らかにしています。たとえば、電子メールのコンテキストでは、クライアントは電子メールの受信者を明らかにし、サーバーは（集約データに基づいて）クライアントがそれらの件について真実であると信じるものを明らかにします。
These can be sensitive things that need to be secured, particularly when a client is talking to a server outside of its own administrative domain. Furthermore, certain types of reputation information are typically perceived as more sensitive than others; movie ratings, for example, are much less damaging if leaked than a person's credit rating.
これらは、特にクライアントが自身の管理ドメインの外部にあるサーバーと通信している場合に、セキュリティで保護する必要がある重要なものになる可能性があります。さらに、特定のタイプのレピュテーション情報は、通常、他のタイプよりも敏感であると認識されています。たとえば、映画の格付けは、人の信用格付けよりも漏洩した場合の損害がはるかに少ない。
For interchanges that are sensitive to such exposures, it is imperative to protect the information from unauthorized access and viewing, and possibly add the capability to do object-level integrity and origin verification. Not all transport options can be adequately secured in these ways. In particular, DNS queries and responses are entirely insecure. Services need to use a transport method that provides adequate security when privacy-sensitive data are involved.
このような露出に敏感なインターチェンジの場合、不正なアクセスと表示から情報を保護し、オブジェクトレベルの整合性と発信元の検証を実行する機能を追加することが不可欠です。これらの方法ですべてのトランスポートオプションを適切に保護できるわけではありません。特に、DNSクエリと応答は完全に安全ではありません。サービスは、プライバシー性の高いデータが含まれる場合に適切なセキュリティを提供する転送方法を使用する必要があります。
The architecture described here neither suggests nor precludes any particular transport mechanism for the data. An HTTP mechanism is defined in [RFC7072], and email-based mechanisms are also envisioned. For HTTP, use of HTTP over Transport Layer Security [HTTP-TLS] is very strongly advised. For email, mechanisms such as OpenPGP [OPENPGP] and S/MIME [SMIME] are similarly advised.
ここで説明するアーキテクチャは、データの特定のトランスポートメカニズムを示唆も排除もしていません。 HTTPメカニズムは[RFC7072]で定義されており、電子メールベースのメカニズムも想定されています。 HTTPの場合、HTTP over Transport Layer Security [HTTP-TLS]の使用を強くお勧めします。電子メールについては、OpenPGP [OPENPGP]やS / MIME [SMIME]などのメカニズムが同様に推奨されます。
The data that are collected as input to a reputation calculation are, in essence, a statement by one party about the actions or output of another. What one party says about another is often meant to be kept in confidence. Accordingly, steps often need to be taken to secure the submission of these input data to a reputation service provider.
評判計算への入力として収集されるデータは、本質的に、ある当事者による別の当事者の行動または出力に関する声明です。ある当事者が別の当事者について言っていることは、多くの場合、秘密にされることを意味します。したがって、これらの入力データのレピュテーションサービスプロバイダーへの送信を保護するために、多くの場合、手順を実行する必要があります。
Moreover, although the aggregated reputation is the product provided by this service, its inadvertent exposure can have undesirable effects. Just as the collection of data about a subject needs due consideration to privacy and security, so too does the output and storage of whatever aggregation the service provider applies.
さらに、集計された評判はこのサービスによって提供される製品ですが、その不注意な露出は望ましくない影響を与える可能性があります。サブジェクトに関するデータの収集にプライバシーとセキュリティへの十分な配慮が必要であるのと同様に、サービスプロバイダーが適用するあらゆる集約の出力とストレージも必要です。
The basic notion of collection and storage of reputation data is obviously a privacy issue in that the opinions of one party about another are likely to be sensitive. Inadvertent or unauthorized exposure of those data can lead to personal or commercial damage.
評判データの収集と保存の基本的な概念は、ある当事者の別の当事者の意見が機密である可能性が高いという点で、明らかにプライバシーの問題です。これらのデータが不注意または不正に公開されると、個人的または商業的な損害が発生する可能性があります。
When a client asks a service provider about a particular subject, the service provider can infer the existence of that subject and begin observing which clients ask about it. This can be an unanticipated leak of private information.
クライアントが特定のサブジェクトについてサービスプロバイダーに尋ねると、サービスプロバイダーはそのサブジェクトの存在を推測し、どのクライアントがそれについて尋ねるかの監視を開始できます。これは、個人情報の予期しない漏洩である可能性があります。
Reputation services that limit queries to authorized clients can cause private information, such as the reputations themselves or the data used to compute them, to be revealed if the client credentials are compromised. It is critical to safeguard not only the interchange of reputation information, and the information once it has been delivered to the client, but the ability to issue requests for information as well.
クエリを承認されたクライアントに制限するレピュテーションサービスは、クライアントの資格情報が侵害された場合に、レピュテーション自体やそれらの計算に使用されるデータなどの個人情報を明らかにする可能性があります。レピュテーション情報の交換、およびクライアントに配信された情報を保護するだけでなく、情報の要求を発行する機能も保護することが重要です。
An important consideration here is that compromised credentials are mainly an exposure of some third party (whose reputation is improperly revealed) rather than the client or the server.
ここでの重要な考慮事項は、侵害された資格情報は、主にクライアントやサーバーではなく、一部のサードパーティ（その評判が不適切に明らかにされている）にさらされていることです。
This document introduces an overall protocol architecture, but no implementation details. As such, the security considerations presented here are very high level. The detailed analysis of the various specific components of the protocol can be found in the documents that instantiate this architecture.
このドキュメントでは、全体的なプロトコルアーキテクチャを紹介しますが、実装の詳細は示しません。そのため、ここに示すセキュリティの考慮事項は非常に高いレベルです。プロトコルのさまざまな特定のコンポーネントの詳細な分析は、このアーキテクチャをインスタンス化するドキュメントに記載されています。
As with [VBR], an agent seeking to make use of a reputation reporting service is placing some trust that the service presents an unbiased "opinion" of the object about which reputation is being returned. The result of trusting the data is, presumably, to guide action taken by the reputation client. It follows, then, that bias in the reputation service can adversely affect the client. Clients therefore need to be aware of this possibility and the effect it might have. For example, a biased system returning a reputation about a DNS domain found in email messages could result in the admission of spam, phishing, or malware through a mail gateway (by rating the domain name more favorably than warranted) or could result in the needless rejection or delay of mail (by rating the domain more unfavorably than warranted). As a possible mitigation strategy, clients might seek to interact only with reputation services that offer some disclosure of the computation methods for the results they return. Such disclosure and evaluation is beyond the scope of the present document.
[VBR]と同様に、レピュテーションレポートサービスを利用しようとするエージェントは、サービスがレピュテーションが返されているオブジェクトの公平な「意見」を提示するという信頼を置きます。データを信頼した結果は、おそらく、レピュテーションクライアントによって実行されたアクションを導くことになります。その結果、レピュテーションサービスの偏見がクライアントに悪影響を及ぼす可能性があります。したがって、クライアントはこの可能性とその可能性を認識する必要があります。たとえば、電子メールメッセージで見つかったDNSドメインについての評判を返す偏ったシステムは、メールゲートウェイを介したスパム、フィッシング、またはマルウェアの許可につながる可能性があります（ドメイン名を正当な評価よりも好意的に評価することにより）、または不要になる可能性があります。メールの拒否または遅延（ドメインを保証よりも不利に評価することにより）。可能な緩和戦略として、クライアントは、返す結果の計算方法をある程度開示するレピュテーションサービスとのみやり取りしようとする場合があります。そのような開示と評価は、現在の文書の範囲を超えています。
Similarly, a client placing trust in the results returned by such a service might suffer if the service itself is compromised, returning biased results under the control of an attacker without the knowledge of the agency providing the reputation service. This might result from an attack on the data being returned at the source, or from a man-in-the-middle attack. Protocols, therefore, need to be designed so as to be as resilient against such attacks as possible.
同様に、そのようなサービスによって返された結果を信頼するクライアントは、サービス自体が危険にさらされ、評判サービスを提供する機関の知識なしに攻撃者の制御下で偏った結果を返す場合に苦しむ可能性があります。これは、ソースで返されているデータへの攻撃、または中間者攻撃による可能性があります。したがって、プロトコルは、このような攻撃に対して可能な限り回復力があるように設計する必要があります。
Both clients and servers of reputation systems need to be resistant to attacks that involve malformed messages, deliberate or otherwise. Malformations can be used to confound clients and servers alike in terms of identifying the party or parties responsible for the content under evaluation. This can result in delivery of undesirable or even dangerous content.
レピュテーションシステムのクライアントとサーバーの両方が、意図的またはその他の方法で、不正な形式のメッセージを含む攻撃に耐性を持つ必要があります。奇形は、評価中のコンテンツの責任者を特定するという点で、クライアントとサーバーを混乱させるために使用できます。これにより、望ましくない、または危険なコンテンツが配信される可能性があります。
Involving a third party (in this case, a reputation service provider) that can influence the handling of incoming content involves ceding some amount of control to that third party. Numerous other topics related to the management, operation, and safe use of reputation systems can be found in [CONSIDERATIONS].
着信コンテンツの処理に影響を与える可能性のあるサードパーティ（この場合は、レピュテーションサービスプロバイダー）が関与するには、そのサードパーティにある程度の制御権を譲渡する必要があります。評判システムの管理、運用、安全な使用に関連する他の多くのトピックは、[考慮事項]にあります。
[CONSIDERATIONS] Kucherawy, M., "Operational Considerations Regarding Reputation Services", Work in Progress, May 2013.
[考慮事項] Kucherawy、M。、「評判サービスに関する運用上の考慮事項」、進行中の作業、2013年5月。
[DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, September 2011.
[DKIM] Crocker、D。、編、Hansen、T。、編、およびM. Kucherawy、編、「DomainKeys Identified Mail（DKIM）Signatures」、STD 76、RFC 6376、2011年9月。
[DNS] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[DNS] Mockapetris、P。、「ドメイン名-実装と仕様」、STD 13、RFC 1035、1987年11月。
[DNSBL] Levine, J., "DNS Blacklists and Whitelists", RFC 5782, February 2010.
[DNSBL] Levine、J。、「DNS Blacklists and Whitelists」、RFC 5782、2010年2月。
[EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.
[メールアーク]クロッカーD.、「インターネットメールアーキテクチャ」、RFC 5598、2009年7月。
[HTTP-TLS] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[HTTP-TLS] Rescorla、E。、「HTTP Over TLS」、RFC 2818、2000年5月。
[MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[メール] Resnick、P。、編、「インターネットメッセージ形式」、RFC 5322、2008年10月。
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part One：Format of Internet Message Bodies」、RFC 2045、1996年11月。
[OPENPGP] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
[OPENPGP] Callas、J.、Donnerhacke、L.、Finney、H.、Shaw、D。、およびR. Thayer、「OpenPGP Message Format」、RFC 4880、2007年11月。
[RANDOMHOUSE] "Random House Webster's Dictionary, Revised Edition", ISBN 978-0-345-44725-8, June 2001.
[ランダムハウス]「ランダムハウスウェブスターの辞書、改訂版」、ISBN 978-0-345-44725-8、2001年6月。
[RFC7071] Borenstein, N. and M. Kucherawy, "A Media Type for Reputation Interchange", RFC 7071, November 2013.
[RFC7071] Borenstein、N。およびM. Kucherawy、「評判交換のためのメディアタイプ」、RFC 7071、2013年11月。
[RFC7072] Borenstein, N. and M. Kucherawy, "A Reputation Query Protocol", RFC 7072, November 2013.
[RFC7072] Borenstein、N.およびM. Kucherawy、「A Reputation Query Protocol」、RFC 7072、2013年11月。
[RFC7073] Borenstein, N. and M. Kucherawy, "A Reputation Response Set for Email Identifiers", RFC 7073, November 2013.
[RFC7073] Borenstein、N。およびM. Kucherawy、「A Email Reidentation Response Set for Email Identifiers」、RFC 7073、2013年11月。
[SMIME] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[SMIME] Ramsdell、B。およびS. Turner、「Secure / Multipurpose Internet Mail Extensions（S / MIME）Version 3.2 Message Specification」、RFC 5751、2010年1月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[SMTP] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、2008年10月。
[VBR] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By Reference", RFC 5518, April 2009.
[VBR] Hoffman、P.、Levine、J。、およびA. Hathcock、「Vouch By Reference」、RFC 5518、2009年4月。
Authors' Addresses
著者のアドレス
Nathaniel Borenstein Mimecast 203 Crescent St., Suite 303 Waltham, MA 02453 USA
Nathaniel Borenstein Mimecast 203 Crescent St.、Suite 303 Waltham、MA 02453 USA
Phone: +1 781 996 5340
EMail: nsb@guppylake.com
Murray S. Kucherawy 270 Upland Drive San Francisco, CA 94127 USA
マレーS.クチェラウィ270アップランドドライブサンフランシスコ、カリフォルニア94127アメリカ
EMail: superuser@gmail.com