idnits 2.17.1 draft-ietf-xmpp-e2e-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 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 exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- 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 (November 20, 2003) is 7462 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 normative reference: RFC 2632 (ref. 'CERT') (Obsoleted by RFC 3850) ** Downref: Normative reference to an Informational RFC: RFC 2792 (ref. 'CMC') ** Obsolete normative reference: RFC 2510 (ref. 'CMP') (Obsoleted by RFC 4210) ** Obsolete normative reference: RFC 3369 (ref. 'CMS') (Obsoleted by RFC 3852) == Outdated reference: A later version (-04) exists of draft-ietf-impp-im-03 == Outdated reference: A later version (-04) exists of draft-ietf-impp-pres-03 ** 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 2633 (ref. 'SMIME') (Obsoleted by RFC 3851) == Outdated reference: A later version (-24) exists of draft-ietf-xmpp-core-20 == Outdated reference: A later version (-22) exists of draft-ietf-xmpp-im-19 == Outdated reference: A later version (-05) exists of draft-ietf-xmpp-cpim-03 Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 3 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: May 20, 2004 November 20, 2003 5 End-to-End Object Encryption in the Extensible Messaging and Presence 6 Protocol (XMPP) 7 draft-ietf-xmpp-e2e-06 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on May 20, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2003). All Rights Reserved. 35 Abstract 37 This memo defines a method for end-to-end object signing and 38 encryption in the Extensible Messaging and Presence Protocol (XMPP). 40 Table of Contents 42 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 43 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 44 3. Securing Messages . . . . . . . . . . . . . . . . . . . . . . 5 45 4. Securing Presence . . . . . . . . . . . . . . . . . . . . . . 6 46 5. Securing Arbitrary XMPP Data . . . . . . . . . . . . . . . . . 8 47 6. Rules for S/MIME Generation and Handling . . . . . . . . . . . 9 48 7. Secure Communications Through a Gateway . . . . . . . . . . . 11 49 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 50 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 51 Normative References . . . . . . . . . . . . . . . . . . . . . 14 52 Informative References . . . . . . . . . . . . . . . . . . . . 15 53 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15 54 A. Schema for urn:ietf:params:xml:ns:xmpp-e2e . . . . . . . . . . 15 55 B. Revision History . . . . . . . . . . . . . . . . . . . . . . . 16 56 Intellectual Property and Copyright Statements . . . . . . . . 18 58 1. Introduction 60 This memo define a method for end-to-end signing and encryption in 61 the Extensible Messaging and Presence Protocol (XMPP). (For 62 information about XMPP, see [XMPP-CORE] and [XMPP-IM].) The method 63 defined herein enables a sender to encrypt and/or sign an instant 64 message sent to a specific recipient, encrypt and/or sign presence 65 information that is directed to a specific user, and sign presence 66 information that is broadcasted to a specific user. This memo 67 thereby helps the XMPP specifications meet the requirements defined 68 in [IMP-REQS]. 70 1.1 Terminology 72 This document inherits terminology defined in [SMIME], [IMP-MODEL], 73 [CMS], and [XMPP-CORE]. 75 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 76 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 77 "OPTIONAL" in this document are to be interpreted as described in 78 [TERMS]. 80 1.2 Discussion Venue 82 The authors welcome discussion and comments related to the topics 83 presented in this document. The preferred forum is the 84 mailing list, for which archives and subscription 85 information are available at . 88 1.3 Intellectual Property Notice 90 This document is in full compliance with all provisions of Section 10 91 of RFC 2026. Parts of this specification use the term "jabber" for 92 identifying namespaces and other protocol syntax. Jabber[tm] is a 93 registered trademark of Jabber, Inc. Jabber, Inc. grants permission 94 to the IETF for use of the Jabber trademark in association with this 95 specification and its successors, if any. 97 2. Requirements 99 For the purposes of this memo, we stipulate the following 100 requirements: 102 1. The method defined MUST address encryption and signing 103 requirements for minimal instant messaging and presence only, as 104 those are defined in [IMP-REQS]. The method is NOT REQUIRED to 105 support non-IM applications of XMPP, nor to support advanced 106 instant messaging and presence functionality that is outside the 107 scope of [IMP-REQS]. In particular, the method MUST address the 108 following requirements defined in [IMP-REQS]: 110 * The protocol MUST provide means to ensure confidence that a 111 received message (NOTIFICATION or INSTANT MESSAGE) has not 112 been corrupted or tampered with. (Section 2.5.1) 114 * The protocol MUST provide means to ensure confidence that a 115 received message (NOTIFICATION or INSTANT MESSAGE) has not 116 been recorded and played back by an adversary. (Section 117 2.5.2) 119 * The protocol MUST provide means to ensure that a sent message 120 (NOTIFICATION or INSTANT MESSAGE) is only readable by ENTITIES 121 that the sender allows. (Section 2.5.3) 123 * The protocol MUST allow any client to use the means to ensure 124 non-corruption, non-playback, and privacy, but the protocol 125 MUST NOT require that all clients use these means at all 126 times. (Section 2.5.4) 128 * When A establishes a SUBSCRIPTION to B's PRESENCE INFORMATION, 129 the protocol MUST provide A means of verifying the accurate 130 receipt of the content B chooses to disclose to A. (Section 131 5.1.4) 133 * The protocol MUST provide A means of verifying that the 134 presence information is accurate, as sent by B. (Section 135 5.3.1) 137 * The protocol MUST provide A means of ensuring that no other 138 PRINCIPAL C can see the content of M. (Section 5.4.6) 140 * The protocol MUST provide A means of ensuring that no other 141 PRINCIPAL C can tamper with M, and B means to verify that no 142 tampering has occurred. (Section 5.4.7) 144 2. The method defined MUST enable interoperability with non-XMPP 145 messaging systems that support the Common Presence and Instant 146 Messaging (CPIM) specifications defined by the Instant Messaging 147 and Presence (IMPP) Working Group. Therefore: 149 * Prior to encrypting or signing, the format of an instant 150 message must conform to the CPIM Message Format defined in 151 [MSGFMT]. 153 * Prior to encrypting or signing, the format of presence 154 information must conform to the CPP Presence Information Data 155 Format defined in [PIDF]. 157 3. The method MUST follow the required procedures (including the 158 specific algorithms) defined in [CPIM] and [CPP]. In particular, 159 these documents specify: 161 * Encryption MUST use [SMIME] encryption with [CMS] 162 EnvelopeData. 164 * Signing MUST use [SMIME] signatures with [CMS] SignedData. 166 4. In order to enable interoperable implementations, sending and 167 receiving applications MUST implement the algorithms defined 168 under Section 6.7. 170 3. Securing Messages 172 In order to encrypt a message, a sending entity MUST use the 173 following procedure: 175 1. Generate a "Message/CPIM" object as defined in [MSGFMT]. 177 2. Encrypt and/or sign both the headers and content of the "Message/ 178 CPIM" object as specified in Requirement 3 of Section 2 above. 180 3. Provide the resulting multipart S/MIME object (see [MULTI]) 181 within a CDATA section of an child of a stanza, 182 where the element is qualified by the 183 'urn:ietf:params:xml:ns:xmpp-e2e' namespace. 185 Example 1: Sender generates "Message/CPIM" object: 187 Content-type: Message/CPIM 189 From: Juliet Capulet 190 To: Romeo Montague 191 DateTime: 2003-05-14T11:45:36Z 192 Subject: Imploring 194 Content-type: text/plain; charset=utf-8 195 Content-ID: <1234567890@example.com> 197 Wherefore art thou, Romeo? 199 Example 2: Sender generates signed message (the 'from' address on the 200 XMPP message stanza is stamped by sender's server): 202 203 204 213 To: Romeo Montague 214 DateTime: 2003-05-14T23:45:36Z 215 Subject: Imploring 217 Content-type: text/plain; charset=utf-8 218 Content-ID: <1234567890@example.com> 220 Wherefore art thou, Romeo? 221 --next 222 Content-Type: application/pkcs7-signature 224 [signed body part] 226 --next-- 227 ]]> 228 229 231 4. Securing Presence 233 In order to encrypt presence information, a sending entity MUST use 234 the following procedure: 236 1. Generate an "application/pidf+xml" object as defined in [PIDF]. 238 2. Encrypt and/or sign the "application/pidf+xml" object as 239 specified in Requirement 3 of Section 2 above. 241 3. Provide the resulting S/MIME object within a CDATA section of an 242 child of a stanza, where the element is 243 qualified by the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace. 244 The stanza MUST include a 'to' attribute, i.e., it 245 must be an instance of directed presence as defined in [XMPP-IM]. 247 Example 3: Sender generates "application/pidf+xml" object: 249 250 253 255 open 256 away 257 258 retired to the chamber 259 2003-05-14T23:53:11Z 260 261 263 Example 4: Sender generates signed presence (the 'from' address on 264 the XMPP presence stanza is stamped by sender's server): 266 267 268 277 278 281 282 283 open 284 away 285 286 retired to the chamber 287 2003-05-14T23:53:11Z 288 289 290 --next 291 Content-Type: application/pkcs7-signature 293 [signed body part] 295 --next-- 296 ]]> 297 298 300 5. Securing Arbitrary XMPP Data 302 The foregoing sections of this memo describe how to secure "least 303 common denominator" messaging and presence data of the kind that can 304 be directly translated into the MSGFMT or PIDF formats. However, 305 XMPP possesses a third base-level stanza type () in addition to 306 and , as well as the ability to include 307 extended XML data within arbitrary child elements of the three core 308 stanza types. Therefore it would be desirable to secure such data if 309 possible. 311 Because [MSGFMT] specifies the ability to encapsulate any MIME type, 312 the approach taken in this memo is to include arbitrary XMPP data in 313 a new MIME type, "application/xmpp+xml". The root element for this 314 MIME type is , and the root element MUST contain one and only 315 one child element, corresponding to one of the XMPP stanza types 316 (i.e., message, presence, or iq) if the default namespace is 317 'jabber:client' or 'jabber:server' as defined in [XMPP-CORE]. 319 The following examples illustrate the structure of the "application/ 320 xmpp+xml" MIME type. 322 Example 5: Message stanza with extended data contained in 323 "application/xmpp+xml" MIME type: 325 326 327 330 331 I told him what I thought, and told no more 332 Than what he found himself was apt and true. 333 334 335 336 338 Example 6: Presence stanza with extended data contained in 339 "application/xmpp+xml" MIME type: 341 342 343 344 dnd 345 Fomenting dissension 346 347 348 350 Example 7: IQ stanza with extended data contained in "application/ 351 xmpp+xml" MIME type: 353 354 355 359 360 Stabber 361 666 362 FiendOS 363 364 365 366 368 6. Rules for S/MIME Generation and Handling 370 6.1 Certificate Enrollment 372 S/MIME v3 does not specify how to obtain a certificate from a 373 certificate authority, but instead mandates that every sending agent 374 must already have a certificate. The PKIX Working Group has, at the 375 time of this writing, produced two separate standards for certificate 376 enrollment: [CMP] and [CMC]. Which method to use for certificate 377 enrollment is outside the scope of this memo. 379 6.2 Certificate Retrieval 381 A receiving agent MUST provide some certificate retrieval mechanism 382 in order to gain access to certificates for recipients of digital 383 envelopes. This memo does not cover how S/MIME agents handle 384 certificates, only what they do after a certificate has been 385 validated or rejected. S/MIME certification issues are covered in 386 [CERT]. 388 At a minimum, for initial S/MIME deployment, a user agent could 389 automatically generate a message to an intended recipient requesting 390 that recipient's certificate in a signed return message. Receiving 391 and sending agents SHOULD also provide a mechanism to allow a user to 392 "store and protect" certificates for correspondents in such a way so 393 as to guarantee their later retrieval. 395 6.3 Certificate Names 397 End-entity certificates used in the context of this memo SHOULD a 398 valid instant messaging address. The address SHOULD be one of the 399 following: 401 1. An XMPP address (also referred to as a Jabber Identifier or JID) 402 as defined in [XMPP-CORE]; the address should be of the form 403 (i.e., a "bare JID"), although any valid JID form 404 MAY be used. The JID SHOULD be contained in the subjectAltName 405 extension, and SHOULD NOT be in the subject distinguished name. 407 2. An "instant inbox address" as defined in [IMP-MODEL] and 408 [MSGFMT]. As explained in [XMPP-CPIM], an instant inbox address 409 maps to a "bare JID" () once the 'im:' URI scheme 410 has been removed. The appropriate container for instant inbox 411 address shall be defined in [MSGFMT]. 413 The value of the JID contained in the XMPP 'from' attribute SHOULD 414 match the JID provided in the signer's certificate, with the 415 exception that the resource identifier portion of the JID contained 416 in the 'from' attribute MAY be ignored for matching purposes. 418 Receiving agents MUST recognize XMPP addresses (JIDs) in the 419 subjectAltName field. 421 Receiving agents SHOULD check that sending JID matches a JID provided 422 in the signer's certificate, with the exception that the resource 423 identifier portion of the JID contained in the 'from' attribute MAY 424 be ignored for matching purposes. A receiving agent SHOULD provide 425 some explicit alternate processing of the message if this comparison 426 fails, which may be to display a message that shows the recipient the 427 addresses in the certificate or other certificate details. 429 The subject alternative name extension is used in S/MIME as the 430 preferred means to convey the JID that corresponds to the entity for 431 this certificate. Any JIDs present SHOULD be encoded using the 432 otherName CHOICE of the subjectAltName type, where the type-id is 433 "xmpp" and the value is the bare JID of the entity. 435 6.4 Transfer Encoding 437 According to various S/MIME specifications for message wrapping, 438 [CMS] objects MAY optionally be wrapped in MIME to dynamically 439 support 7-bit transport. Because it is expected that XMPP will not 440 be used to interface with older 7-bit systems, this outer wrapping is 441 NOT REQUIRED for XMPP transport, and generally SHOULD NOT be applied 442 in a homogeneous XMPP environment or in an environment that supports 443 XMPP-CPIM gateways. 445 6.5 Attachment of Signatures 447 Sending agents SHOULD attach a signature to each encrypted message or 448 presence stanza, but are NOT REQUIRED to do so. 450 6.6 Inclusion of Certificates 452 Sending agents are NOT REQUIRED to include the sender's certificate 453 along with each encrypted message or presence stanza. 455 6.7 Mandatory to Implement Technologies 457 At a minimum, all implementations MUST support the following CMS 458 algorithms as defined in [CMS-ALG]: 460 for digest: DIGEST-MD5 462 for signing: RSA 464 for content encryption: Triple-DES CBC 466 7. Secure Communications Through a Gateway 468 A common method for achieving interoperability between two disparate 469 services is through the use of a "gateway" that interprets the 470 protocols of each service and translates them into the protocols of 471 the other. The CPIM specifications (specifically [MSGFMT] and [PIDF] 472 define the common profiles to be used for interoperability between 473 instant messaging and presence services that comply with [IMP-REQS]. 474 In the case of communications between an XMPP service and a non-XMPP 475 service, we can visualize this relationship as follows: 477 +-------------+ +-------------+ +------------+ 478 | | | | | | 479 | XMPP | | XMPP-CPIM | | Non-XMPP | 480 | Service | <----> | Gateway | <----> | Service | 481 | | | | | | 482 +-------------+ +-------------+ +------------+ 484 The end-to-end encryption method defined herein enables the exchange 485 of encrypted and/or signed instant messages and presence through an 486 XMPP-CPIM gateway. In particular: 488 o When a gateway receives a secured XMPP message or presence stanza 489 from the XMPP service that is addressed to a user on the non-XMPP 490 service, it MUST remove the XMPP "wrapper" (everything down to and 491 including the and tags) in order to reveal the 492 multipart S/MIME object, then route the object to the non-XMPP 493 service (first wrapping it in the protocol used by the non-XMPP 494 service if necessary). 496 o When a gateway receives a secured non-XMPP instant message or 497 presence document from the non-XMPP service that is addressed to a 498 user on the XMPP service, it MUST remove the non-XMPP "wrapper" 499 (if any) in order to reveal the multipart S/MIME object, wrap the 500 object in an XMPP message or presence "wrapper" (including the 501 and tags), and then route the XMPP stanza to the XMPP 502 service. 504 The wrapped S/MIME object MUST be immutable and MUST NOT be modified 505 by an XMPP-CPIM gateway. 507 8. Security Considerations 509 This entire memo discusses security. Detailed security 510 considerations for instant messaging and presence protocols are given 511 in [IMP-REQS] (Sections 5.1 through 5.4), and for XMPP in particular 512 are given in [XMPP-CORE] (Sections 12.1 through 12.6). 514 The end-to-end security method defined here MAY result in exchanging 515 secured instant messages and presence information through a gateway 516 that implements the CPIM specifications. Such a gateway MUST be 517 compliant with the minimum security requirements of the instant 518 messaging and presence protocols with which it interfaces. 520 9. IANA Considerations 522 9.1 Content-type Registration for "application/xmpp+xml" 524 To: ietf-types@iana.org 526 Subject: Registration of MIME media type application/xmpp+xml 528 MIME media type name: application 530 MIME subtype name: xmpp+xml 531 Required parameters: (none) 533 Optional parameters: charset Indicates the character encoding of the 534 enclosed XML; the default encoding is UTF-8. 536 Encoding considerations: Contains XML, which can employ 8-bit 537 characters, depending on the character encoding used. 539 Security considerations: Contains a message, presence information, or 540 IQ (request-response) data in XMPP, which may be considered 541 private. Appropriate precautions should be adopted to limit 542 disclosure of this information. 544 Interoperability considerations: (none) 546 Specification: XXXX 548 Applications which use this media type: XMPP-compliant instant 549 messaging and presence systems. 551 Additional information: (none) 553 Person and email address to contact for further information: IETF, 554 XMPP Working Group, 556 Intended usage: COMMON 558 Author/Change controller: IETF, XMPP Working Group 560 9.2 XML Namespace Name for e2e Data in XMPP 562 A URN sub-namespace for signed and encrypted content in the 563 Extensible Messaging and Presence Protocol (XMPP) is defined as 564 follows. (This namespace name adheres to the format defined in 565 [XML-REG].) 567 URI: urn:ietf:params:xml:ns:xmpp-e2e 569 Specification: XXXX 571 Description: This is the XML namespace name for signed and encrypted 572 content in the Extensible Messaging and Presence Protocol as 573 defined by XXXX. 575 Registrant Contact: IETF, XMPP Working Group, 577 Normative References 579 [CERT] Ramsdell, B., "S/MIME Version 3 Certificate Handling", RFC 580 2632, June 1999. 582 [CMC] Blaze, M., Ioannidis, J. and A. Keromytis, "DSA and RSA 583 Key and Signature Encoding for the KeyNote Trust 584 Management System", RFC 2792, March 2000. 586 [CMP] Adams, C. and S. Farrell, "Internet X.509 Public Key 587 Infrastructure Certificate Management Protocols", RFC 588 2510, March 1999. 590 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 591 3369, August 2002. 593 [CMS-ALG] Housley, R., "Cryptographic Message Syntax (CMS) 594 Algorithms", RFC 3370, August 2002. 596 [CPIM] Crocker, D. and J. Peterson, "Common Profile for Instant 597 Messaging (CPIM)", draft-ietf-impp-im-03 (work in 598 progress), May 2003. 600 [CPP] Crocker, D. and J. Peterson, "Common Profile for Presence 601 (CPP)", draft-ietf-impp-pres-03 (work in progress), May 602 2003. 604 [IMP-MODEL] 605 Day, M., Rosenberg, J. and H. Sugano, "A Model for 606 Presence and Instant Messaging", RFC 2778, February 2000, 607 . 609 [IMP-REQS] 610 Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / 611 Presence Protocol Requirements", RFC 2779, February 2000. 613 [MSGFMT] Atkins, D. and G. Klyne, "Common Presence and Instant 614 Messaging: Message Format", draft-ietf-impp-cpim-msgfmt-08 615 (work in progress), January 2003. 617 [MULTI] Galvin, J., Murphy, S., Crocker, S. and N. Freed, 618 "Security Multiparts for MIME: Multipart/Signed and 619 Multipart/Encrypted", RFC 1847, October 1995. 621 [PIDF] Fujimoto, S., Sugano, H., Klyne, G., Bateman, A., Carr, W. 622 and J. Peterson, "Presence Information Data Format", 623 draft-ietf-impp-cpim-pidf-08 (work in progress), May 2003. 625 [SMIME] Ramsdell, B., "S/MIME Version 3 Message Specification", 626 RFC 2633, June 1999. 628 [TERMS] Bradner, S., "Key words for use in RFCs to Indicate 629 Requirement Levels", BCP 14, RFC 2119, March 1997. 631 [XMPP-CORE] 632 Saint-Andre, P., "XMPP Core", draft-ietf-xmpp-core-20 633 (work in progress), November 2003. 635 [XMPP-IM] Saint-Andre, P., "XMPP Instant Messaging", 636 draft-ietf-xmpp-im-19 (work in progress), November 2003. 638 Informative References 640 [XML-REG] Mealling, M., "The IANA XML Registry", 641 draft-mealling-iana-xmlns-registry-05 (work in progress), 642 June 2003. 644 [XMPP-CPIM] 645 Saint-Andre, P., "Mapping the Extensible Messaging and 646 Presence Protocol (XMPP) to Common Presence and Instant 647 Messaging (CPIM)", draft-ietf-xmpp-cpim-03 (work in 648 progress), November 2003. 650 Author's Address 652 Peter Saint-Andre 653 Jabber Software Foundation 655 EMail: stpeter@jabber.org 657 Appendix A. Schema for urn:ietf:params:xml:ns:xmpp-e2e 659 The following XML schema is descriptive, not normative. 661 663 669 671 673 Appendix B. Revision History 675 Note to RFC Editor: please remove this entire appendix, and the 676 corresponding entries in the table of contents, prior to publication. 678 B.1 Changes from draft-ietf-xmpp-e2e-05 680 o Addressed I-D nits and RFC Editor formatting. 682 B.2 Changes from draft-ietf-xmpp-e2e-04 684 o Added text about instant inbox addresses. 686 B.3 Changes from draft-ietf-xmpp-e2e-03 688 o Specified that S/MIME multipart objects are enclosed in a CDATA 689 section. 691 o Changed "text/xml" to "text/plain" for message examples. 693 o Specified must-implement technologies, transfer encodings, 694 certificate enrollment, certificate retrieval, and certificate 695 names (including subjectAltName for JIDs). 697 o Specified requirements regarding attachment of signatures and 698 inclusion of certificates. 700 o Fixed some small terminological errors. 702 B.4 Changes from draft-ietf-xmpp-e2e-02 704 o Completely revised to use formats defined in the CPIM 705 specifications. 707 B.5 Changes from draft-ietf-xmpp-e2e-01 709 o Removed old Section 6 (Signalling Support via Presence) -- the 710 ability to sign broadcasted presence made it redundant. 712 o Made small editorial changes to address RFC Editor requirements. 714 B.6 Changes from draft-ietf-xmpp-e2e-00 716 o Added support for all stanza types. 718 o Specified that the full stanza is encrypted. 720 o Added support for S/MIME in addition to OpenPGP. 722 o Specified that encrypted presence must be directed to a specific 723 recipient. 725 o Specified order of encrypting and signing. 727 o Added support for signing broadcasted presence. 729 o Added IANA considerations. 731 o Changed namespace to 'urn:ietf:params:xml:ns:xmpp-e2e'. 733 o Added XML schema. 735 Intellectual Property Statement 737 The IETF takes no position regarding the validity or scope of any 738 intellectual property or other rights that might be claimed to 739 pertain to the implementation or use of the technology described in 740 this document or the extent to which any license under such rights 741 might or might not be available; neither does it represent that it 742 has made any effort to identify any such rights. Information on the 743 IETF's procedures with respect to rights in standards-track and 744 standards-related documentation can be found in BCP-11. Copies of 745 claims of rights made available for publication and any assurances of 746 licenses to be made available, or the result of an attempt made to 747 obtain a general license or permission for the use of such 748 proprietary rights by implementors or users of this specification can 749 be obtained from the IETF Secretariat. 751 The IETF invites any interested party to bring to its attention any 752 copyrights, patents or patent applications, or other proprietary 753 rights which may cover technology that may be required to practice 754 this standard. Please address the information to the IETF Executive 755 Director. 757 Full Copyright Statement 759 Copyright (C) The Internet Society (2003). All Rights Reserved. 761 This document and translations of it may be copied and furnished to 762 others, and derivative works that comment on or otherwise explain it 763 or assist in its implementation may be prepared, copied, published 764 and distributed, in whole or in part, without restriction of any 765 kind, provided that the above copyright notice and this paragraph are 766 included on all such copies and derivative works. However, this 767 document itself may not be modified in any way, such as by removing 768 the copyright notice or references to the Internet Society or other 769 Internet organizations, except as needed for the purpose of 770 developing Internet standards in which case the procedures for 771 copyrights defined in the Internet Standards process must be 772 followed, or as required to translate it into languages other than 773 English. 775 The limited permissions granted above are perpetual and will not be 776 revoked by the Internet Society or its successors or assignees. 778 This document and the information contained herein is provided on an 779 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 780 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 781 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 782 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 783 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 785 Acknowledgment 787 Funding for the RFC Editor function is currently provided by the 788 Internet Society.