Internet Engineering Task Force (IETF) N. Borenstein
Request for Comments: 7070 Mimecast
Category: Standards Track M. Kucherawy
ISSN: 2070-1721 November 2013
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.
这是一份互联网标准跟踪文件。
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）的产品。它代表了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.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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.
历史上，许多互联网协议在未经认证的实体之间运行。例如，电子邮件的作者字段（发件人：）[MAIL]可以包含任何显示名称或地址，并且不会由收件人或传递路径上的其他代理验证。类似地，使用简单邮件传输协议[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.
近年来，显式身份验证机制开始得到更广泛的应用。例如，DomainKeys Identified Mail[DKIM]协议允许将经过验证的标识符与消息相关联。这种关联在密码学上很强，是对先前状态的改进，但它不区分好参与者和坏参与者的标识符。即使可以在作者字段中验证域名（例如“john”中的“trustry.example.com”）。doe@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".
随着这些认证协议的出现，可以满足对相互信任的各方可以交换关于其他参与者的评估信息的机制的要求。出于这些目的，我们可以将“声誉”定义为“对某个可识别参与者的估计，尤其是社区或互联网公众的估计”。（这是基于[RANDOMHOUSE]中“声誉”的定义）我们可以将个人评估的汇总称为“声誉输入”。
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
在电子邮件世界中，声誉服务的需求可能特别明显，滥用声誉服务的情况屡见不鲜，但其他互联网服务正受到攻击，可能也有类似的需求。例如，声誉机制可以用于对网站的安全性、互联网服务提供商（ISP）或应用程序服务提供商（ASP）的服务质量进行评级。更一般地说，使用声誉服务有许多不同的机会，例如电子商务中的客户满意度
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.
网站，甚至与互联网协议无关的东西，如水管工、酒店或书籍。正如人类传统上依赖于物理世界中受信任方的推荐一样，人们也可以期望他们在互联网上的各种应用程序中使用这种声誉服务。
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.
完全信任体系结构包含一系列参与者和活动，以支持用于创建、交换和使用信任相关信息的端到端服务。其中一个组件是查询机制，允许检索信誉。并非所有此类声誉服务都需要传达相同的信息。一些只需要提供基本评级，而另一些则需要提供基本细节。这类似于支票批准和信用报告之间的区别。
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.
总体上可以对好坏进行定义，但具体的应用程序可能需要描述多个属性的声誉：电子商务网站可能根据价格、交付速度、客户服务等进行评级，并且每个属性的评级可能非常不同。因此，该体系结构定义了通用查询机制和信誉检索的基本格式，但允许对每个应用程序进行扩展。
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.
在接收到客户端运营商希望评估的某些内容（例如，因特网消息）时，客户端从内容中提取一个或多个要评估的感兴趣的标识符。这方面的示例包括在消息的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]描述了如何使用超文本传输协议（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区块列表[DNSBL]进行传输）。声誉传输的每个规范独立于任何其他规范。
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 |
+-------------+ \~~~~~~~~~~/ +------------+
+-------------+ +------------+
| 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.
有关Internet消息传递体系结构的一般说明，请参见[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服务提供一个或多个稳定标识符，该标识符是信誉查询的基础。收到MTA的消息后，DKIM服务提供一组（可能为空）已验证的标识符（在本例中为域名），这些标识符是标识符评估员进行信誉查询的主题。标识符评估器查询信誉服务以确定所提供标识符的信誉，并将标识符及其信誉传递给处理过滤器。处理过滤器根据这些和其他有关消息的输入（可能包括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.
应用程序具有不同的兴趣属性集，因此查询的主题和结果响应会有所不同，以便在各自的上下文中描述实体的声誉。例如，应用程序“movies”将具有与“restaurants”不同的一组感兴趣的属性和相关评级（见下文）。因此，有必要对其进行正式定义。
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".
响应集的关键属性之一称为“断言”。断言是关于声誉查询主题的声明。例如，有人可能会断言某家餐厅供应的食物很好。在这种架构的背景下，断言将是“提供优质食物”。
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之间（含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”值的两倍。它还允许更轻松地汇总从多个声誉服务提供商收集的评级。
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.
“reputon”是包含对信誉查询的基本响应的对象。它以序列化形式包含与查询主题相关的响应集。它的特定编码留给实现此体系结构的文档。
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.
例如，“电子邮件发送域”的信誉响应集可能需要一个规范；响应集可能包含有关从该域接收垃圾邮件的频率的信息。
[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），并相应地传输。它也可以是专门构建的协议的完整有效载荷。对于基本请求/响应场景，一个实体（客户端）将向第二个实体（服务器）请求关于第三个实体（主体）的信誉数据，第二个实体将使用这些数据进行响应。
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.
这里描述的体系结构既不建议也不排除任何特定的数据传输机制。[RFC7072]中定义了HTTP机制，还设想了基于电子邮件的机制。对于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.，Ed.，Hansen，T.，Ed.，和M.Kucherawy，Ed.，“域密钥识别邮件（DKIM）签名”，STD 76，RFC 63762011年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黑名单和白名单”，RFC 5782，2010年2月。
[EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.
[EMAIL-ARCH]Crocker，D.，“互联网邮件体系结构”，RFC 55982009年7月。
[HTTP-TLS] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[HTTP-TLS]Rescorla，E.，“TLS上的HTTP”，RFC 28182000年5月。
[MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[邮件]Resnick，P.，Ed.，“互联网信息格式”，RFC5322，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，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年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消息格式”，RFC 48802007年11月。
[RANDOMHOUSE] "Random House Webster's Dictionary, Revised Edition", ISBN 978-0-345-44725-8, June 2001.
[RANDOMHOUSE]“RANDOMHOUSE-Webster字典，修订版”，ISBN 978-0-345-44725-82001年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，“声誉查询协议”，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，“电子邮件标识符的声誉响应集”，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，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 5751，2010年1月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[SMTP]Klensin，J.，“简单邮件传输协议”，RFC 53212008年10月。
[VBR] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By Reference", RFC 5518, April 2009.
[VBR]Hoffman，P.，Levine，J.和A.Hathcock，“参考凭证”，RFC 5518，2009年4月。
Authors' Addresses
作者地址
Nathaniel Borenstein Mimecast 203 Crescent St., Suite 303 Waltham, MA 02453 USA
美国马萨诸塞州沃尔瑟姆新月街203号303室Nathaniel Borenstein Mimecast 02453
Phone: +1 781 996 5340
EMail: nsb@guppylake.com
Phone: +1 781 996 5340
EMail: nsb@guppylake.com
Murray S. Kucherawy 270 Upland Drive San Francisco, CA 94127 USA
Murray S. Kucherawy 270高地驱动旧金山，CA 94127美国
EMail: superuser@gmail.com
EMail: superuser@gmail.com