idnits 2.17.1 draft-ietf-xmpp-e2e-09.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 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1238. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1215. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1222. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1228. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1244), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 27 longer pages, the longest (page 25) being 72 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 28 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (July 12, 2004) is 7228 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) == Unused Reference: 'X509' is defined on line 1020, but no explicit reference was found in the text == Unused Reference: 'XMPP-CPIM' is defined on line 1064, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2778 (ref. 'IMP-MODEL') ** Downref: Normative reference to an Informational RFC: RFC 2779 (ref. 'IMP-REQS') ** Obsolete normative reference: RFC 3280 (ref. 'X509') (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3023 (ref. 'XML-MEDIA') (Obsoleted by RFC 7303) -- Obsolete informational reference (is this intentional?): RFC 2797 (ref. 'CMC') (Obsoleted by RFC 5272) -- Obsolete informational reference (is this intentional?): RFC 2510 (ref. 'CMP') (Obsoleted by RFC 4210) Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 XMPP Working Group P. Saint-Andre 2 Internet-Draft Jabber Software Foundation 3 Expires: January 10, 2005 July 12, 2004 5 End-to-End Signing and Object Encryption in the Extensible Messaging 6 and Presence Protocol (XMPP) 7 draft-ietf-xmpp-e2e-09 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668. 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 19 Internet-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 January 10, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 This memo defines a method for end-to-end signing and object 41 encryption in the Extensible Messaging and Presence Protocol (XMPP). 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 47 3. Securing Messages . . . . . . . . . . . . . . . . . . . . . 5 48 4. Securing Presence . . . . . . . . . . . . . . . . . . . . . 9 49 5. Securing Arbitrary XMPP Data . . . . . . . . . . . . . . . . 13 50 6. Rules for S/MIME Generation and Handling . . . . . . . . . . 15 51 7. Recipient Error Handling . . . . . . . . . . . . . . . . . . 18 52 8. Secure Communications Through a Gateway . . . . . . . . . . 20 53 9. urn:ietf:params:xml:xmpp-e2e Namespace . . . . . . . . . . . 20 54 10. application/xmpp+xml Media Type . . . . . . . . . . . . . . 21 55 11. Security Considerations . . . . . . . . . . . . . . . . . . 21 56 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21 57 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 58 13.1 Normative References . . . . . . . . . . . . . . . . . . . 22 59 13.2 Informative References . . . . . . . . . . . . . . . . . . 24 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . 25 61 A. Schema for urn:ietf:params:xml:ns:xmpp-e2e . . . . . . . . . 25 62 B. Revision History . . . . . . . . . . . . . . . . . . . . . . 25 63 Intellectual Property and Copyright Statements . . . . . . . 28 65 1. Introduction 67 This memo define a method for end-to-end signing and object 68 encryption in the Extensible Messaging and Presence Protocol (XMPP). 69 (For information about XMPP, see [XMPP-CORE] and [XMPP-IM].) The 70 method specified herein enables a sender to sign and/or encrypt an 71 instant message sent to a specific recipient, sign and/or encrypt 72 presence information that is directed to a specific user, and sign 73 and/or encrypt any arbitrary XMPP stanza directed to a specific user. 74 This memo thereby helps the XMPP specifications meet the requirements 75 specified in [IMP-REQS]. 77 1.1 Terminology 79 This document inherits terminology defined in [CMS], [IMP-MODEL], 80 [SMIME], and [XMPP-CORE]. 82 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 83 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 84 "OPTIONAL" in this document are to be interpreted as described in 85 [TERMS]. 87 2. Requirements 89 For the purposes of this memo, we stipulate the following 90 requirements: 92 1. The method defined MUST address signing and encryption 93 requirements for minimal instant messaging and presence, as those 94 are defined in [IMP-REQS]. In particular, the method MUST 95 address the following requirements, which are copied here 96 verbatim from [IMP-REQS]: 97 * The protocol MUST provide means to ensure confidence that a 98 received message (NOTIFICATION or INSTANT MESSAGE) has not 99 been corrupted or tampered with. (Section 2.5.1) 100 * The protocol MUST provide means to ensure confidence that a 101 received message (NOTIFICATION or INSTANT MESSAGE) has not 102 been recorded and played back by an adversary. (Section 103 2.5.2) 104 * The protocol MUST provide means to ensure that a sent message 105 (NOTIFICATION or INSTANT MESSAGE) is only readable by ENTITIES 106 that the sender allows. (Section 2.5.3) 107 * The protocol MUST allow any client to use the means to ensure 108 non-corruption, non-playback, and privacy, but the protocol 109 MUST NOT require that all clients use these means at all 110 times. (Section 2.5.4) 111 * When A establishes a SUBSCRIPTION to B's PRESENCE INFORMATION, 112 the protocol MUST provide A means of verifying the accurate 113 receipt of the content B chooses to disclose to A. (Section 114 5.1.4) 115 * The protocol MUST provide A means of verifying that the 116 presence information is accurate, as sent by B. (Section 117 5.3.1) 118 * The protocol MUST provide A means of ensuring that no other 119 PRINCIPAL C can see the content of M. (Section 5.4.6) 120 * The protocol MUST provide A means of ensuring that no other 121 PRINCIPAL C can tamper with M, and B means to verify that no 122 tampering has occurred. (Section 5.4.7) 123 2. The method defined MUST enable interoperability with non-XMPP 124 messaging systems that support the Common Presence and Instant 125 Messaging (CPIM) specifications published by the Instant 126 Messaging and Presence (IMPP) Working Group. Two corollaries of 127 this requirement are: 128 * Prior to signing and/or encrypting, the format of an instant 129 message MUST conform to the CPIM Message Format defined in 130 [MSGFMT]. 131 * Prior to signing and/or encrypting, the format of presence 132 information MUST conform to the CPP Presence Information Data 133 Format defined in [PIDF]. 134 3. The method MUST follow the required procedures (including the 135 specific algorithms) defined in [CPIM] and [CPP]. In particular, 136 these documents specify: 137 * Signing MUST use [SMIME] signatures with [CMS] SignedData. 138 * Encryption MUST use [SMIME] encryption with [CMS] 139 EnvelopeData. 140 4. In order to enable interoperable implementations, sending and 141 receiving applications MUST implement the algorithms specified 142 under Mandatory-to-Implement Cryptographic Algorithms (Section 143 6.10). 145 We further stipulate that the following functionality is out of scope 146 for this memo: 148 o Discovery of support for this protocol. An entity could discover 149 whether another entity supports this protocol by (1) attempting to 150 send signed or encrypted stanzas and receiving an error stanza 151 ("technical" discovery) or a textual message in reply ("social" 152 discovery) if the protocol is not supported, or (2) using a 153 dedicated service discovery protocol, such as [DISCO] or [CAPS]. 154 However, the definition of a service discovery protocol is out of 155 scope for this memo. 156 o Signing or encryption of XMPP groupchat messages, which are 157 mentioned in [XMPP-IM] but not defined therein since they are not 158 required by [IMP-REQS]; such messages are best specified in [MUC]. 159 o Signing or encryption of broadcasted presence as described in 160 [XMPP-IM] (the methods defined herein apply to directed presence 161 only). 162 o Signing or encryption of communications that occur within the 163 context of applications other than instant messaging and presence 164 as those are described in [IMP-MODEL] and [IMP-REQS]. 166 3. Securing Messages 168 3.1 Process for Securing Messages 170 In order to sign and/or encrypt a message, a sending agent MUST use 171 the following procedure: 173 1. Generate a "Message/CPIM" object as defined in [MSGFMT]. 174 2. Sign and/or encrypt both the headers and content of the "Message/ 175 CPIM" object as specified in Requirement 3 of Section 2 above. 176 3. Provide the resulting signed and/or encrypted object within an 177 XML CDATA section (see Section 2.7 of [XML]) contained in an 178 child of a stanza, where the element is 179 qualified by the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace as 180 specified more fully in Section 9 below. 182 3.2 Example of a Signed Message 184 The following example illustrates the defined steps for signing a 185 message. 187 First, the sending agent generates a "Message/CPIM" object in 188 accordance with the rules and formats specified in [MSGFMT]. 190 Example 1: Sender generates "Message/CPIM" object: 192 | Content-type: Message/CPIM 193 | 194 | From: Juliet Capulet 195 | To: Romeo Montague 196 | DateTime: 2003-12-09T11:45:36.66Z 197 | Subject: Imploring 198 | 199 | Content-type: text/plain; charset=utf-8 200 | Content-ID: <1234567890@example.com> 201 | 202 | Wherefore art thou, Romeo? 204 Once the sending agent has generated the "Message/CPIM" object, the 205 sending agent may sign it. The result is a multipart [SMIME] object 206 (see [MULTI]) that has a Content-Type of "multipart/signed" and 207 includes two parts: one whose Content-Type is "Message/CPIM" and 208 another whose Content-Type is "application/pkcs7-signature". 210 Example 2: Sender generates multipart/signed object: 212 | Content-Type: multipart/signed; boundary=next; 213 | micalg=sha1; 214 | protocol=application/pkcs7-signature 215 | 216 | --next 217 | Content-type: Message/CPIM 218 | 219 | From: Juliet Capulet 220 | To: Romeo Montague 221 | DateTime: 2003-12-09T23:45:36.66Z 222 | Subject: Imploring 223 | 224 | Content-type: text/plain; charset=utf-8 225 | Content-ID: <1234567890@example.com> 226 | 227 | Wherefore art thou, Romeo? 228 | --next 229 | Content-Type: application/pkcs7-signature 230 | Content-Disposition: attachment;handling=required;\ 231 | filename=smime.p7s 232 | 233 | [signed body part] 234 | 235 | --next-- 237 The sending agent now wraps the "mulipart/signed" object in an XML 238 CDATA section, which is contained in an element that is 239 included as a child element of the XMPP message stanza and that is 240 qualified by the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace. 242 Example 3: Sender generates XMPP message stanza: 244 | 245 | 246 | 255 | To: Romeo Montague 256 | DateTime: 2003-12-09T23:45:36.66Z 257 | Subject: Imploring 258 | 259 | Content-type: text/plain; charset=utf-8 260 | Content-ID: <1234567890@example.com> 261 | 262 | Wherefore art thou, Romeo? 263 | --next 264 | Content-Type: application/pkcs7-signature 265 | Content-Disposition: attachment;handling=required;\ 266 | filename=smime.p7s 267 | 268 | [signed body part] 269 | 270 | --next-- 271 | ]]> 272 | 273 | 275 3.3 Example of an Encrypted Message 277 The following example illustrates the defined steps for encrypting a 278 message. 280 First, the sending agent generates a "Message/CPIM" object in 281 accordance with the rules and formats specified in [MSGFMT]. 283 Example 4: Sender generates "Message/CPIM" object: 285 | Content-type: Message/CPIM 286 | 287 | From: Juliet Capulet 288 | To: Romeo Montague 289 | DateTime: 2003-12-09T11:45:36.66Z 290 | Subject: Imploring 291 | 292 | Content-type: text/plain; charset=utf-8 293 | Content-ID: <1234567890@example.com> 294 | 295 | Wherefore art thou, Romeo? 297 Once the sending agent has generated the "Message/CPIM" object, the 298 sending agent may encrypt it. 300 Example 5: Sender generates encrypted object: 302 | U2FsdGVkX19okeKTlLxa/1n1FE/upwn1D20GhPWqhDWlexKMUKYJInTWzERP+vcQ 303 | /OxFs40uc9Fx81a5/62p/yPb/UWnuG6SR6o3Ed2zwcusDImyyz125HFERdDUMBC9 304 | Pt6Z4cTGKBmJzZBGyuc3Y+TMBTxqFFUAxeWaoxnZrrl+LP72vwbriYc3KCMxDbQL 305 | Igc1Vzs5/5JecegMieNY24SlNyX9HMFRNFpbI64vLxYEk55A+3IYbZsluCFT31+a 306 | +GeAvJkvH64LRV4mPbUhENTQ2wbAwnOTvbLIaQEQrii78xNEh+MK8Bx7TBTvi4yH 307 | Ddzf9Sim6mtWsXaCAvWSyp0X91d7xRJ4JIgKfPzkxNsWJFCLthQS1p734eDxXVd3 308 | i08lEHzyll6htuEr59ZDAw== 310 The sending agent now wraps the encrypted object in an XML CDATA 311 section, which is contained in an element that is included as 312 a child element of the XMPP message stanza and that is qualified by 313 the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace. 315 Example 6: Sender generates XMPP message stanza: 317 | 318 | 319 | 328 | 329 | 331 4. Securing Presence 333 4.1 Process for Securing Presence Information 335 In order to sign and/or encrypt presence information, a sending agent 336 MUST use the following procedure: 338 1. Generate an "application/pidf+xml" object as defined in [PIDF]. 339 2. Sign and/or encrypt the "application/pidf+xml" object as 340 specified in Requirement 3 of Section 2 above. 341 3. Provide the resulting signed and/or encrypted object within an 342 XML CDATA section (see Section 2.7 of [XML]) contained in an 343 child of a stanza, where the element is 344 qualified by the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace. 345 The stanza MUST include a 'to' attribute, i.e., it 346 must be an instance of directed presence as defined in [XMPP-IM]. 348 4.2 Example of Signed Presence Information 350 The following example illustrates the defined steps for signing 351 presence information. 353 First, the sending agent generates an "application/pidf+xml" object 354 in accordance with the rules and formats specified in [PIDF]. 356 Example 7: Sender generates "application/pidf+xml" object: 358 | 359 | 362 | 364 | open 365 | away 366 | 367 | retired to the chamber 368 | 2003-12-09T23:53:11.31 369 | 370 | 372 Once the sending agent has generated the "application/pidf+xml" 373 object, the sending agent may sign it. The result is a multipart 374 [SMIME] object (see [MULTI]) that has a Content-Type of "multipart/ 375 signed" and includes two parts: one whose Content-Type is 376 "application/pidf+xml" and another whose Content-Type is 377 "application/pkcs7-signature". 379 Example 8: Sender generates multipart/signed object: 381 | Content-Type: multipart/signed; boundary=next; 382 | micalg=sha1; 383 | protocol=application/pkcs7-signature 384 | 385 | --next 386 | Content-type: application/pidf+xml 387 | Content-ID: <2345678901@example.com> 388 | 389 | 390 | 393 | 394 | open 396 | away 397 | 398 | retired to the chamber 399 | 2003-12-09T23:53:11.31Z 400 | 401 | 402 | --next 403 | Content-Type: application/pkcs7-signature 404 | Content-Disposition: attachment;handling=required;\ 405 | filename=smime.p7s 406 | 407 | [signed body part] 408 | 409 | --next-- 411 The sending agent now wraps the "mulipart/signed" object in an XML 412 CDATA section, which is contained in an element that is 413 included as a child element of the XMPP message stanza and that is 414 qualified by the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace. 416 Example 9: Sender generates XMPP presence stanza: 418 | 419 | 420 | 428 | 429 | 430 | 433 | 434 | 435 | open 436 | away 437 | 438 | retired to the chamber 439 | 2003-12-09T23:53:11.31Z 440 | 441 | 442 | --next 443 | Content-Type: application/pkcs7-signature 444 | Content-Disposition: attachment;handling=required;\ 445 | filename=smime.p7s 446 | 447 | [signed body part] 448 | 449 | --next-- 450 | ]]> 451 | 452 | 454 4.3 Example of Encrypted Presence Information 456 The following example illustrates the defined steps for encrypting 457 presence information. 459 First, the sending agent generates an "application/pidf+xml" object 460 in accordance with the rules and formats specified in [PIDF]. 462 Example 10: Sender generates "application/pidf+xml" object: 464 | 465 | 468 | 470 | open 471 | away 472 | 473 | retired to the chamber 474 | 2003-12-09T23:53:11.31 475 | 476 | 478 Once the sending agent has generated the "application/pidf+xml" 479 object, the sending agent may encrypt it. 481 Example 11: Sender generates encrypted object: 483 | U2FsdGVkX18VJPbx5GMdFPTPZrHLC9QGiVP+ziczu6zWZLFQxae6O5PP6iqpr2No 484 | zOvBVMWvYeRAT0zd18hr6qsqKiGl/GZpAAbTvPtaBxeIykxsd1+CX+U+iw0nEGCr 485 | bjiQrk0qUKJ79bNxwRnqdidjhyTpKSbOJC0XZ8CTe7AE9KDM3Q+uk+O3jrqX4byL 486 | GBlKThbzKidxz32ObojPEEwfFiM/yUeqYUP1OcJpUmeQ8lcXhD6tcx+m2MAyYYLP 487 | boKQxpLknxRnbM8T/voedlnFLbbDu69mOlxDPbr1mHZd3hDsyFudb1fb4rI3Kw0K 488 | Nq+3udr2IkysviJDgQo+xGIQUG/5sED/mAaPRlj4f/JtTzvT4EaQTawv69ntXfKV 489 | MCr9KdIMMdjdJzOJkYLoAhNVrcZn5tw8WsJGwuKuhYb/SShy7InzOapPaPAl7/Mm 490 | PHj7zj3NZ6EEIweDOuAwWlIG/dT506tci27+EW7JnXwMPnFMkF+6a7tr/0Y+iiej 491 | woJxUIBqCOgX+U7srHpK2NYtNTZ7UQp2V0yEx1JV8+Y= 493 The sending agent now wraps the encrypted object in an XML CDATA 494 section, which is contained in an element that is included as 495 a child element of the XMPP message stanza and that is qualified by 496 the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace. 498 Example 12: Sender generates XMPP presence stanza: 500 | 501 | 502 | 513 | 514 | 516 5. Securing Arbitrary XMPP Data 518 The foregoing sections of this memo describe how to secure "least 519 common denominator" messaging and presence data of the kind that can 520 be directly translated into the MSGFMT or PIDF formats. However, 521 XMPP possesses a third base-level stanza type () in addition to 522 and , as well as the ability to include 523 extended XML data within arbitrary child elements of the three core 524 stanza types. Therefore it would be desirable to secure such data if 525 possible. 527 Because [MSGFMT] specifies the ability to encapsulate any MIME type, 528 the approach taken in this memo is to include arbitrary XMPP data in 529 an XML media type named "application/xmpp+xml" as specified more 530 fully in Section 10 below. 532 The following examples illustrate the structure of the "application/ 533 xmpp+xml" MIME type. (Note: The 'http://jabber.org/protocol/evil' 534 namespace used in these examples is associated with an April Fool's 535 protocol written to be the instant messaging equivalent of RFC 3514; 536 it is included only as an instance of extended information included 537 in an XML stanza and should not be taken seriously as a functional 538 XMPP extension.) 539 Example 13: Message stanza with extended data contained in 540 "application/xmpp+xml" MIME type: 542 | 543 | 544 | 547 | 548 | I told him what I thought, and told no more 549 | Than what he found himself was apt and true. 550 | 551 | 552 | 553 | 555 Example 14: Presence stanza with extended data contained in 556 "application/xmpp+xml" MIME type: 558 | 559 | 560 | 561 | dnd 562 | Fomenting dissension 563 | 564 | 565 | 567 Example 15: IQ stanza with extended data contained in "application/ 568 xmpp+xml" MIME type: 570 | 571 | 572 | 576 | 577 | Stabber 578 | 666 579 | FiendOS 580 | 581 | 582 | 583 | 585 Just as with the "Message/CPIM" and "application/pidf+xml" objects, 586 the "application/xmpp+xml" object would be signed and/or encrypted, 587 then encapsulated within an XML CDATA section (see Section 2.7 of 588 [XML]) contained in an child of a stanza, where 589 the element is qualified by the 590 'urn:ietf:params:xml:ns:xmpp-e2e' namespace. 592 6. Rules for S/MIME Generation and Handling 594 6.1 Certificate Enrollment 596 [SMIME] does not specify how to obtain a certificate from a 597 certificate authority, but instead mandates that every sending agent 598 must already have a certificate. The PKIX Working Group has, at the 599 time of this writing, produced two separate standards for certificate 600 enrollment: [CMP] and [CMC]. Which method to use for certificate 601 enrollment is outside the scope of this memo. 603 6.2 Certificate Retrieval 605 A receiving agent MUST provide some certificate retrieval mechanism 606 in order to gain access to certificates for recipients of digital 607 envelopes. This memo does not address how S/MIME agents handle 608 certificates, only what they do after a certificate has been 609 validated or rejected. S/MIME certification issues are covered in 610 [CERT]. 612 However, at a minimum, for initial S/MIME deployment, a user agent 613 SHOULD automatically generate a message to an intended recipient 614 requesting that recipient's certificate in a signed return message. 615 Receiving and sending agents SHOULD also provide a mechanism to allow 616 a user to "store and protect" certificates for correspondents in such 617 a way so as to guarantee their later retrieval. 619 6.3 Certificate Names 621 End-entity certificates used by XMPP entities in the context of this 622 memo SHOULD contain a valid instant messaging and presence address. 623 The address SHOULD be specified as both an 'im:' URI (for instant 624 messaging, as defined in [CPIM]) and a 'pres:' URI (for presence, as 625 defined in [CPP]); each of these URIs SHOULD be specified in a 626 separate GeneralName entry of type uniformResourceIdentifier inside 627 the subjectAltName (i.e., two separate entries). Information in the 628 subject distinguished name SHOULD be ignored. 630 Each URI MUST be of the form or , where 631 the "address" portion is an XMPP address (also referred to as a 632 Jabber Identifier or JID) as defined in [XMPP-CORE], prepended with 633 the 'im:' or 'pres:' URI scheme. The address SHOULD be of the form 634 (i.e., a "bare JID"), although any valid JID form MAY 635 be used. 637 The value of the JID contained in the XMPP 'from' attribute MUST 638 match a JID provided in the signer's certificate, with the exception 639 that the resource identifier portion of the JID contained in the 640 'from' attribute SHOULD be ignored for matching purposes. 642 Receiving agents MUST check that the sending JID matches a JID 643 provided in the signer's certificate, with the exception that the 644 resource identifier portion of the JID contained in the 'from' 645 attribute SHOULD be ignored for matching purposes. A receiving agent 646 SHOULD provide some explicit alternate processing of the stanza if 647 this comparison fails, which may be to display a message informing 648 the recipient of the addresses in the certificate or other 649 certificate details. 651 The subject alternative name extension is used in S/MIME as the 652 preferred means to convey the instant messaging and presence address 653 that corresponds to the entity for this certificate. Any XMPP 654 address present in the certificate MUST be encoded using the ASN.1 655 Object Identifier "id-on-xmppAddr" as specified in Section 5.1.1 of 656 [XMPP-CORE]. 658 6.4 Transfer Encoding 660 Because it is expected that XMPP applications will not interface with 661 older 7-bit systems, the transfer encoding (as defined in Section 662 3.1.2 of [SMIME]) MUST be "binary". 664 6.5 Order of Signing and Encrypting 666 If a stanza is both signed and encrypted, it SHOULD be signed first, 667 then encrypted. 669 6.6 Inclusion of Certificates 671 If the sender and recipient are involved in an active messaging 672 session over a period of time, the sending agent SHOULD include the 673 sender's certificate along with at least one encrypted message stanza 674 every five minutes. Outside the context of an active messaging 675 session, the sending agent SHOULD include the sender's certificate 676 along with each encrypted message stanza. A sending agent MAY 677 include the sender's certificate along with each encrypted presence 678 stanza. However, a sending agent SHOULD NOT include a certificate 679 more than once every five minutes. 681 6.7 Attachment and Checking of Signatures 683 Sending agents SHOULD attach a signature to each encrypted XML 684 stanza. If a signature is attached, a Content-Disposition header 685 field (as defined in [DISP]) SHOULD be included to specify how the 686 signature is to be handled by the receiving application. 688 If the receiving agent determines that the signature attached to an 689 encrypted XML stanza is invalid, it SHOULD NOT present the stanza to 690 the intended recipient (human or application), SHOULD provide some 691 explicit alternate processing of the stanza (which may be to display 692 a message informing the recipient that the attached signature is 693 invalid), and MAY return a stanza error to the sender as described 694 under Recipient Error Handling (Section 7). 696 6.8 Decryption 698 If the receiving agent is unable to decrypt the encrypted XML stanza, 699 it SHOULD NOT present the stanza to the intended recipient (human or 700 application), SHOULD provide some explicit alternate processing of 701 the stanza (which may be to display a message informing the recipient 702 that it has received a stanza that cannot be decrypted), and MAY 703 return a stanza error to the sender as described under Recipient 704 Error Handling (Section 7). 706 6.9 Inclusion and Checking of Timestamps 708 Timestamps are included in "Message/CPIM" and "application/pidf+xml" 709 objects to help prevent replay attacks. All timestamps MUST conform 710 to [DATETIME] and be presented as UTC with no offset, including 711 fractions of a second as appropriate. Absent a local adjustment to 712 the sending agent's perceived time or the underlying clock time, the 713 sending agent MUST ensure that the timestamps it sends to the 714 receiver increase monotonically (if necessary by incrementing the 715 seconds fraction in the timestamp if the clock returns the same time 716 for multiple requests). The following rules apply to the receiving 717 application: 719 o It MUST verify that the timestamp received is within five minutes 720 of the current time. 721 o It SHOULD verify that the timestamp received is greater than any 722 timestamp received in the last 10 minutes which passed the 723 previous check. 724 o If any of the foregoing checks fails, the timestamp SHOULD be 725 presented to the receiving entity (human or application) marked as 726 "old timestamp", "future timestamp", or "decreasing timestamp", 727 and the receiving entity MAY return a stanza error to the sender 728 as described under Recipient Error Handling (Section 7). 730 6.10 Mandatory-to-Implement Cryptographic Algorithms 732 All implementations MUST support the following algorithms. 733 Implementations MAY support other algorithms as well. 735 For CMS SignedData: 737 o The SHA-1 message digest as specified in [CMS-ALG] section 2.1. 738 o The RSA (PKCS #1 v1.5) with SHA-1 signature algorithm, as 739 specified in [CMS-ALG] section 3.2. 741 For CMS EnvelopedData: 743 o The RSA (PKCS #1 v1.5) key transport, as specified in [CMS-ALG] 744 section 4.2.1. 745 o The AES-128 encryption algorithm in CBC mode, as specified in 746 [CMS-AES]. 748 7. Recipient Error Handling 750 When an XMPP entity receives an XML stanza containing data that is 751 signed and/or encrypted using the protocol described herein, several 752 scenarios are possible: 754 Case #1: The receiving application does not understand the protocol. 755 Case #2: The receiving application understands the protocol and is 756 able to decrypt the payload and verify the sender's signature. 757 Case #3: The receiving application understands the protocol and is 758 able to decrypt the payload and verify the sender's signature, but 759 the timestamps fail the checks specified above under Checking of 760 Timestamps (Section 6.9). 761 Case #4: The receiving application understands the protocol and is 762 able to decrypt the payload but is unable to verify the sender's 763 signature. 764 Case #5: The receiving application understands the protocol but is 765 unable to decrypt the payload. 767 In Case #1, the receiving application MUST do one and only one of the 768 following: (1) ignore the extension, (2) ignore the entire 769 stanza, or (3) return a error to the sender, 770 as described in [XMPP-CORE]. 772 In Case #2, the receiving application MUST NOT return a stanza error 773 to the sender, since this is the success case. 775 In Case #3, the receiving application MAY return a 776 error to the sender (as described in [XMPP-CORE]), optionally 777 supplemented by an application-specific error condition element 778 as shown below: 780 Example 16: Recipient returns error: 782 783 784 [CDATA section here] 785 786 787 788 789 790 792 In Case #4, the receiving application SHOULD return a 793 error to the sender (as described in [XMPP-CORE]), 794 optionally supplemented by an application-specific error condition 795 element as shown below: 797 Example 17: Recipient returns error: 799 800 801 [CDATA section here] 802 803 804 805 806 807 809 In Case #5, the receiving application SHOULD return a 810 error to the sender (as described in [XMPP-CORE]), optionally 811 supplemented by an application-specific error condition element 812 as shown below: 814 Example 18: Recipient returns error: 816 817 818 [CDATA section here] 819 820 821 822 823 824 826 8. Secure Communications Through a Gateway 828 A common method for achieving interoperability between two disparate 829 services is through the use of a "gateway" that interprets the 830 protocols of each service and translates them into the protocols of 831 the other. The CPIM specifications (specifically [MSGFMT] and [PIDF] 832 define the common profiles to be used for interoperability between 833 instant messaging and presence services that comply with [IMP-REQS]. 834 In the case of communications between an XMPP service and a non-XMPP 835 service, we can visualize this relationship as follows: 837 +-------------+ +-------------+ +------------+ 838 | | | | | | 839 | XMPP | | XMPP-CPIM | | Non-XMPP | 840 | Service | <----> | Gateway | <----> | Service | 841 | | | | | | 842 +-------------+ +-------------+ +------------+ 844 The end-to-end encryption method defined herein enables the exchange 845 of encrypted and/or signed instant messages and presence through an 846 XMPP-CPIM gateway. In particular: 848 o When a gateway receives a secured XMPP message or presence stanza 849 from the XMPP service that is addressed to a user on the non-XMPP 850 service, it MUST remove the XMPP "wrapper" (everything down to and 851 including the and tags) in order to reveal the 852 multipart S/MIME object, then route the object to the non-XMPP 853 service (first wrapping it in the protocol used by the non-XMPP 854 service if necessary). 855 o When a gateway receives a secured non-XMPP instant message or 856 presence document from the non-XMPP service that is addressed to a 857 user on the XMPP service, it MUST remove the non-XMPP "wrapper" 858 (if any) in order to reveal the multipart S/MIME object, wrap the 859 object in an XMPP message or presence "wrapper" (including the 860 and tags), and then route the XMPP stanza to the XMPP 861 service. 863 The wrapped S/MIME object MUST be immutable and MUST NOT be modified 864 by an XMPP-CPIM gateway. 866 9. urn:ietf:params:xml:xmpp-e2e Namespace 868 The element is a 869 wrapper for an XML CDATA section (see Section 2.7 of [XML]) that 870 contains a "Message/CPIM", "application/pidf+xml", or "application/ 871 xmpp+xml" object. Thus the 'urn:ietf:params:xml:xmpp-e2e' namespace 872 has no inherent semantics, and the semantics of the encapsulated 873 object are defined by one of the following specifications: 875 o [MSGFMT] for "Message/CPIM" 876 o [PIDF] for "application/pidf+xml" 877 o [XMPP-CORE] for "application/xmpp+xml" 879 Although the "application/xmpp+xml" media type is specified in this 880 document, the element is simply a wrapper for a , 881 , or stanza, where the semantics of those stanza 882 types are specified in [XMPP-CORE]. 884 Given that the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace has no 885 inherent semantics and specifies a using protocol only, versioning is 886 the responsibility of the protocols that define the encapsulated 887 objects ([MSGFMT], [PIDF], and [XMPP-CORE]). 889 10. application/xmpp+xml Media Type 891 The "application/xmpp+xml" media type adheres to the guidelines 892 specified in [XML-MEDIA]. The root element for this MIME type is 893 , and the root element MUST contain one and only one child 894 element, corresponding to one of the XMPP stanza types (i.e., 895 message, presence, or iq) if the default namespace is 'jabber:client' 896 or 'jabber:server' as defined in [XMPP-CORE]. The character encoding 897 for this XML media type MUST be UTF-8, in accordance with Section 898 11.5 of [XMPP-CORE]. 900 11. Security Considerations 902 This entire memo discusses security. Detailed security 903 considerations for instant messaging and presence protocols are given 904 in [IMP-REQS] (Sections 5.1 through 5.4), and for XMPP in particular 905 are given in [XMPP-CORE] (Sections 12.1 through 12.6). In addition, 906 all of the security considerations specified in [XML-MEDIA] apply to 907 the "application/xmpp+xml" media type. 909 The end-to-end security method defined here MAY result in exchanging 910 secured instant messages and presence information through a gateway 911 that implements the CPIM specifications. Such a gateway MUST be 912 compliant with the minimum security requirements of the instant 913 messaging and presence protocols with which it interfaces. 915 12. IANA Considerations 917 12.1 XML Namespace Name for e2e Data in XMPP 919 A URN sub-namespace for signed and encrypted content in the 920 Extensible Messaging and Presence Protocol (XMPP) is defined as 921 follows. (This namespace name adheres to the format defined in 922 [XML-REG].) 923 URI: urn:ietf:params:xml:ns:xmpp-e2e 924 Specification: XXXX 925 Description: This is the XML namespace name for signed and encrypted 926 content in the Extensible Messaging and Presence Protocol as 927 defined by XXXX. 928 Registrant Contact: IESG, 930 12.2 Content-type Registration for "application/xmpp+xml" 932 To: ietf-types@iana.org 934 Subject: Registration of MIME media type application/xmpp+xml 936 MIME media type name: application 937 MIME subtype name: xmpp+xml 938 Required parameters: (none) 939 Optional parameters: (charset) Same as charset parameter of 940 application/xml as specified in RFC 3023; per Section 11.5 of 941 [draft-ietf-xmpp-core-24], the charset must be UTF-8. 942 Encoding considerations: Same as encoding considerations of 943 application/xml as specified in RFC 3023; per Section 11.5 of 944 [draft-ietf-xmpp-core-24], the encoding must be UTF-8. 945 Security considerations: All of the security considerations specified 946 in RFC 3023 and [draft-ietf-xmpp-core-24] apply to this XML media 947 type. Refer to Section 11 of XXXX. 948 Interoperability considerations: (none) 949 Specification: XXXX 950 Applications which use this media type: XMPP-compliant instant 951 messaging and presence systems. 952 Additional information: (none) 953 Person and email address to contact for further information: IESG, 954 955 Intended usage: COMMON 956 Author/Change controller: IETF, XMPP Working Group 958 13. References 960 13.1 Normative References 962 [CERT] Ramsdell, B., "S/MIME Version 3.1 Certificate Handling", 963 draft-ietf-smime-rfc2632bis-07 (work in progress), June 964 2004. 966 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", 967 draft-ietf-smime-rfc3369bis-04 (work in progress), May 968 2004. 970 [CMS-AES] Schaad, J., "Use of the Advanced Encryption Standard (AES) 971 Encryption Algorithm in Cryptographic Message Syntax 972 (CMS)", RFC 3565, July 2003. 974 [CMS-ALG] Housley, R., "Cryptographic Message Syntax (CMS) 975 Algorithms", RFC 3370, August 2002. 977 [CPIM] Peterson, J., "Common Profile for Instant Messaging 978 (CPIM)", draft-ietf-impp-im-04 (work in progress), 979 February 2004. 981 [CPP] Peterson, J., "Common Profile for Presence (CPP)", 982 draft-ietf-impp-pres-04 (work in progress), February 2004. 984 [DATETIME] 985 Klyne, G. and C. Newman, "Date and Time on the Internet: 986 Timestamps", RFC 3339, July 2002. 988 [DISP] Troost, R., Dorner, S. and K. Moore, "Communicating 989 Presentation Information in Internet Messages: The 990 Content-Disposition Header Field", RFC 2183, August 1997. 992 [IMP-MODEL] 993 Day, M., Rosenberg, J. and H. Sugano, "A Model for 994 Presence and Instant Messaging", RFC 2778, February 2000, 995 . 997 [IMP-REQS] 998 Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / 999 Presence Protocol Requirements", RFC 2779, February 2000. 1001 [MSGFMT] Atkins, D. and G. Klyne, "Common Presence and Instant 1002 Messaging: Message Format", draft-ietf-impp-cpim-msgfmt-08 1003 (work in progress), January 2003. 1005 [MULTI] Galvin, J., Murphy, S., Crocker, S. and N. Freed, 1006 "Security Multiparts for MIME: Multipart/Signed and 1007 Multipart/Encrypted", RFC 1847, October 1995. 1009 [PIDF] Fujimoto, S., Sugano, H., Klyne, G., Bateman, A., Carr, W. 1010 and J. Peterson, "Presence Information Data Format", 1011 draft-ietf-impp-cpim-pidf-08 (work in progress), May 2003. 1013 [SMIME] Ramsdell, B., "S/MIME Version 3.1 Message Specification", 1014 draft-ietf-smime-rfc2633bis-09 (work in progress), April 1015 2004. 1017 [TERMS] Bradner, S., "Key words for use in RFCs to Indicate 1018 Requirement Levels", BCP 14, RFC 2119, March 1997. 1020 [X509] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet 1021 X.509 Public Key Infrastructure Certificate and 1022 Certificate Revocation List (CRL) Profile", RFC 3280, 1023 April 2002. 1025 [XML-MEDIA] 1026 Murata, M., St. Laurent, S. and D. Kohn, "XML Media 1027 Types", RFC 3023, January 2001. 1029 [XMPP-CORE] 1030 Saint-Andre, P., "XMPP Core", draft-ietf-xmpp-core-24 1031 (work in progress), May 2004. 1033 [XMPP-IM] Saint-Andre, P., "XMPP Instant Messaging", 1034 draft-ietf-xmpp-im-22 (work in progress), May 2004. 1036 13.2 Informative References 1038 [CAPS] Hildebrand, J. and P. Saint-Andre, "JEP-0115: Entity 1039 Capabilities", April 2004, 1040 . 1042 [CMC] Myers, M., Liu, X., Schaad, J. and J. Weinstein, 1043 "Certificate Management Messages over CMS", RFC 2797, 1044 April 2000. 1046 [CMP] Adams, C. and S. Farrell, "Internet X.509 Public Key 1047 Infrastructure Certificate Management Protocols", RFC 1048 2510, March 1999. 1050 [DISCO] Hildebrand, J., Millard, P., Eatmon, R. and P. 1051 Saint-Andre, "JEP-0030: Service Discovery", June 2004, 1052 . 1054 [MUC] Saint-Andre, P., "JEP-0045: Multi-User Chat", June 2004, 1055 . 1057 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, 1058 "Extensible Markup Language (XML) 1.0 (3rd ed)", W3C 1059 REC-xml, February 2004, . 1061 [XML-REG] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1062 January 2004. 1064 [XMPP-CPIM] 1065 Saint-Andre, P., "Mapping the Extensible Messaging and 1066 Presence Protocol (XMPP) to Common Presence and Instant 1067 Messaging (CPIM)", draft-ietf-xmpp-cpim-05 (work in 1068 progress), May 2004. 1070 Author's Address 1072 Peter Saint-Andre 1073 Jabber Software Foundation 1075 EMail: stpeter@jabber.org 1077 Appendix A. Schema for urn:ietf:params:xml:ns:xmpp-e2e 1079 The following XML schema is descriptive, not normative. 1081 1083 1089 1091 1092 1093 1095 1096 1097 1098 1099 1101 1103 Appendix B. Revision History 1105 Note to RFC Editor: please remove this entire appendix, and the 1106 corresponding entries in the table of contents, prior to publication. 1108 B.1 Changes from draft-ietf-xmpp-e2e-08 1110 o Changed title to mention signing in addition to encryption. 1111 o Specified several functionality areas that are out of scope for 1112 this memo. 1114 o Added clarifying text to the examples, split several examples in 1115 order to correspond to the defined process steps, and added 1116 examples for encrypting both messages and presence information. 1117 o Changed SHOULD to MUST regarding checking of XMPP addresses. 1118 o Changed "could" to SHOULD regarding sending of initial message 1119 requesting certificate retrieval. 1120 o Specified that 'from' attributes MUST (rather than SHOULD) match a 1121 JID contained in the sender's certificate, and that resource 1122 identifiers SHOULD be ignored for matching purposes. 1123 o More fully defined S/MIME handling, including correct processing 1124 of XML stanzas with invalid signatures, stanzas that cannot be 1125 decrypted, and messages that appear to be replayed. 1126 o Defined recipient generation of XMPP error stanzas. 1127 o Incorporated text for "Mandatory-to-Implement Cryptographic 1128 Algorithms" suggested by Russ Housley. 1129 o Referred to Section 5.1.1 of XMPP-CORE regarding ASN.1 Object 1130 Identifier to be used when an XMPP address is represented in a 1131 certificate. 1132 o Added reference to RFC 3565. 1133 o Fixed CMC reference to point to RFC 2797. 1134 o Updated references to point to rfc2632bis, rfc2633bis, and 1135 rfc3369bis. 1136 o Updated boilerplate to refer to RFC 3668. 1137 o Removed Discussion Venue subsection. 1139 B.2 Changes from draft-ietf-xmpp-e2e-07 1141 o Clarified relationship of the 'urn:ietf:params:xml:ns:xmpp-e2e' 1142 namespace to its encapsulated objects, including versioning, and 1143 placed this content in its own section. 1144 o Clarified nature of "application/xmpp+xml" media type and placed 1145 this content in its own section. 1146 o Added reference to RFC 3023 and modified XML media type 1147 registration to adhere to the guidelines specified therein. 1148 o Changed XML params registrant to IESG, per RFC 3688. 1149 o Updated other references. 1151 B.3 Changes from draft-ietf-xmpp-e2e-06 1153 o Specified use of SHA-1 for digest and AES for content encryption. 1154 o Specified order of signing then encrypting. 1155 o Specified format and checking of timestamps. 1156 o Clarified use of subjectAltName field, where the GeneralName 1157 content is a URI of the form im:user@host and pres:user@host. 1158 o Clarified circumstances under which certificates should be 1159 attached. 1160 o Added Content-Disposition header field to examples. 1162 B.4 Changes from draft-ietf-xmpp-e2e-05 1164 o Addressed I-D nits and RFC Editor formatting. 1166 B.5 Changes from draft-ietf-xmpp-e2e-04 1168 o Added text about instant inbox addresses. 1170 B.6 Changes from draft-ietf-xmpp-e2e-03 1172 o Specified that S/MIME multipart objects are enclosed in a CDATA 1173 section. 1174 o Changed "text/xml" to "text/plain" for message examples. 1175 o Specified must-implement technologies, transfer encodings, 1176 certificate enrollment, certificate retrieval, and certificate 1177 names (including subjectAltName for JIDs). 1178 o Specified requirements regarding attachment of signatures and 1179 inclusion of certificates. 1180 o Fixed some small terminological errors. 1182 B.7 Changes from draft-ietf-xmpp-e2e-02 1184 o Completely revised to use formats defined in the CPIM 1185 specifications, S/MIME only, etc. 1187 B.8 Changes from draft-ietf-xmpp-e2e-01 1189 o Removed old Section 6 (Signalling Support via Presence) -- the 1190 ability to sign broadcasted presence made it redundant. 1191 o Made small editorial changes to address RFC Editor requirements. 1193 B.9 Changes from draft-ietf-xmpp-e2e-00 1195 o Added support for all stanza types. 1196 o Specified that the full stanza is encrypted. 1197 o Added support for S/MIME in addition to OpenPGP. 1198 o Specified that encrypted presence must be directed to a specific 1199 recipient. 1200 o Specified order of encrypting and signing. 1201 o Added support for signing broadcasted presence. 1202 o Added IANA considerations. 1203 o Changed namespace to 'urn:ietf:params:xml:ns:xmpp-e2e'. 1204 o Added XML schema. 1206 Intellectual Property Statement 1208 The IETF takes no position regarding the validity or scope of any 1209 Intellectual Property Rights or other rights that might be claimed to 1210 pertain to the implementation or use of the technology described in 1211 this document or the extent to which any license under such rights 1212 might or might not be available; nor does it represent that it has 1213 made any independent effort to identify any such rights. Information 1214 on the procedures with respect to rights in RFC documents can be 1215 found in BCP 78 and BCP 79. 1217 Copies of IPR disclosures made to the IETF Secretariat and any 1218 assurances of licenses to be made available, or the result of an 1219 attempt made to obtain a general license or permission for the use of 1220 such proprietary rights by implementers or users of this 1221 specification can be obtained from the IETF on-line IPR repository at 1222 http://www.ietf.org/ipr. 1224 The IETF invites any interested party to bring to its attention any 1225 copyrights, patents or patent applications, or other proprietary 1226 rights that may cover technology that may be required to implement 1227 this standard. Please address the information to the IETF at 1228 ietf-ipr@ietf.org. 1230 Disclaimer of Validity 1232 This document and the information contained herein are provided on an 1233 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1234 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1235 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1236 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1237 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1238 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1240 Copyright Statement 1242 Copyright (C) The Internet Society (2004). This document is subject 1243 to the rights, licenses and restrictions contained in BCP 78, and 1244 except as set forth therein, the authors retain all their rights. 1246 Acknowledgment 1248 Funding for the RFC Editor function is currently provided by the 1249 Internet Society.