summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7070.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7070.txt')
-rw-r--r--doc/rfc/rfc7070.txt787
1 files changed, 787 insertions, 0 deletions
diff --git a/doc/rfc/rfc7070.txt b/doc/rfc/rfc7070.txt
new file mode 100644
index 0000000..4fcfd95
--- /dev/null
+++ b/doc/rfc/rfc7070.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+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.
+
+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.
+
+ 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.
+
+Copyright Notice
+
+ Copyright (c) 2013 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.
+
+
+
+
+
+
+Borenstein & Kucherawy Standards Track [Page 1]
+
+RFC 7070 Reputation Architecture November 2013
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Borenstein & Kucherawy Standards Track [Page 2]
+
+RFC 7070 Reputation Architecture November 2013
+
+
+1. Introduction
+
+ 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.
+
+ 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.
+
+ 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
+
+
+
+Borenstein & Kucherawy Standards Track [Page 3]
+
+RFC 7070 Reputation Architecture November 2013
+
+
+ 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.
+
+2. Overview
+
+ 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.
+
+
+
+
+Borenstein & Kucherawy Standards Track [Page 4]
+
+RFC 7070 Reputation Architecture November 2013
+
+
+ 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.
+
+3. Related Documents
+
+ 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.
+
+ [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.
+
+ 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.
+
+4. High-Level Architecture
+
+ 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 The types and content of queries that can be supported;
+
+ o The extensible range of response information that can be provided;
+
+ o Query/response transport conventions.
+
+ 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.
+
+
+
+Borenstein & Kucherawy Standards Track [Page 5]
+
+RFC 7070 Reputation Architecture November 2013
+
+
+ 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.
+
+4.1. Example of a Reputation Service Being Used
+
+ 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:
+
+ +-------------+ +------------+
+ | 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
+
+
+
+
+
+
+Borenstein & Kucherawy Standards Track [Page 6]
+
+RFC 7070 Reputation Architecture November 2013
+
+
+ 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.
+
+ 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.
+
+5. Terminology and Definitions
+
+ This section defines terms used in the rest of the document.
+
+5.1. Application
+
+ 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.
+
+5.2. Response Set
+
+ 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;
+
+
+
+Borenstein & Kucherawy Standards Track [Page 7]
+
+RFC 7070 Reputation Architecture November 2013
+
+
+ o the Assertion (see Section 5.3);
+
+ o the Rating (see Section 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 registries are created in [RFC7071].
+
+5.3. Assertions and Ratings
+
+ 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.
+
+ 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.
+
+
+
+
+
+Borenstein & Kucherawy Standards Track [Page 8]
+
+RFC 7070 Reputation Architecture November 2013
+
+
+5.4. Reputon
+
+ 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.
+
+6. Information Represented in the Protocol
+
+ 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 the name of the reputation context ("Application"; see
+ Section 5.1);
+
+ o optionally, name(s) of the specific reputation assertions of
+ interest.
+
+ 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 the identity of the entity being rated;
+
+ o the application context for the query (e.g., email address
+ evaluation);
+
+ o the overall rating score for that entity.
+
+ 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.
+
+
+
+Borenstein & Kucherawy Standards Track [Page 9]
+
+RFC 7070 Reputation Architecture November 2013
+
+
+7. Information Flow in the Reputation Query Protocol
+
+ 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.
+
+ 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.
+
+8. Privacy Considerations
+
+8.1. Data in Transit
+
+ 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.
+
+ 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.
+
+
+
+Borenstein & Kucherawy Standards Track [Page 10]
+
+RFC 7070 Reputation Architecture November 2013
+
+
+8.2. Aggregation
+
+ 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.
+
+8.3. Collection of Data
+
+ 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.
+
+8.4. Queries Can Reveal Information
+
+ 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.
+
+8.5. Compromised Relationships
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+Borenstein & Kucherawy Standards Track [Page 11]
+
+RFC 7070 Reputation Architecture November 2013
+
+
+9. Security Considerations
+
+ 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.
+
+9.1. Biased Reputation Agents
+
+ 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.
+
+ 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.
+
+9.2. Malformed Messages
+
+ 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.
+
+
+
+
+
+
+
+Borenstein & Kucherawy Standards Track [Page 12]
+
+RFC 7070 Reputation Architecture November 2013
+
+
+9.3. Further Discussion
+
+ 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].
+
+10. Informative References
+
+ [CONSIDERATIONS]
+ Kucherawy, M., "Operational Considerations Regarding
+ Reputation Services", Work in Progress, May 2013.
+
+ [DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy,
+ Ed., "DomainKeys Identified Mail (DKIM) Signatures",
+ STD 76, RFC 6376, September 2011.
+
+ [DNS] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [DNSBL] Levine, J., "DNS Blacklists and Whitelists", RFC 5782,
+ February 2010.
+
+ [EMAIL-ARCH]
+ Crocker, D., "Internet Mail Architecture", RFC 5598,
+ July 2009.
+
+ [HTTP-TLS] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
+
+ [MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322,
+ October 2008.
+
+ [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format of Internet Message
+ Bodies", RFC 2045, November 1996.
+
+ [OPENPGP] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
+ Thayer, "OpenPGP Message Format", RFC 4880,
+ November 2007.
+
+ [RANDOMHOUSE]
+ "Random House Webster's Dictionary, Revised Edition",
+ ISBN 978-0-345-44725-8, June 2001.
+
+
+
+
+
+
+
+Borenstein & Kucherawy Standards Track [Page 13]
+
+RFC 7070 Reputation Architecture November 2013
+
+
+ [RFC7071] Borenstein, N. and M. Kucherawy, "A Media Type for
+ Reputation Interchange", RFC 7071, November 2013.
+
+ [RFC7072] Borenstein, N. and M. Kucherawy, "A Reputation Query
+ Protocol", RFC 7072, November 2013.
+
+ [RFC7073] Borenstein, N. and M. Kucherawy, "A Reputation Response
+ Set for Email Identifiers", RFC 7073, November 2013.
+
+ [SMIME] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
+ Mail Extensions (S/MIME) Version 3.2 Message
+ Specification", RFC 5751, January 2010.
+
+ [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
+ October 2008.
+
+ [VBR] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By
+ Reference", RFC 5518, April 2009.
+
+Authors' Addresses
+
+ 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
+
+ EMail: superuser@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Borenstein & Kucherawy Standards Track [Page 14]
+