idnits 2.17.1 draft-ietf-repute-model-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 459: '...ecure. Services MUST use a transport ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 17, 2013) is 3836 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 2818 (ref. 'HTTP-TLS') (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 5751 (ref. 'SMIME') (Obsoleted by RFC 8551) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 REPUTE Working Group N. Borenstein 3 Internet-Draft Mimecast 4 Intended status: Standards Track M. Kucherawy 5 Expires: March 21, 2014 6 A. Sullivan, Ed. 7 Dyn, Inc. 8 September 17, 2013 10 An Architecture for Reputation Reporting 11 draft-ietf-repute-model-10 13 Abstract 15 This document describes a general architecture for a reputation-based 16 service, allowing one to request reputation-related data over the 17 Internet, where "reputation" refers to predictions or expectations 18 about an entity or an identifier such as a domain name. The document 19 roughly follows the recommendations of RFC4101 for describing a 20 protocol model. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on March 21, 2014. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Related Documents . . . . . . . . . . . . . . . . . . . . . . 5 59 4. High-Level Architecture . . . . . . . . . . . . . . . . . . . 5 60 4.1. Example of a Reputation Service Being Used . . . . . . . . 6 61 5. Terminology and Definitions . . . . . . . . . . . . . . . . . 8 62 5.1. Application . . . . . . . . . . . . . . . . . . . . . . . 8 63 5.2. Response Set . . . . . . . . . . . . . . . . . . . . . . . 8 64 5.3. Assertions and Ratings . . . . . . . . . . . . . . . . . . 9 65 5.4. Reputon . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 6. Information Represented in the Protocol . . . . . . . . . . . 9 67 7. Information Flow in the Reputation Query Protocol . . . . . . 10 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 69 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 11 70 9.1. Data In Transit . . . . . . . . . . . . . . . . . . . . . 11 71 9.2. Aggregation . . . . . . . . . . . . . . . . . . . . . . . 11 72 9.3. Collection Of Data . . . . . . . . . . . . . . . . . . . . 12 73 9.4. Queries Can Reveal Information . . . . . . . . . . . . . . 12 74 9.5. Compromised Relationships . . . . . . . . . . . . . . . . 12 75 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 10.1. Biased Reputation Agents . . . . . . . . . . . . . . . . . 13 77 10.2. Malformed Messages . . . . . . . . . . . . . . . . . . . . 13 78 10.3. Further Discussion . . . . . . . . . . . . . . . . . . . . 13 79 11. Informative References . . . . . . . . . . . . . . . . . . . . 14 80 Appendix A. Public Discussion . . . . . . . . . . . . . . . . . . 15 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 83 1. Introduction 85 Historically, many Internet protocols have operated between 86 unauthenticated entities. For example, an email message's author 87 field (From) [MAIL] can contain any display name or address and is 88 not verified by the recipient or other agents along the delivery 89 path. Similarly, a sending email server using the Simple Mail 90 Transfer Protocol [SMTP] trusts that the Domain Name System [DNS] has 91 led it to the intended receiving server. Both kinds of trust are 92 easily betrayed, opening the operation to subversion of some kind, 93 which makes spam, phishing, and other attacks even easier than they 94 would othewise be. 96 In recent years, explicit identity authentication mechanisms have 97 begun to see wider deployment. For example, the [DKIM] protocol 98 permits associating a validated identifier to a message. This 99 association is cryptographically strong, and is an improvement over 100 the prior state of affairs, but it does not distinguish between 101 identifiers of good actors and bad. Even when it is possible to 102 validate the domain name in an author field (e.g. 103 "trustworthy.example.com" in "john.doe@trustworthy.example.com") 104 there is no basis for knowing whether it is associated with a good 105 actor worthy of trust. As a practical matter, both bad actors and 106 good adopt basic authentication mechanisms like DKIM. In fact, bad 107 actors tend to adopt them even more rapidly than the good actors do 108 in the hope that some receivers will confuse identity authentication 109 with identity assessment. The former merely means that the name is 110 being used by its owner or their agent, while the latter makes a 111 statement about the quality of the owner. 113 With the advent of these authentication protocols, it is possible to 114 statisfy the requirement for a mechanism by which mutually trusted 115 parties can exchange assessment information about other actors. For 116 these purposes, we may usefully define "reputation" as "the 117 estimation in which an identifiable actor is held, especially by the 118 community or the Internet public generally". (This is based on the 119 definition of "reputation" from the 2013 Random House dictionary.) 120 We may call an aggregation of individual assessments "reputation 121 input." 123 While the need for reputation services has been perhaps especially 124 clear in the email world, where abuses are commonplace, other 125 Internet services are coming under attack and may have a similar 126 need. For instance, a reputation mechanism could be useful in rating 127 the security of web sites, the quality of service of an Internet 128 Service Provider (ISP), or an Application Service Provider (ASP). 129 More generally, there are many different opportunities for use of 130 reputation services, such as customer satisfaction at e-commerce 131 sites, and even things unrelated to Internet protocols, such as 132 plumbers, hotels, or books. Just as human beings traditionally rely 133 on the recommendations of trusted parties in the physical world, so 134 too they can be expected to make use of such reputation services in a 135 variety of applications on the Internet. 137 A full trust architecture encompasses a range of actors and 138 activities, to enable an end-to-end service for creating, exchanging, 139 and consuming trust-related information. One component of that is a 140 query mechanism, to permit retrieval of a reputation. Not all such 141 reputation services will need to convey the same information. Some 142 need only to produce a basic rating, while others need to provide 143 underlying detail. This is akin to the difference between check 144 approval versus a credit report. 146 An overall reckoning of goodness versus badness can be defined 147 generically, but specific applications are likely to want to describe 148 reputations for multiple attributes: an e-commerce site might be 149 rated on price, speed of delivery, customer service, etc., and might 150 receive very different ratings on each. Therefore, the architecture 151 defines a generic query mechanism and basic format for reputation 152 retrieval, but allows extensions for each application. 154 Omitted from this architecture is the means by which a reputation- 155 reporting agent goes about collecting such data and the method for 156 creating an evaluation. The mechanism defined here merely enables 157 asking a question and getting an answer; the remainder of an overall 158 service provided by such a reputation agent is specific to the 159 implementation of that service and is out of scope here. 161 2. Overview 163 The basic premise of this reputation system involves a client that is 164 seeking to evaluate content based on an identifier associated with 165 the content, and a reputation service provider that collects, 166 aggregates, and makes available for consumption, scores based on the 167 collected data. Typically client and service operators enter into 168 some kind of agreement during which some parameters are exchanged, 169 such as: the location at which the reputation service can be reached, 170 the nature of the reputation data being offered, possibly some client 171 authentication details, and the like. 173 Upon receipt of some content the client operator wishes to evaluate 174 (an Internet message, for example), the client extracts from the 175 content one or more identifiers of interest to be evaluated. 176 Examples of this include the domain name found in the From: field of 177 a message, or the domain name extracted from a valid DomainKeys 178 Identified Mail (DKIM) signature. 180 Next, the goal is to ask the reputation service provider what the 181 reputation of the extracted identifier is. The query will contain 182 the identifier to be evaluated and possibly some context-specific 183 information (such as to establish the context of the query, e.g., an 184 email message) or client-specific information. The client typically 185 folds the data in the response into whatever local evaluation logic 186 it applies to decide what disposition the content deserves. 188 3. Related Documents 190 This document presents a high-level view of the reputation 191 architecture. 193 For the purposes of sending and receiving reputation information, 194 [I-D.REPUTE-MEDIA-TYPE] defines a media type for containing responses 195 to reputation queries, and a serialization format for these data 196 (with examples). It also creates the registry for specific 197 reputation contexts and the parameters related to them. 199 [I-D.REPUTE-QUERY-HTTP] describes how to construct and issue 200 reputation queries and replies in the context of this architecture 201 using the HyperText Transport Protocol (HTTP) as the query protocol. 203 Finally, [I-D.REPUTE-EMAIL-IDENTIFIERS] defines (and registers) a 204 first, common, reputation application, namely the evaluation of 205 portions of an email message as subjects for reputation queries and 206 replies. 208 4. High-Level Architecture 210 This document outlines the reputation query and response mechanism. 211 It provides the following definitions: 213 o Vocabulary for the current work and work of this type; 215 o The types and content of queries that can be supported; 217 o The extensible range of response information that can be provided; 219 o Query/response transport conventions. 221 It provides an extremely simple query/response model that can be 222 carried over a variety of transports, including the Domain Name 223 System. (Although not typically thought of as a 'transport', the DNS 224 provides generic capabilities and can be thought of as a mechanism 225 for transporting queries and responses that have nothing to do with 226 Internet addresses, such as is done with a DNS BlockList [DNSBL].) 227 Each specification for Repute transport is independent of any other 228 specification. 230 The precise syntaxes of both the query and response are application- 231 specific. An application within this architecture defines the 232 parameters available to queries of that type, and also defines the 233 data returned in response to any query. 235 4.1. Example of a Reputation Service Being Used 237 A reputation mechanism functions as a component of an overall 238 service. A current example is that of an email system that uses 239 DomainKeys Identified Mail (DKIM; see [DKIM]) to affix a stable 240 identifier to a message and then uses that as a basis for evaluation: 242 +-------------+ +------------+ 243 | Sender | | Recipient | 244 +-------------+ +------------+ 245 | ^ 246 V | 247 +-------------+ +------------+ 248 | MSA | | MDA | 249 +-------------+ +------------+ 250 | ^ 251 | | 252 | +------------+ 253 | | Handling | 254 | | Filter | 255 | +------------+ 256 | ^ 257 | | 258 | +------------+ +------------+ 259 | | Reputation |<=====>| Identifier | 260 | | Service | | Assessor | 261 | +------------+ +------------+ 262 | ^ 263 V | 264 +------------+ Responsible Identifier +------------+ 265 | Identifier |. . . . . . . . . . . . . .>| Identifier | 266 | Signer | (DKIM) | Verifier | 267 +------------+ +------------+ 268 | ^ 269 V | 270 +-------------+ /~~~~~~~~~~\ +------+-----+ 271 | MTA |----->( other MTAs )------>| MTA | 272 +-------------+ \~~~~~~~~~~/ +------------+ 274 Figure 1: Actors in a Trust Sequence Using DKIM 276 (See [EMAIL-ARCH] for a general description of the Internet messaging 277 architecture.) In this figure, the solid lines indicate the flow of 278 a message; the dotted line indicates transfer of validated 279 identifiers within the message content; and the double line shows the 280 query and response of the reputation information. 282 Here, the DKIM Service provides one or more stable identifiers that 283 is the basis for the reputation query. On receipt of a message from 284 an MTA, the DKIM Service provides a (possibly empty) set of validated 285 identifiers -- domain names, in this case -- which are the subjects 286 of reputation queries made by the Identity Assessor. The Identifier 287 Assessor queries a Reputation Service to determine the reputation of 288 the provided identifiers, and delivers the identifiers and their 289 reputations to the Handling Filter. The Handling Filter makes a 290 decision about whether and how to deliver the message to the 291 recipient based on these and other inputs about the message, possibly 292 including evaluation mechanisms in addition to DKIM. 294 5. Terminology and Definitions 296 This section defines terms used in the rest of the document. 298 5.1. Application 300 An "Application" is a specific context in which reputation queries 301 are made. Some obvious popular examples include restaurants, movies, 302 or providers of various services. 304 Applications have different sets of attributes of interest, and so 305 the subjects of queries and the resulting responses will vary in 306 order to describe the reputations of entities in their respective 307 contexts. For example, the Application "movies" would have a 308 different set of properties of interest and associated ratings (see 309 below) from "restaurants". It is therefore necessary for them to be 310 formally defined. 312 5.2. Response Set 314 A "Response Set" is a representation for data that are returned in 315 response to a reputation query about a particular entity within the 316 context of an Application. A Response Set will always contain at 317 least the following components: 319 o the name of the entity being rated; 321 o the Assertion (see Section 5.3); 323 o the Rating (see Section 5.3). 325 The full content of the Response Set is specific to the Application; 326 though all Applications have these few key response set fields in 327 common, some of the reputation data returned in the evaluation of 328 email senders would be different than that returned about a movie, 329 restaurant, or baseball player. The specific meaning of a Rating is 330 also specific to an Application. 332 A Response Set is declared in a specification document, along with a 333 symbolic name representing the Application. The specifying documents 334 will include the details of query parameters and responses particular 335 to that Application. The symbolic names and corresponding specifying 336 documents are registered with IANA in the Reputation Applications 337 Registry in order to prevent name collisions and provide convenient 338 references to the documents. 340 IANA registries are created in a separate document. 342 5.3. Assertions and Ratings 344 One of the key properties of a Response Set is called an Assertion. 345 Assertions are claims made about the subject of a reputation query. 346 For example, one might assert that a particular restaurant serves 347 good food. In the context of this architecture, the assertion would 348 be "serves good food". 350 Assertions are coupled with a numeric value called a Rating, which is 351 an indication of how much the party generating the Response Set 352 agrees with the assertion being made. Ratings are typically 353 expressed as a floating point value between 0.0 and 1.0 inclusive, 354 with the former indicating no support for the assertion and the 355 latter indicating total agreement with the assertion. 357 The documents that define applications will also specify the type of 358 scale in use when generating ratings, to which all reputation service 359 providers for that application space must adhere. This will allow a 360 client to change which reputation service provider is being queried 361 without having to learn through some out-of-band method what the new 362 provider's ratings mean. For example, a registration might state 363 that ratings are linear, which would mean a score of "x" is twice as 364 strong as a value of "x/2". It also allows easier aggregation of 365 ratings collected from multiple reputation service providers. 367 5.4. Reputon 369 A "reputon" is an object that comprises the basic response to a 370 reputation query. It contains the response set relevant to the 371 subject of the query in a serialized form. Its specific encoding is 372 left to documents that implement this architecture. 374 6. Information Represented in the Protocol 376 Regardless of the transport selected for the interchange, the basic 377 information to be represented in the protocol is fairly simple, and 378 normally includes at least the following data: 380 In the query: 382 o the subject of the query; 383 o the name of the reputation context ("Application"; see 384 Section 5.1); 386 o optionally, name(s) of the specific reputation assertions of 387 interest. 389 Different transports, or different reputation contexts, might need 390 additional query parameters. 392 In the response: 394 o the identity of the entity providing the reputation information; 396 o the identity of the entity being rated; 398 o the application context for the query (e.g., email address 399 evaluation); 401 o the overall rating score for that entity. 403 Beyond this, arbitrary amounts of additional information might be 404 included for specific uses of the service. The entire collection of 405 data found in the response is the Response Set for that application, 406 and is defined in specifying documents as described above. 408 For example, a specification might be needed for a reputation 409 Response Set for an "email-sending-domain"; the Response Set might 410 include information on how often spam was received from that domain. 412 Additional documents define a media type and format for reputation 413 data, and protocols for exchanging such data. 415 7. Information Flow in the Reputation Query Protocol 417 The basic Response Set could be wrapped into a new MIME media type 418 [MIME] or a DNS RR, and transported accordingly. It also could be 419 the integral payload of a purpose-built protocol. For a basic 420 request/response scenario, one entity (the client) will ask a second 421 entity (the server) for reputation data about a third entity (the 422 subject), and the second entity will respond with those data. 424 An application might benefit from an extremely lightweight mechanism, 425 supporting constrained queries and responses, while others might need 426 to support larger and more complex responses. 428 8. IANA Considerations 430 This document presents no actions for IANA. 432 [RFC Editor: Please remove this section prior to publication.] 434 9. Privacy Considerations 436 9.1. Data In Transit 438 Some reputation exchanges can be sensitive, and should not be shared 439 publicly. A client making use of this framework is explicitly 440 revealing that it is interested in particular subjects, and the 441 server is revealing what its information sources have reported about 442 those subjects (in the aggregate). In the email context, for 443 example, a client is revealing from whom it receives email, and the 444 server is revealing what it (based on its aggregated data) believes 445 to be true about those subjects. 447 These can be sensitive things that need to be secured, particularly 448 when a client is talking to a server outside of its own 449 administrative domain. Furthermore, certain types of reputation 450 information are typically perceived as more sensitive than others; 451 movie ratings, for example, are much less damaging if leaked than a 452 person's credit rating. 454 For interchanges that are sensitive to such exposures, it is 455 imperative to protect the information from unauthorized access and 456 viewing, and possibly add the capability to do object-level integrity 457 and origin verification. Not all transport options can be adequately 458 secured in these ways. In particular, DNS queries and responses are 459 entirely insecure. Services MUST use a transport method that 460 provides adequate security when privacy-sensitive data are involved. 462 The architecture described here neither suggests nor precludes any 463 particular transport mechanism for the data. An HTTP mechanism is 464 defined in [I-D.REPUTE-QUERY-HTTP], and email-based mechanisms are 465 also envisioned. For HTTP, use of HTTP over TLS [HTTP-TLS] is very 466 strongly advised. For email, mechanisms such as OpenPGP [OPENPGP] 467 and S/MIME [SMIME] are similarly advised. 469 9.2. Aggregation 471 The data that are collected as input to a reputation calculation are 472 in essence a statement by one party about the actions or output of 473 another. What one party says about another is often meant to be kept 474 in confidence. Accordingly, steps often need to be taken to secure 475 the submission of these input data to a reputation service provider. 477 Moreover, although the aggregated reputation is the product provided 478 by this service, its inadvertent exposure can have undesirable 479 effects. Just as the collection of data about a subject needs due 480 consideration to privacy and security, so too does the output and 481 storage of whatever aggregation the service provider applies. 483 9.3. Collection Of Data 485 The basic notion of collection and storage of reputation data is 486 obviously a privacy issue in that the opinions of one party about 487 another are likely to be sensitive. Inadvertent or unauthorized 488 exposure of those data can lead to personal or commercial damage. 490 9.4. Queries Can Reveal Information 492 When a client asks a service provider about a particular subject, the 493 service provider can infer the existence of that subject and begin 494 observing which clients ask about it. This can be an unanticipated 495 leak of private information. 497 9.5. Compromised Relationships 499 Reputation services that limit queries to authorized clients can 500 cause private information, such as the reputations themselves or the 501 data used to compute them, to be revealed if the client credentials 502 are compromised. It is critical to safeguard not only the 503 interchange of reputation information, and the information once it 504 has been delivered to the client, but the ability to issue requests 505 for information as well. 507 An important consideration here is that compromised credentials are 508 mainly an exposure of some third party (whose reputation is 509 improperly revealed), rather than the client or the server. 511 10. Security Considerations 513 This document introduces an overall protocol architecture, but no 514 implementation details. As such, the security considerations 515 presented here are very high-level. The detailed analyses of the 516 various specific components of the protocol can be found the 517 documents that instantiate this architecture. 519 10.1. Biased Reputation Agents 521 As with [VBR], an agent seeking to make use of a reputation reporting 522 service is placing some trust that the service presents an unbiased 523 "opinion" of the object about which reputation is being returned. 524 The result of trusting the data is, presumably, to guide action taken 525 by the reputation client. It follows, then, that bias in the 526 reputation service can adversely affect the client. Clients 527 therefore need to be aware of this possibility and the effect it 528 might have. For example, a biased system returning a reputation 529 about a DNS domain found in email messages could result in the 530 admission of spam, phishing or malware through a mail gateway (by 531 rating the domain name more favourably than warranted) or could 532 result in the needless rejection or delay of mail (by rating the 533 domain more unfavourably than warranted). As a possible mitigation 534 strategy, clients might seek to interact only with reputation 535 services that offer some disclosure of the computation methods for 536 the results they return. Such disclosure and evaluation is beyond 537 the scope of the present document. 539 Similarly, a client placing trust in the results returned by such a 540 service might suffer if the service itself is compromised, returning 541 biased results under the control of an attacker without the knowledge 542 of the agency providing the reputation service. This might result 543 from an attack on the data being returned at the source, or from a 544 man-in-the-middle attack. Protocols, therefore, need to be designed 545 so as to be as resilient against such attacks as possible. 547 10.2. Malformed Messages 549 Both clients and servers of reputation systems need to be resistant 550 to attacks that involve malformed messages, deliberate or otherwise. 551 Malformations can be used to confound clients and servers alike in 552 terms of identifying the party or parties responsible for the content 553 under evaluation. This can result in delivery of undesirable or even 554 dangerous content. 556 10.3. Further Discussion 558 Involving a third party (in this case, a reputation service provider) 559 that can influence the handling of incoming content involves ceding 560 some amount of control to that third party. Numerous other topics 561 related to the management, operation, and safe use of reputation 562 systems can be found in [I-D.REPUTE-CONSIDERATIONS]. 564 11. Informative References 566 [DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 567 "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, 568 September 2011. 570 [DNS] Mockapetris, P., "Domain names - implementation and 571 specification", STD 13, RFC 1035, November 1987. 573 [DNSBL] Levine, J., "DNS Blacklists and Whitelists", RFC 5782, 574 February 2010. 576 [EMAIL-ARCH] 577 Crocker, D., "Internet Mail Architecture", RFC 5598, 578 July 2009. 580 [HTTP-TLS] 581 Rescorla, E., "HTTP over TLS", RFC 2818, May 2000. 583 [I-D.REPUTE-CONSIDERATIONS] 584 Kucherawy, M., "Operational Considerations Regarding 585 Reputation Services", draft-ietf-repute-considerations 586 (work in progress), November 2012. 588 [I-D.REPUTE-EMAIL-IDENTIFIERS] 589 Borenstein, N. and M. Kucherawy, "A Reputation Vocabulary 590 for Email Identifiers", 591 draft-ietf-repute-email-identifiers (work in progress), 592 November 2012. 594 [I-D.REPUTE-MEDIA-TYPE] 595 Borenstein, N. and M. Kucherawy, "A Media Type for 596 Reputation Interchange", draft-ietf-repute-media-type 597 (work in progress), November 2012. 599 [I-D.REPUTE-QUERY-HTTP] 600 Borenstein, N. and M. Kucherawy, "Reputation Data 601 Interchange using HTTP and XML", 602 draft-ietf-repute-query-http (work in progress), 603 November 2012. 605 [MAIL] Resnick, P., "Internet Message Format", RFC 5322, 606 October 2008. 608 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 609 Extensions (MIME) Part One: Format of Internet Message 610 Bodies", RFC 2045, November 1996. 612 [OPENPGP] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 613 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 615 [SMIME] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 616 Mail Extensions (S/MIME) Version 3.2: Message 617 Specification", RFC 5751, January 2010. 619 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 620 October 2008. 622 [VBR] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By 623 Reference", RFC 5518, April 2009. 625 Appendix A. Public Discussion 627 Public discussion of this suite of documents takes place on the 628 domainrep@ietf.org mailing list. See 629 https://www.ietf.org/mailman/listinfo/domainrep. 631 Authors' Addresses 633 Nathaniel Borenstein 634 Mimecast 635 203 Crescent St., Suite 303 636 Waltham, MA 02453 637 USA 639 Phone: +1 781 996 5340 640 Email: nsb@guppylake.com 642 Murray S. Kucherawy 643 270 Upland Drive 644 San Francisco, CA 94127 645 USA 647 Email: superuser@gmail.com 648 Andrew Sullivan (editor) 649 Dyn, Inc. 650 150 Dow St. 651 Manchester, NH 03101 652 USA 654 Email: asullivan@dyn.com