idnits 2.17.1 draft-ietf-opes-smtp-security-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 576. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 587. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 594. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 600. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 3, 2007) is 6264 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) ** Downref: Normative reference to an Informational RFC: RFC 3238 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 3914 (ref. '3') -- Obsolete informational reference (is this intentional?): RFC 2821 (ref. '4') (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 3852 (ref. '10') (Obsoleted by RFC 5652) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Open Pluggable Edge Services M. Stecher 3 Internet-Draft Secure Computing 4 Expires: August 7, 2007 February 3, 2007 6 Integrity, privacy and security in OPES for SMTP 7 draft-ietf-opes-smtp-security-03 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on August 7, 2007. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2007). 38 Abstract 40 The Open Pluggable Edge Services (OPES) framework is application 41 agnostic. Application specific adaptations extend that framework. 42 Previous work has focused on HTTP and work for SMTP is in progress. 43 These protocols differ fundamentally in the way data flows and it 44 turns out that existing OPES requirements and IAB considerations for 45 OPES need to be reviewed with regards to how well they fit for SMTP 46 adaptation. This document analyzes aspects about the integrity of 47 SMTP and mail message adaptation by OPES systems and privacy and 48 security issues when the OPES framework is adapted to SMTP and lists 49 requirements that must be considered when creating the "SMTP 50 adaptation with OPES" document. 52 The intent of this document is to capture this information before the 53 current OPES working group shuts down. This is to provide input for 54 subsequent working groups or individual contributors that may pick up 55 the OPES/SMTP work at a later date. 57 Table of Contents 59 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.1. Differences between unidirectional and bidirectional 62 application protocols . . . . . . . . . . . . . . . . . . 5 63 2.2. Non-standardized SMTP adaptations at SMTP gateways . . . . 5 64 2.3. Non-OPES issues of SMTP . . . . . . . . . . . . . . . . . 6 65 2.4. Opportunities of OPES/SMTP to address some issues . . . . 6 66 2.5. Limitations of OPES in regards to fixing SMTP issues . . . 6 67 3. Integrity, privacy and security considerations . . . . . . . . 8 68 3.1. Tracing info in OPES/SMTP . . . . . . . . . . . . . . . . 8 69 3.2. Bypass in OPES/SMTP . . . . . . . . . . . . . . . . . . . 8 70 3.3. Compatibility with Cryptographic Protection Mechanisms . . 9 71 4. Protocol requirements for OPES/SMTP . . . . . . . . . . . . . 12 72 5. IAB Considerations for OPES/SMTP . . . . . . . . . . . . . . . 13 73 5.1. IAB Consideration (2.1) One-Party Consent . . . . . . . . 13 74 5.2. IAB Consideration (2.2) IP-Layer Communications . . . . . 13 75 5.3. IAB Consideration (3.1) Notification . . . . . . . . . . . 13 76 5.4. IAB Consideration (3.2) Notification . . . . . . . . . . . 13 77 5.5. IAB Consideration (3.3) Non-Blocking . . . . . . . . . . . 14 78 5.6. IAB Consideration Application Layer Addresses (4.x) . . . 14 79 5.7. IAB Consideration (5.1) Privacy . . . . . . . . . . . . . 14 80 5.8. IAB Consideration Encryption . . . . . . . . . . . . . . . 15 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 85 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 86 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 20 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 88 Intellectual Property and Copyright Statements . . . . . . . . . . 22 90 1. Terminology 92 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [1]. When used with 95 the normative meanings, these keywords will be all uppercase. 96 Occurrences of these words in lowercase comprise normal prose usage, 97 with no normative implications. 99 2. Introduction 101 Because OPES is a protocol that is built over application layer 102 transports, its security may depend on the specifics of the 103 transport. OPES designs are guided by the IAB considerations for 104 OPES document [2], and those considerations are revisited here in the 105 context of the SMTP protocol. 107 Section 3 of the OPES SMTP use cases document [6] maps some email and 108 SMTP elements to OPES names that are used in this document. 110 2.1. Differences between unidirectional and bidirectional application 111 protocols 113 The IAB listed considerations for Open Pluggable Edge Services (OPES) 114 in [2] and OPES treatment of those considerations has been discussed 115 in [3]. Both documents make use of HTTP as an example for the 116 underlying protocol in OPES flows, and focus on web protocols that 117 have requests and responses in the classic form (client sends a 118 request to a server that replies with a response of the same protocol 119 within a single protocol transaction). 121 RFC 3914 [3] already indicates that other protocols may not fit in 122 this context, for example in section 5.3: "Moreover, some application 123 protocols may not have explicit responses...". 125 When using SMTP there are still client and server applications, and 126 requests and responses handled within SMTP, but email messages are 127 sent by the data provider to the recipients (data consumers) without 128 a previous request. At that abstraction layer, email delivery via 129 SMTP is a unidirectional process and different from the previously 130 handled web protocols such as HTTP. For example: bypass has been 131 defined for OPES so far by the data consumer requesting an OPES 132 bypass by adding information to the application protocol request; the 133 OPES system can then react on the bypass request in both the 134 application request and response. For SMTP, the data consumer (email 135 recipient) cannot request in-band that the OPES bypass handling of 136 his/her messages. 138 The IAB considerations need to be revisited and special requirements 139 may be needed for OPES handling of SMTP. 141 2.2. Non-standardized SMTP adaptations at SMTP gateways 143 A large number of email filters are deployed at SMTP gateways today; 144 in fact all use cases listed in "OPES SMTP Use Cases" [6] are already 145 deployed, often in non standardized ways. This opens a number of 146 integrity, privacy and security concerns that are not addressed, and 147 SMTP itself does not provide effective measures to detect and defend 148 against compromised implementations. 150 OPES will most likely not be able to solve these issues completely, 151 but at least should be able to improve the situation to some extent. 153 2.3. Non-OPES issues of SMTP 155 The SMTP specifications [4] require that NDRs (Non Delivery Reports) 156 be sent to the originator of an undeliverable mail that has been 157 accepted by an SMTP server. But it has become common practice for 158 some sorts of mail (spam, worms) to be silently dropped without 159 sending an NDR, a violation of the MUST statement of SMTP (see 160 section 3.7 of [4]). While the user of a web protocol notices if a 161 resource cannot be fetched, neither the email sender nor email 162 recipient may notice that an email was not delivered. These kind of 163 issues already exist and are not introduced by OPES. 165 2.4. Opportunities of OPES/SMTP to address some issues 167 Adding SMTP adaptations with OPES allows us to define a standardized 168 way for SMTP gateway filtering, to offload filtering services to 169 callout servers and address a number of the integrity, privacy and 170 security issues. OPES offers methods to add OPES tracing information 171 and to request bypass of filtering, and by that can make email 172 gateway filtering a more reliable and standardized function. But 173 OPES won't make email delivery via SMTP a reliable communication. 175 2.5. Limitations of OPES in regards to fixing SMTP issues 177 The biggest concerns when adding OPES services to a network flow are 178 that compromised, misconfigured or faulty OPES systems may change 179 messages in a way that the consumer can no longer read them or that 180 messages are no longer delivered at all. 182 Defining a standard way to mark mails that have been handled by OPES 183 systems is fairly simple and does not require new techniques by SMTP 184 gateways; they already today MUST leave tracing information by adding 185 "Received" headers to mails. Therefore, recipients receiving broken 186 mail have a fair chance of finding the compromised OPES system by 187 using the trace information. There is still no guarantee, as the 188 email may have been broken in a way that makes even the tracing 189 information unreadable. But the chance will be even better than with 190 other protocols such as HTTP, because most email clients allow the 191 user to display mail headers, while many browsers have no mechanism 192 to show the HTTP headers that might include tracing info. 194 Email that cannot be delivered, because a compromised OPES system 195 prevented the delivery of legitimate mail, MUST result in a an NDR to 196 be sent to the originator of the mail according to the SMTP 197 specifications [4]. OPES should not be forced to fix the issue that 198 NDRs are not reliable over SMTP. 200 3. Integrity, privacy and security considerations 202 3.1. Tracing info in OPES/SMTP 204 Tracing OPES operations is an important requirement for OPES systems. 205 Tracing information added to email should follow a similar syntax and 206 structure to that defined for OPES/HTTP in HTTP Adaptation with Open 207 Pluggable Edge Services [5], and with the same guidelines as the SMTP 208 specifications [4] define for the "Received" headers. (We do not 209 speficy here whether "Received" headers would be used to carry the 210 OPES information, or new trace headers should be defined, such as 211 OPES-System and OPES-Via.) 213 OPES/SMTP specifications defining tracing requirements MUST be 214 compliant with the general OPES tracing requirements defined in OPES 215 Entities & End Points Communication [12], but MAY further restrict 216 those. For example, they might require: that the OPES processor must 217 add tracing information for the OPES system before calling the first 218 callout server; that it has to augment the tracing information with 219 additional data if necessary after the message returns from each 220 service it is calling; and that it must ensure that the tracing 221 information has not been deleted by an OPES service before it 222 forwards the SMTP message. 224 Trace information can then be seen by mail recipients when the mail 225 message reaches the recipient. 227 Mail that cannot be delivered or that is blocked by the OPES service 228 will either be rejected or cannot be delivered after it has been 229 accepted by an SMTP server. In the latter case SMTP specifications 230 [4] require that a NDR MUST be sent to the originator; OPES further 231 requires that a NDR generated due to OPES processing MUST also 232 contain information about the OPES system so that the sender gets 233 informed. If an email is rejected at the SMTP protocol level due to 234 OPES processing, an OPES system MUST also include trace data in the 235 SMTP response so that the originator can find out why and where the 236 mail was rejected. 238 3.2. Bypass in OPES/SMTP 240 If a mail message was rejected or could not be delivered (and a NDR 241 was sent), the originator of the message may want to bypass the OPES 242 system that blocked the message. 244 If the recipient of a message receives a mail with OPES trace 245 information, he may want to receive a non-OPES version of the 246 message. Although there is no direct in-band request from the 247 recipient back to the OPES system, the recipient can contact the 248 sender and ask her to send the message again and to add a bypass 249 request for the OPES system. Not all OPES systems will be allowed to 250 fulfill a bypass request according to their policy. For example, 251 malware scanners should not be bypassed. But other OPES services are 252 good candidates for bypass requests, such as language translation of 253 the email message. Translation could be bypassed after the recipient 254 has noticed that the translated result does not meet his/her 255 expectations and that the original message would be preferred. 257 An OPES system MAY also define out-of-band methods to request a 258 bypass, for example a web interface or an email message sent to the 259 server that results in the creation of a white list entry for the 260 sender/recipient pair. Examples for these out-of-band methods are 261 email systems that keep a copy of the original email in a quarantine 262 queue and only send the recipient a block notification plus either a 263 direct link or a digest notification, with the ability to retrieve 264 the original message from quarantine. These out-of-band methods are 265 typically offered by spam filters today. 267 OPES MUST implement methods to request a bypass but there cannot be a 268 guarantee that the bypass request will be approved. The security 269 needs of the receiver or the receiver's network may demand that 270 certain filters must not be bypassed (such as virus scanners). In 271 general, the receiver should be able to configure a client centric 272 OPES system, i.e. the receiver should be able to indicate if he/she 273 wants to receive a non-OPES version if it is available. 275 Bypass requests could be added to the mail message or within the SMTP 276 dialog. Bypass request data added to the mail message cannot bypass 277 OPES services that operate on other SMTP dialog commands, which are 278 sent before the mail message has been received (such as RCPT 279 commands). 281 Bypass request data sent using an ESMTP extension as part of the SMTP 282 dialog may not reach the OPES system if intermediate SMTP relays do 283 not support those bypass request commands and don't forward that 284 information. 286 3.3. Compatibility with Cryptographic Protection Mechanisms 288 Cryptography can be used to assure message privacy, to authenticate 289 the originator of messages, and to detect message modification. 290 There are standard methods for achieving some or all these 291 protections for generic messages ([9], [10], [11]), and these can be 292 used to protect SMTP data without changing the SMTP protocol. 294 The content of encrypted mail messages cannot be inspected by OPES 295 systems because only the intended recipient has the information 296 necessary for decryption. The IAB and others have suggested that 297 users might want to share that information with OPES systems, thus 298 permitting decryption by intermediates. For most cryptographic 299 systems that are compatible with email, this would require end users 300 to share their most valuable keys, in essence their "identities", 301 with OPES machines. Some key management systems, particularly those 302 which have centralized administrative control of keys, might have 303 trust models in which such sharing would be sensible and secure. 305 After decrypting the message, an OPES box that modified the content 306 would be faced with the task of re-encrypting it in order to maintain 307 some semblance of "end-to-end" privacy. 309 If OPES/SMTP had a way to interact with end users on a per message 310 basis, it might be possible to communicate cryptographic key 311 information from individual messages to end users, have them compute 312 the message encrypting key for particular message, and to send that 313 back to the OPES box. This would perhaps ameliorate the need to 314 share a user's "master" message decrypting key with the OPES box. 315 This kind of communication has not been defined for OPES. 317 Message protection systems generally include some message integrity 318 mechanisms by which recipient can check for message modification that 319 may have occurred after the sender released the message. This 320 protection can be applied to encrypted or plaintext messages and can 321 be accomplished through either symmetric or asymmetric cryptography. 322 In the case of symmetric cryptography, the key sharing problem is 323 exactly similar to the encryption case discussed previously. If the 324 OPES box modified the content, then the message integrity (or 325 authentication) code would have to be re-calculated and included with 326 the modified message. 328 For asymmetric cryptography the situation is more complicated. The 329 message integrity is tied to the sender's public key, and although 330 anyone who can get the sender's public key can also check for message 331 modification, no one but the sender can compute the sender's 332 signature on a modified message. Thus, an OPES system could not 333 modify messages and have them appear to come from the purported 334 sender. The notion of sharing the sender's signing key with the OPES 335 system is unpalatable, because few trust models would be compatible 336 with sharing digital identities across organization boundaries. 337 However, if the OPES system doing the modification were under the 338 control of the sender's local administration, the sharing might be 339 sensible (as discussed for decryption, above). 341 OPES/SMTP systems could present modified content showing the modified 342 regions in a form that permits authentication of the original message 343 and authentication of the OPES modifications (assuming the OPES box 344 had a digital signature identity and key). One method for doing this 345 is outlined in [13], but to our knowledge this method is not in any 346 standard. 348 There are security risks associated with sharing cryptographic keys 349 that must be addressed by implementers. Because this is not a simple 350 task, it is not a requirement for OPES/SMTP. 352 4. Protocol requirements for OPES/SMTP 354 In addition to other documents listing requirements for OPES, the 355 discussion in this document implies specific requirements for 356 designing and implementing SMTP adaptations with OPES: 358 o OPES Systems MUST add tracing headers to mail messages 360 o If an email message that has been accepted by an OPES system 361 cannot be delivered, the non delivery report MUST include trace 362 information of the OPES system. 364 o The OPES/SMTP specifications MUST define a bypass request option 365 that can be included in mail messages. 367 o The OPES/SMTP specifications MUST define a bypass request option 368 as an extension for SMTP dialogs. 370 5. IAB Considerations for OPES/SMTP 372 This section lists the IAB considerations for OPES [2] and summarizes 373 how OPES/SMTP addresses them. 375 5.1. IAB Consideration (2.1) One-Party Consent 377 The IAB recommends that all OPES services be explicitly authorized by 378 one of the application-layer end-hosts (that is, either the data 379 consumer application or the data provider application). For OPES/ 380 SMTP this means consent of either the email message sender or the 381 recipient. 383 The application agnostic architecture of OPES [7] requires that "OPES 384 processors MUST be consented to by either the data consumer or data 385 provider application" (OPES processor is the email gateway for OPES/ 386 SMTP). This cannot prevent the consent-less introduction of OPES 387 processors by noncompliant OPES entities. 389 5.2. IAB Consideration (2.2) IP-Layer Communications 391 The IAB recommends that OPES processors must be explicitly addressed 392 at the IP layer by the end user (data consumer application). 394 This requirement has been addressed by the architecture requirements 395 in section 2.1 of [7] and has been further clarified in section 2.2 396 of [3]. 398 5.3. IAB Consideration (3.1) Notification 400 "The overall OPES framework needs to assist content providers in 401 detecting and responding to client-centric actions by OPES 402 intermediaries that are deemed inappropriate by the content provider" 403 [2]. 405 For OPES/SMTP this translates into assistance for the email message 406 sender to detect and respond to recipient-centric actions that are 407 deemed inappropriate by the sender. 409 This has been addressed in Section 3.1 and by the second tracing 410 requirements in Section 4. As discussed in Section 2.3 OPES/SMTP 411 cannot fix cases where NDRs are not sent or get blocked before 412 reaching the sender of the original message. 414 5.4. IAB Consideration (3.2) Notification 416 "The overall OPES framework should assist end users in detecting the 417 behavior of OPES intermediaries, potentially allowing them to 418 identify imperfect or compromised intermediaries" [2]. 420 This is addressed in Section 3.1 and by the first tracing requirement 421 in Section 4. It must be noted that some email systems do not make 422 the email headers available to the end user although the headers 423 belong to the payload that is transferred via SMTP. Building an OPES 424 architecture with those email systems should be avoided or requires 425 that the tracing information be made available to the end users in a 426 different way. 428 5.5. IAB Consideration (3.3) Non-Blocking 430 "If there exists a "non-OPES" version of content available from the 431 content provider, the OPES architecture must not prevent users from 432 retrieving this "non-OPES" version from the content provider" [2]. 434 For OPES/SMTP this has been discussed in Section 3.2 and is addressed 435 by the two bypass requirements of Section 4. 437 5.6. IAB Consideration Application Layer Addresses (4.x) 439 While "most application layer addressing revolves around URIs" 440 (section 8 of [2]), SMTP uses email addresses, for which the 441 considerations only apply to some degree. 443 The SMTP use cases document [6] includes a use case for Mail 444 Rerouting and Address Rewriting. Alias and email list address 445 resolution are standard functions of an email gateway described in 446 [4]. 448 Translating the reference validity consideration regarding inter- and 449 intra-document reference validity to SMTP, OPES services mapping 450 internal to external email addresses MUST ensure the proper mapping 451 of addresses in all affected email headers. 453 5.7. IAB Consideration (5.1) Privacy 455 This consideration recommends that the overall OPES framework must 456 provide for mechanisms for end users to determine the privacy 457 policies that were used by OPES intermediaries. 459 The application agnostic part for OPES has been discussed in section 460 10 of [3]. Email specific trace information that will be added to 461 OPES/SMTP according to the requirements in Section 4 may raise 462 additional privacy issues that MUST be added to the privacy policy 463 description of the OPES system. 465 5.8. IAB Consideration Encryption 467 "If OPES was compatible with end-to-end encryption, this would 468 effectively ensure that OPES boxes would be restricted to ones that 469 are known, trusted, explicitly addressed at the IP layer, and 470 authorized (by the provision of decryption keys) by at least one of 471 the ends" [2]. 473 This has been discussed in Section 3.3. 475 6. Security Considerations 477 The document itself discusses security considerations of OPES/SMTP. 478 General security threats of OPES are described in Security Threats 479 for OPES [8] 481 Section 3.3 (about compatibility with cryptographic protection 482 mechanisms) mentions that an OPES system could eventually deal with 483 cryptographic keys. This raises security issues (such as 484 availability and storage of cryptographic keys) that must be 485 addressed by the implementer. 487 7. IANA Considerations 489 There are no IANA Considerations. 491 RFC Editor: this section may be removed upon publication. 493 8. References 495 8.1. Normative References 497 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 498 Levels", BCP 14, RFC 2119, March 1997. 500 [2] Floyd, S. and L. Daigle, "IAB Architectural and Policy 501 Considerations for Open Pluggable Edge Services", RFC 3238, 502 January 2002. 504 [3] Barbir, A. and A. Rousskov, "Open Pluggable Edge Services 505 (OPES) Treatment of IAB Considerations", RFC 3914, 506 October 2004. 508 8.2. Informative References 510 [4] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 511 April 2001. 513 [5] Rousskov, A. and M. Stecher, "HTTP Adaptation with Open 514 Pluggable Edge Services (OPES)", RFC 4236, November 2005. 516 [6] Stecher, M. and A. Barbir, "Open Pluggable Edge Services (OPES) 517 SMTP Use Cases", RFC 4496, May 2006. 519 [7] Barbir, A., Penno, R., Chen, R., Hofmann, M., and H. Orman, "An 520 Architecture for Open Pluggable Edge Services (OPES)", 521 RFC 3835, August 2004. 523 [8] Barbir, A., Batuner, O., Srinivas, B., Hofmann, M., and H. 524 Orman, "Security Threats and Risks for Open Pluggable Edge 525 Services (OPES)", RFC 3837, August 2004. 527 [9] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME 528 Security with OpenPGP", RFC 3156, August 2001. 530 [10] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, 531 July 2004. 533 [11] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup 534 Language) XML-Signature Syntax and Processing", RFC 3275, 535 March 2002. 537 [12] Barbir, A., "Open Pluggable Edge Services (OPES) Entities and 538 End Points Communication", RFC 3897, September 2004. 540 [13] Orman, H., "Data Integrity for Mildly Active Content", 541 Proceedings of the Third Annual International Workshop on 542 Active Middleware Services p.73, August 2001. 544 Appendix A. Acknowledgements 546 Many thanks to everybody who provided input and feedback for this 547 document. Very special thanks to Hilarie Orman for her input and 548 suggestions, especially for the content of Section 3.3 (about 549 compatibility with cryptographic protection mechanisms). 551 Author's Address 553 Martin Stecher 554 Secure Computing Corporation 555 Vattmannstr. 3 556 33100 Paderborn 557 Germany 559 Email: martin.stecher@webwasher.com 560 URI: http://www.securecomputing.com/ 562 Full Copyright Statement 564 Copyright (C) The IETF Trust (2007). 566 This document is subject to the rights, licenses and restrictions 567 contained in BCP 78, and except as set forth therein, the authors 568 retain all their rights. 570 This document and the information contained herein are provided on an 571 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 572 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 573 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 574 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 575 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 576 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 578 Intellectual Property 580 The IETF takes no position regarding the validity or scope of any 581 Intellectual Property Rights or other rights that might be claimed to 582 pertain to the implementation or use of the technology described in 583 this document or the extent to which any license under such rights 584 might or might not be available; nor does it represent that it has 585 made any independent effort to identify any such rights. Information 586 on the procedures with respect to rights in RFC documents can be 587 found in BCP 78 and BCP 79. 589 Copies of IPR disclosures made to the IETF Secretariat and any 590 assurances of licenses to be made available, or the result of an 591 attempt made to obtain a general license or permission for the use of 592 such proprietary rights by implementers or users of this 593 specification can be obtained from the IETF on-line IPR repository at 594 http://www.ietf.org/ipr. 596 The IETF invites any interested party to bring to its attention any 597 copyrights, patents or patent applications, or other proprietary 598 rights that may cover technology that may be required to implement 599 this standard. Please address the information to the IETF at 600 ietf-ipr@ietf.org. 602 Acknowledgment 604 Funding for the RFC Editor function is provided by the IETF 605 Administrative Support Activity (IASA).