idnits 2.17.1 draft-ietf-xmpp-e2e-04.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 (June 29, 2003) is 7605 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) -- Looks like a reference, but probably isn't: 'RFCXXXX' on line 568 == Outdated reference: A later version (-24) exists of draft-ietf-xmpp-core-15 == Outdated reference: A later version (-22) exists of draft-ietf-xmpp-im-14 ** Downref: Normative reference to an Informational RFC: RFC 2779 (ref. '3') ** Obsolete normative reference: RFC 2633 (ref. '4') (Obsoleted by RFC 3851) ** Downref: Normative reference to an Informational RFC: RFC 2778 (ref. '5') ** Obsolete normative reference: RFC 3369 (ref. '6') (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 ** Obsolete normative reference: RFC 2632 (ref. '14') (Obsoleted by RFC 3850) Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Saint-Andre 3 Internet-Draft Jabber Software Foundation 4 Expires: December 28, 2003 June 29, 2003 6 End-to-End Object Encryption in XMPP 7 draft-ietf-xmpp-e2e-04 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 December 28, 2003. 31 Copyright Notice 33 Copyright (C) The Internet Society (2003). All Rights Reserved. 35 Abstract 37 This document 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 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 44 1.2 Discussion Venue . . . . . . . . . . . . . . . . . . . . . . . 3 45 1.3 Intellectual Property Notice . . . . . . . . . . . . . . . . . 3 46 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 47 3. Securing Messages . . . . . . . . . . . . . . . . . . . . . . 6 48 4. Securing Presence . . . . . . . . . . . . . . . . . . . . . . 8 49 5. Securing Arbitrary XMPP Data . . . . . . . . . . . . . . . . . 10 50 6. Rules for S/MIME Generation and Handling . . . . . . . . . . . 12 51 6.1 Certificate Enrollment . . . . . . . . . . . . . . . . . . . . 12 52 6.2 Certificate Retrieval . . . . . . . . . . . . . . . . . . . . 12 53 6.3 Certificate Names . . . . . . . . . . . . . . . . . . . . . . 12 54 6.4 Transfer Encoding . . . . . . . . . . . . . . . . . . . . . . 13 55 6.5 Attachment of Signatures . . . . . . . . . . . . . . . . . . . 13 56 6.6 Inclusion of Certificates . . . . . . . . . . . . . . . . . . 13 57 6.7 Mandatory to Implement Technologies . . . . . . . . . . . . . 13 58 7. Secure Communications Through a Gateway . . . . . . . . . . . 14 59 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 60 8.1 Content-type Registration for "application/xmpp+xml" . . . . . 15 61 8.2 XML Namespace Name for e2e Data in XMPP . . . . . . . . . . . 15 62 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 63 Normative References . . . . . . . . . . . . . . . . . . . . . 18 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19 65 A. Schema for urn:ietf:params:xml:ns:xmpp-e2e . . . . . . . . . . 20 66 B. Revision History . . . . . . . . . . . . . . . . . . . . . . . 21 67 B.1 Changes from draft-ietf-xmpp-e2e-03 . . . . . . . . . . . . . 21 68 B.2 Changes from draft-ietf-xmpp-e2e-02 . . . . . . . . . . . . . 21 69 B.3 Changes from draft-ietf-xmpp-e2e-01 . . . . . . . . . . . . . 21 70 B.4 Changes from draft-ietf-xmpp-e2e-00 . . . . . . . . . . . . . 21 71 Intellectual Property and Copyright Statements . . . . . . . . 23 73 1. Introduction 75 This document define a method for end-to-end signing and encryption 76 in the Extensible Messaging and Presence Protocol (XMPP). (For 77 information about XMPP, see XMPP Core [1] and XMPP IM [2].) The 78 method defined herein enables a sender to encrypt and/or sign an 79 instant message sent to a specific recipient, encrypt and/or sign 80 presence information that is directed to a specific user, and sign 81 presence information that is broadcasted to a specific user. This 82 document thereby helps the XMPP specifications meet the requirements 83 defined in RFC 2779 [3]. 85 1.1 Terminology 87 This document inherits terminology defined in RFC 2633 [4], RFC 2778 88 [5], RFC 3369 [6], and XMPP Core [1]. 90 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 91 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 92 "OPTIONAL" in this document are to be interpreted as described in RFC 93 2119 [7]. 95 1.2 Discussion Venue 97 The authors welcome discussion and comments related to the topics 98 presented in this document. The preferred forum is the 99 mailing list, for which archives and subscription 100 information are available at . 103 1.3 Intellectual Property Notice 105 This document is in full compliance with all provisions of Section 10 106 of RFC 2026. Parts of this specification use the term "jabber" for 107 identifying namespaces and other protocol syntax. Jabber[tm] is a 108 registered trademark of Jabber, Inc. Jabber, Inc. grants permission 109 to the IETF for use of the Jabber trademark in association with this 110 specification and its successors, if any. 112 2. Requirements 114 For the purposes of this document, we stipulate the following 115 requirements: 117 1. The method defined MUST address encryption and signing 118 requirements for minimal instant messaging and presence only, as 119 those are defined in RFC 2779 [3]. The method is NOT REQUIRED to 120 support non-IM applications of XMPP, nor to support advanced 121 instant messaging and presence functionality that is outside the 122 scope of RFC 2799. In particular, the method MUST address the 123 following requirements defined in RFC 2779: 125 * The protocol MUST provide means to ensure confidence that a 126 received message (NOTIFICATION or INSTANT MESSAGE) has not 127 been corrupted or tampered with. (Section 2.5.1) 129 * The protocol MUST provide means to ensure confidence that a 130 received message (NOTIFICATION or INSTANT MESSAGE) has not 131 been recorded and played back by an adversary. (Section 2.5.2) 133 * The protocol MUST provide means to ensure that a sent message 134 (NOTIFICATION or INSTANT MESSAGE) is only readable by ENTITIES 135 that the sender allows. (Section 2.5.3) 137 * The protocol MUST allow any client to use the means to ensure 138 non-corruption, non-playback, and privacy, but the protocol 139 MUST NOT require that all clients use these means at all 140 times. (Section 2.5.4) 142 * When A establishes a SUBSCRIPTION to B's PRESENCE INFORMATION, 143 the protocol MUST provide A means of verifying the accurate 144 receipt of the content B chooses to disclose to A. (Section 145 5.1.4) 147 * The protocol MUST provide A means of verifying that the 148 presence information is accurate, as sent by B. (Section 149 5.3.1) 151 * The protocol MUST provide A means of ensuring that no other 152 PRINCIPAL C can see the content of M. (Section 5.4.6) 154 * The protocol MUST provide A means of ensuring that no other 155 PRINCIPAL C can tamper with M, and B means to verify that no 156 tampering has occurred. (Section 5.4.7) 158 2. The method defined MUST enable interoperability with non-XMPP 159 messaging systems that support the Common Presence and Instant 160 Messaging (CPIM) specifications defined by the Instant Messaging 161 and Presence (IMPP) Working Group. Therefore: 163 * Prior to encrypting or signing, the format of an instant 164 message must conform to the CPIM Message Format defined in 165 MSGFMT [8]. 167 * Prior to encrypting or signing, the format of presence 168 information must conform to the CPP Presence Information Data 169 Format defined in PIDF [9]. 171 3. The method MUST follow the required procedures (including the 172 specific algorithms) defined in Common Profile for Instant 173 Messaging [10] and Common Profile for Presence [11]. In 174 particular, these documents specify: 176 * Encryption MUST use S/MIME [4] encryption with CMS [6] 177 EnvelopeData. 179 * Signing MUST use S/MIME [4] signatures with CMS [6] 180 SignedData. 182 4. In order to enable interoperable implementations, sending and 183 receiving applications MUST implement the algorithms defined 184 under Section 6.7. 186 3. Securing Messages 188 In order to encrypt a message, a sending entity MUST use the 189 following procedure: 191 1. Generate a "Message/CPIM" object as defined in MSGFMT [8]. 193 2. Encrypt and/or sign both the headers and content of the "Message/ 194 CPIM" object as specified in Requirement 3 of Section 2 above. 196 3. Provide the resulting multipart S/MIME object (see RFC 1847 [12]) 197 as the CDATA of an child of a stanza, with the 198 element scoped by the 'urn:ietf:params:xml:ns:xmpp-e2e' 199 namespace (note that this namespace name adheres to the format 200 defined in The IANA XML Registry [13]). 202 Example 1: Sender generates "Message/CPIM" object: 204 Content-type: Message/CPIM 206 From: Juliet Capulet 207 To: Romeo Montague 208 DateTime: 2003-05-14T11:45:36Z 209 Subject: Imploring 211 Content-type: text/plain; charset=utf-8 212 Content-ID: <1234567890@capulet.com> 214 Wherefore art thou, Romeo? 215 Example 2: Sender generates signed message (the 'from' address on the 216 XMPP message stanza is stamped by sender's server): 218 219 220 229 To: Romeo Montague 230 DateTime: 2003-05-14T23:45:36Z 231 Subject: Imploring 233 Content-type: text/plain; charset=utf-8 234 Content-ID: <1234567890@capulet.com> 236 Wherefore art thou, Romeo? 237 --next 238 Content-Type: application/pkcs7-signature 240 [signed body part] 242 --next-- 243 ]]> 244 245 247 4. Securing Presence 249 In order to encrypt presence information, a sending entity MUST use 250 the following procedure: 252 1. Generate an "application/pidf+xml" object as defined in PIDF [9]. 254 2. Encrypt and/or sign the "application/pidf+xml" object as 255 specified in Requirement 3 of Section 2 above. 257 3. Provide the resulting S/MIME object as the CDATA of an 258 child of a stanza, with the element scoped by 259 the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace (note that this 260 namespace name adheres to the format defined in The IANA XML 261 Registry [13]). The stanza MUST include a 'to' 262 attribute, i.e., it must be an instance of directed presence as 263 defined in XMPP IM [2]. 265 Example 3: Sender generates "application/pidf+xml" object: 267 268 271 273 open 274 away 275 276 retired to the chamber 277 2003-05-14T23:53:11Z 278 279 280 Example 4: Sender generates signed presence (the 'from' address on 281 the XMPP presence stanza is stamped by sender's server): 283 284 285 294 295 298 300 open 301 away 302 303 retired to the chamber 304 2003-05-14T23:53:11Z 305 306 307 --next 308 Content-Type: application/pkcs7-signature 310 [signed body part] 312 --next-- 313 ]]> 314 315 317 5. Securing Arbitrary XMPP Data 319 The foregoing sections of this document describe how to secure "least 320 common denominator" messaging and presence data of the kind that can 321 be directly translated into the MSGFMT or PIDF formats. However, XMPP 322 possesses a third base-level stanza type () in addition to 323 and , as well as the ability to include 324 extended XML data within arbitrary child elements of the three core 325 stanza types. Therefore it would be desirable to secure such data if 326 possible. 328 Because MSGFMT [8] specifies the ability to encapsulate any MIME 329 type, the approach taken in this document is to include arbitrary 330 XMPP data in a new MIME type, "application/xmpp+xml". The root 331 element for this MIME type is , and the root element MUST 332 contain one and only one child element, corresponding to one of the 333 XMPP stanza types (i.e., message, presence, or iq) if the default 334 namespace is 'jabber:client' or 'jabber:server' as defined in XMPP 335 Core [1]. 337 The following examples illustrate the structure of the "application/ 338 xmpp+xml" MIME type. 340 Example 5: Message stanza with extended data contained in 341 "application/xmpp+xml" MIME type: 343 344 345 348 349 I told him what I thought, and told no more 350 Than what he found himself was apt and true. 351 352 353 354 355 Example 6: Presence stanza with extended data contained in 356 "application/xmpp+xml" MIME type: 358 359 360 361 dnd 362 Fomenting dissension 363 364 365 367 Example 7: IQ stanza with extended data contained in "application/ 368 xmpp+xml" MIME type: 370 371 372 376 377 Stabber 378 666 379 FiendOS 380 381 382 383 385 6. Rules for S/MIME Generation and Handling 387 6.1 Certificate Enrollment 389 S/MIME v3 does not specify how to obtain a certificate from a 390 certificate authority, but instead mandates that every sending agent 391 must already have a certificate. The PKIX Working Group has, at the 392 time of this writing, produced two separate standards for certificate 393 enrollment: CMP (RFC 2510) and CMC (RFC 2792). Which method to use 394 for certificate enrollment is outside the scope of this document. 396 6.2 Certificate Retrieval 398 A receiving agent MUST provide some certificate retrieval mechanism 399 in order to gain access to certificates for recipients of digital 400 envelopes. This document does not cover how S/MIME agents handle 401 certificates, only what they do after a certificate has been 402 validated or rejected. S/MIME certification issues are covered in RFC 403 2632 [14]. 405 At a minimum, for initial S/MIME deployment, a user agent could 406 automatically generate a message to an intended recipient requesting 407 that recipient's certificate in a signed return message. Receiving 408 and sending agents SHOULD also provide a mechanism to allow a user to 409 "store and protect" certificates for correspondents in such a way so 410 as to guarantee their later retrieval. 412 6.3 Certificate Names 414 End-entity certificates used in the context of this document SHOULD 415 contain a XMPP address as described in XMPP Core [1]. The address 416 SHOULD be in the form of a "bare JID", i.e., , although 417 any valid JID form MAY be used. The JID SHOULD be in the 418 subjectAltName extension, and SHOULD NOT be in the subject 419 distinguished name. 421 The value of the JID contained in the XMPP 'from' attribute SHOULD 422 match the JID provided in the signer's certificate, with the 423 exception that the resource identifier portion of the JID contained 424 in the 'from' attribute MAY be ignored for matching purposes. 426 Receiving agents MUST recognize XMPP addresses (JIDs) in the 427 subjectAltName field. 429 Receiving agents SHOULD check that sending JID matches a JID provided 430 in the signer's certificate, with the exception that the resource 431 identifier portion of the JID contained in the 'from' attribute MAY 432 be ignored for matching purposes. A receiving agent SHOULD provide 433 some explicit alternate processing of the message if this comparison 434 fails, which may be to display a message that shows the recipient the 435 addresses in the certificate or other certificate details. 437 The subject alternative name extension is used in S/MIME as the 438 preferred means to convey the JID that corresponds to the entity for 439 this certificate. Any JIDs present SHOULD be encoded using the 440 otherName CHOICE of the subjectAltName type, where the type-id is 441 "xmpp" and the value is the bare JID of the entity. 443 6.4 Transfer Encoding 445 According to various S/MIME specifications for message wrapping, CMS 446 objects MAY optionally be wrapped in MIME to dynamically support 447 7-bit transport. Because it is expected that XMPP will not be used to 448 interface with older 7-bit systems, this outer wrapping is NOT 449 REQUIRED for XMPP transport, and generally SHOULD NOT be applied in a 450 homogeneous XMPP environment or in an environment that supports 451 XMPP-CPIM gateways. 453 6.5 Attachment of Signatures 455 Sending agents SHOULD attach a signature to each encrypted message or 456 presence stanza, but are NOT REQUIRED to do so. 458 6.6 Inclusion of Certificates 460 Sending agents are NOT REQUIRED to include the sender's certificate 461 along with each encrypted message or presence stanza. 463 6.7 Mandatory to Implement Technologies 465 At a minimum, all implementations MUST support the following CMS 466 algorithms as defined in RFC 3370 [15]: 468 for digest: DIGEST-MD5 470 for signing: RSA 472 for content encryption: Triple-DES CBC 474 7. Secure Communications Through a Gateway 476 A common method for achieving interoperability between two disparate 477 services is through the use of a "gateway" that interprets the 478 protocols of each service and translates them into the protocols of 479 the other. The CPIM specifications (specifically MSGFMT [8] and PIDF 480 [9] define the common profiles to be used for interoperability 481 between instant messaging and presence services that comply with RFC 482 2779 [3]. In the case of communications between an XMPP service and a 483 non-XMPP service, we can visualize this relationship as follows: 485 +-------------+ +-------------+ +------------+ 486 | | | | | | 487 | XMPP | | XMPP-CPIM | | Non-XMPP | 488 | Service | <----> | Gateway | <----> | Service | 489 | | | | | | 490 +-------------+ +-------------+ +------------+ 492 The end-to-end encryption method defined herein enables the exchange 493 of encrypted and/or signed instant messages and presence through an 494 XMPP-CPIM gateways. In particular: 496 o When a gateway receives a secured XMPP message or presence stanza 497 from the XMPP service that is addressed to a user on the non-XMPP 498 service, it MUST remove the XMPP "wrapper" (everything down to and 499 including the and tags) in order to reveal the 500 multipart S/MIME object, then route the object to the non-XMPP 501 service (first wrapping it in the protocol used by the non-XMPP 502 service if necessary). 504 o When a gateway receives a secured non-XMPP instant message or 505 presence document from the non-XMPP service that is addressed to a 506 user on the XMPP service, it MUST remove the non-XMPP "wrapper" 507 (if any) in order to reveal the multipart S/MIME object, wrap the 508 object in an XMPP message or presence "wrapper" (including the 509 and tags), and then route the XMPP stanza to the XMPP 510 service. 512 The wrapped S/MIME object MUST be immutable and MUST NOT be modified 513 by an XMPP-CPIM gateway. 515 8. IANA Considerations 517 8.1 Content-type Registration for "application/xmpp+xml" 519 To: ietf-types@iana.org 521 Subject: Registration of MIME media type application/xmpp+xml 523 MIME media type name: application 525 MIME subtype name: xmpp+xml 527 Required parameters: (none) 529 Optional parameters: charset Indicates the character encoding of the 530 enclosed XML; the default encoding is UTF-8. 532 Encoding considerations: Contains XML, which can employ 8-bit 533 characters, depending on the character encoding used. 535 Security considerations: Contains a message, presence information, or 536 IQ (request-response) data in XMPP, which may be considered 537 private. Appropriate precautions should be adopted to limit 538 disclosure of this information. 540 Interoperability considerations: (none) 542 Specification: [RFCXXXX] 544 Applications which use this media type: XMPP-compliant instant 545 messaging and presence systems. 547 Additional information: (none) 549 Person and email address to contact for further information: IETF, 550 XMPP Working Group, 552 Intended usage: COMMON 554 Author/Change controller: IETF, XMPP Working Group 556 8.2 XML Namespace Name for e2e Data in XMPP 558 A URN sub-namespace for signed and encrypted content in the 559 Extensible Messaging and Presence Protocol (XMPP) is defined as 560 follows. 562 URI: urn:ietf:params:xml:ns:xmpp-e2e 564 Specification: [RFCXXXX] 566 Description: This is the XML namespace name for signed and encrypted 567 content in the Extensible Messaging and Presence Protocol as 568 defined by [RFCXXXX]. 570 Registrant Contact: IETF, XMPP Working Group, 572 9. Security Considerations 574 This entire document discusses security. Detailed security 575 considerations for instant messaging and presence protocols are given 576 in RFC 2779 [3] (Sections 5.1 through 5.4), and for XMPP in 577 particular are given in XMPP Core [1] (Sections 12.1 through 12.6). 579 The end-to-end security method defined here MAY result in exchanging 580 secured instant messages and presence information through a gateway 581 that implements the CPIM specifications. Such a gateway MUST be 582 compliant with the minimum security requirements of the instant 583 messaging and presence protocols with which it interfaces. 585 Normative References 587 [1] Saint-Andre, P. and J. Miller, "XMPP Core", 588 draft-ietf-xmpp-core-15 (work in progress), June 2003. 590 [2] Saint-Andre, P. and J. Miller, "XMPP Instant Messaging", 591 draft-ietf-xmpp-im-14 (work in progress), June 2003. 593 [3] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / 594 Presence Protocol Requirements", RFC 2779, February 2000. 596 [4] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 597 2633, June 1999. 599 [5] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and 600 Instant Messaging", RFC 2778, February 2000, . 603 [6] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369, 604 August 2002. 606 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 607 Levels", BCP 14, RFC 2119, March 1997. 609 [8] Atkins, D. and G. Klyne, "Common Presence and Instant 610 Messaging: Message Format", draft-ietf-impp-cpim-msgfmt-08 611 (work in progress), January 2003. 613 [9] Fujimoto, S., Sugano, H., Klyne, G., Bateman, A., Carr, W. and 614 J. Peterson, "Presence Information Data Format", 615 draft-ietf-impp-cpim-pidf-08 (work in progress), May 2003. 617 [10] Crocker, D. and J. Peterson, "Common Profile for Instant 618 Messaging (CPIM)", draft-ietf-impp-im-03 (work in progress), 619 May 2003. 621 [11] Crocker, D. and J. Peterson, "Common Profile for Presence 622 (CPP)", draft-ietf-impp-pres-03 (work in progress), May 2003. 624 [12] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security 625 Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", 626 RFC 1847, October 1995. 628 [13] Mealling, M., "The IANA XML Registry", 629 draft-mealling-iana-xmlns-registry-05 (work in progress), June 630 2003. 632 [14] Ramsdell, B., "S/MIME Version 3 Certificate Handling", RFC 633 2632, June 1999. 635 [15] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", 636 RFC 3370, August 2002. 638 Author's Address 640 Peter Saint-Andre 641 Jabber Software Foundation 643 EMail: stpeter@jabber.org 645 Appendix A. Schema for urn:ietf:params:xml:ns:xmpp-e2e 647 The following XML schema is descriptive, not normative. 649 651 657 659 661 Appendix B. Revision History 663 Note to RFC Editor: please remove this entire appendix, and the 664 corresponding entries in the table of contents, prior to publication. 666 B.1 Changes from draft-ietf-xmpp-e2e-03 668 o Specified that S/MIME multipart objects are enclosed in a CDATA 669 section. 671 o Changed "text/xml" to "text/plain" for message examples. 673 o Specified must-implement technologies, transfer encodings, 674 certificate enrollment, certificate retrieval, and certificate 675 names (including subjectAltName for JIDs). 677 o Specified requirements regarding attachment of signatures and 678 inclusion of certificates. 680 o Fixed some small terminological errors. 682 B.2 Changes from draft-ietf-xmpp-e2e-02 684 o Completely revised to use formats defined in the CPIM 685 specifications. 687 B.3 Changes from draft-ietf-xmpp-e2e-01 689 o Removed old Section 6 (Signalling Support via Presence) -- the 690 ability to sign broadcasted presence made it redundant. 692 o Made small editorial changes to address RFC Editor requirements. 694 B.4 Changes from draft-ietf-xmpp-e2e-00 696 o Added support for all stanza types. 698 o Specified that the full stanza is encrypted. 700 o Added support for S/MIME in addition to OpenPGP. 702 o Specified that encrypted presence must be directed to a specific 703 recipient. 705 o Specified order of encrypting and signing. 707 o Added support for signing broadcasted presence. 709 o Added IANA considerations. 711 o Changed namespace to 'urn:ietf:params:xml:ns:xmpp-e2e'. 713 o Added XML schema. 715 Intellectual Property Statement 717 The IETF takes no position regarding the validity or scope of any 718 intellectual property or other rights that might be claimed to 719 pertain to the implementation or use of the technology described in 720 this document or the extent to which any license under such rights 721 might or might not be available; neither does it represent that it 722 has made any effort to identify any such rights. Information on the 723 IETF's procedures with respect to rights in standards-track and 724 standards-related documentation can be found in BCP-11. Copies of 725 claims of rights made available for publication and any assurances of 726 licenses to be made available, or the result of an attempt made to 727 obtain a general license or permission for the use of such 728 proprietary rights by implementors or users of this specification can 729 be obtained from the IETF Secretariat. 731 The IETF invites any interested party to bring to its attention any 732 copyrights, patents or patent applications, or other proprietary 733 rights which may cover technology that may be required to practice 734 this standard. Please address the information to the IETF Executive 735 Director. 737 Full Copyright Statement 739 Copyright (C) The Internet Society (2003). All Rights Reserved. 741 This document and translations of it may be copied and furnished to 742 others, and derivative works that comment on or otherwise explain it 743 or assist in its implementation may be prepared, copied, published 744 and distributed, in whole or in part, without restriction of any 745 kind, provided that the above copyright notice and this paragraph are 746 included on all such copies and derivative works. However, this 747 document itself may not be modified in any way, such as by removing 748 the copyright notice or references to the Internet Society or other 749 Internet organizations, except as needed for the purpose of 750 developing Internet standards in which case the procedures for 751 copyrights defined in the Internet Standards process must be 752 followed, or as required to translate it into languages other than 753 English. 755 The limited permissions granted above are perpetual and will not be 756 revoked by the Internet Society or its successors or assignees. 758 This document and the information contained herein is provided on an 759 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 760 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 761 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 762 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 763 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 765 Acknowledgement 767 Funding for the RFC Editor function is currently provided by the 768 Internet Society.