Skip to main content

An Architecture for Reputation Reporting

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7070.
Authors Dr. Nathaniel S. Borenstein , Murray Kucherawy , Andrew Sullivan
Last updated 2015-10-14 (Latest revision 2013-09-17)
Replaces draft-kucherawy-reputation-model
RFC stream Internet Engineering Task Force (IETF)
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Document shepherd Dave Crocker
Shepherd write-up Show Last changed 2013-05-25
IESG IESG state RFC 7070 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Pete Resnick
Send notices to (None)
IANA IANA review state Version Changed - Review Needed
IANA action state No IANA Actions
REPUTE Working Group                                       N. Borenstein
Internet-Draft                                                  Mimecast
Intended status: Standards Track                            M. Kucherawy
Expires: March 21, 2014
                                                        A. Sullivan, Ed.
                                                               Dyn, Inc.
                                                      September 17, 2013

                An Architecture for Reputation Reporting


   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 RFC4101 for describing a
   protocol model.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 21, 2014.

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
   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect

Borenstein, et al.       Expires March 21, 2014                 [Page 1]
Internet-Draft           Reputation Architecture          September 2013

   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.

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  . . . . . . . . . . . . . . . . .  8
     5.1.  Application  . . . . . . . . . . . . . . . . . . . . . . .  8
     5.2.  Response Set . . . . . . . . . . . . . . . . . . . . . . .  8
     5.3.  Assertions and Ratings . . . . . . . . . . . . . . . . . .  9
     5.4.  Reputon  . . . . . . . . . . . . . . . . . . . . . . . . .  9
   6.  Information Represented in the Protocol  . . . . . . . . . . .  9
   7.  Information Flow in the Reputation Query Protocol  . . . . . . 10
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   9.  Privacy Considerations . . . . . . . . . . . . . . . . . . . . 11
     9.1.  Data In Transit  . . . . . . . . . . . . . . . . . . . . . 11
     9.2.  Aggregation  . . . . . . . . . . . . . . . . . . . . . . . 11
     9.3.  Collection Of Data . . . . . . . . . . . . . . . . . . . . 12
     9.4.  Queries Can Reveal Information . . . . . . . . . . . . . . 12
     9.5.  Compromised Relationships  . . . . . . . . . . . . . . . . 12
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 12
     10.1. Biased Reputation Agents . . . . . . . . . . . . . . . . . 13
     10.2. Malformed Messages . . . . . . . . . . . . . . . . . . . . 13
     10.3. Further Discussion . . . . . . . . . . . . . . . . . . . . 13
   11. Informative References . . . . . . . . . . . . . . . . . . . . 14
   Appendix A.  Public Discussion . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15

Borenstein, et al.       Expires March 21, 2014                 [Page 2]
Internet-Draft           Reputation Architecture          September 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 sending email server 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 othewise be.

   In recent years, explicit identity authentication mechanisms have
   begun to see wider deployment.  For example, the [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.
   "" in "")
   there is no basis for knowing whether it is associated with a good
   actor 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
   statisfy 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" from the 2013 Random House dictionary.)
   We may call an aggregation of individual assessments "reputation

   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, et al.       Expires March 21, 2014                 [Page 3]
Internet-Draft           Reputation Architecture          September 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 versus 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 DomainKeys

Borenstein, et al.       Expires March 21, 2014                 [Page 4]
Internet-Draft           Reputation Architecture          September 2013

   Identified Mail (DKIM) signature.

   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

   For the purposes of sending and receiving reputation information,
   [I-D.REPUTE-MEDIA-TYPE] 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.

   [I-D.REPUTE-QUERY-HTTP] 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, [I-D.REPUTE-EMAIL-IDENTIFIERS] defines (and registers) a
   first, common, reputation application, namely the evaluation of
   portions of an email message as subjects for reputation queries and

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

Borenstein, et al.       Expires March 21, 2014                 [Page 5]
Internet-Draft           Reputation Architecture          September 2013

   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

   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 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
   DomainKeys Identified Mail (DKIM; see [DKIM]) to affix a stable
   identifier to a message and then uses that as a basis for evaluation:

Borenstein, et al.       Expires March 21, 2014                 [Page 6]
Internet-Draft           Reputation Architecture          September 2013

        +-------------+                           +------------+
        |   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

   (See [EMAIL-ARCH] for a general description of the Internet messaging
   architecture.)  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 -- which are the subjects
   of reputation queries made by the Identity 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

Borenstein, et al.       Expires March 21, 2014                 [Page 7]
Internet-Draft           Reputation Architecture          September 2013

   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;

   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

Borenstein, et al.       Expires March 21, 2014                 [Page 8]
Internet-Draft           Reputation Architecture          September 2013

   Registry in order to prevent name collisions and provide convenient
   references to the documents.

   IANA registries are created in a separate document.

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 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.

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;

Borenstein, et al.       Expires March 21, 2014                 [Page 9]
Internet-Draft           Reputation Architecture          September 2013

   o  the name of the reputation context ("Application"; see
      Section 5.1);

   o  optionally, name(s) of the specific reputation assertions of

   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

   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.

   Additional documents define a media type and format for reputation
   data, and protocols for exchanging such data.

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 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.

Borenstein, et al.       Expires March 21, 2014                [Page 10]
Internet-Draft           Reputation Architecture          September 2013

8.  IANA Considerations

   This document presents no actions for IANA.

   [RFC Editor: Please remove this section prior to publication.]

9.  Privacy Considerations

9.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 MUST 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 [I-D.REPUTE-QUERY-HTTP], and email-based mechanisms are
   also envisioned.  For HTTP, use of HTTP over TLS [HTTP-TLS] is very
   strongly advised.  For email, mechanisms such as OpenPGP [OPENPGP]
   and S/MIME [SMIME] are similarly advised.

9.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

Borenstein, et al.       Expires March 21, 2014                [Page 11]
Internet-Draft           Reputation Architecture          September 2013

   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.

9.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.

9.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.

9.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.

10.  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 analyses of the
   various specific components of the protocol can be found the
   documents that instantiate this architecture.

Borenstein, et al.       Expires March 21, 2014                [Page 12]
Internet-Draft           Reputation Architecture          September 2013

10.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 favourably than warranted) or could
   result in the needless rejection or delay of mail (by rating the
   domain more unfavourably 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.

10.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.

10.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 [I-D.REPUTE-CONSIDERATIONS].

Borenstein, et al.       Expires March 21, 2014                [Page 13]
Internet-Draft           Reputation Architecture          September 2013

11.  Informative References

   [DKIM]     Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
              "DomainKeys Identified Mail (DKIM) Signatures", 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.

              Crocker, D., "Internet Mail Architecture", RFC 5598,
              July 2009.

              Rescorla, E., "HTTP over TLS", RFC 2818, May 2000.

              Kucherawy, M., "Operational Considerations Regarding
              Reputation Services", draft-ietf-repute-considerations
              (work in progress), November 2012.

              Borenstein, N. and M. Kucherawy, "A Reputation Vocabulary
              for Email Identifiers",
              draft-ietf-repute-email-identifiers (work in progress),
              November 2012.

              Borenstein, N. and M. Kucherawy, "A Media Type for
              Reputation Interchange", draft-ietf-repute-media-type
              (work in progress), November 2012.

              Borenstein, N. and M. Kucherawy, "Reputation Data
              Interchange using HTTP and XML",
              draft-ietf-repute-query-http (work in progress),
              November 2012.

   [MAIL]     Resnick, P., "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.

Borenstein, et al.       Expires March 21, 2014                [Page 14]
Internet-Draft           Reputation Architecture          September 2013

   [OPENPGP]  Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
              Thayer, "OpenPGP Message Format", RFC 4880, November 2007.

   [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.

Appendix A.  Public Discussion

   Public discussion of this suite of documents takes place on the mailing list.  See

Authors' Addresses

   Nathaniel Borenstein
   203 Crescent St., Suite 303
   Waltham, MA  02453

   Phone: +1 781 996 5340

   Murray S. Kucherawy
   270 Upland Drive
   San Francisco, CA  94127


Borenstein, et al.       Expires March 21, 2014                [Page 15]
Internet-Draft           Reputation Architecture          September 2013

   Andrew Sullivan (editor)
   Dyn, Inc.
   150 Dow St.
   Manchester, NH  03101


Borenstein, et al.       Expires March 21, 2014                [Page 16]