Network Working Group                                     P. Saint-Andre
Internet-Draft                                Jabber Software Foundation
Expires: October 20, November 18, 2003                                  J. Hildebrand
                                                            Jabber, Inc.
                                                          April 21,                                  May 20, 2003

                  End-to-End Object Encryption in XMPP

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-
   Drafts. Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on October 20, November 18, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2003). All Rights Reserved.


   This document describes an defines a method for end-to-end object signing and
   method for use in the Extensible Messaging and Presence Protocol (XMPP).

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.1 Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.2 Discussion Venue . . . . . . . . . . . . . . . . . . . . . . .  3
   1.3 Intellectual Property Notice . . . . . . . . . . . . . . . . .  3
   2.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Encrypting Stanzas . . . . . . . . . . . . . . . . . . . . . .  5
   3.1 General Syntax . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.2 Encrypting  Securing Messages  . . . . . . . . . . . . . . . . . . . . . .  6
   3.3 Encrypting
   4.  Securing Presence  . . . . . . . . . . . . . . . . . . . . .  7
   3.4 Encrypting IQs . . . . . . . . . . . . . . . . . . . . . . . .  8
   4.  Signing Encrypted Content  . . . . . . . . . . . . . . . . . .  9
   5.  Signing Broadcasted Presence . . . . . .  Secure Communications Through a Gateway  . . . . . . . . . . . 10
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
       Normative References . . . . . . . . . . . . . . . . . . . . . 13
       Informative References . . . . . . . .
       Author's Address . . . . . . . . . . . . 14
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
   A.  XML Schemas  . . . . . . . . . . . . . . . . . . . . . . . . . 15
   A.1  Schema for urn:ietf:params:xml:ns:xmpp-e2e . . . . . . . . . . . . . . . 15
   A.2 urn:ietf:params:xml:ns:xmpp-e2e#payload  . . . . . . . . . . . 16
   B.  Revision History . . . . . . . . . . . . . . . . . . . . . . . 17 16
   B.1 Changes from draft-ietf-xmpp-e2e-01 draft-ietf-xmpp-e2e-02  . . . . . . . . . . . . . 17 16
   B.2 Changes from draft-ietf-xmpp-e2e-00 draft-ietf-xmpp-e2e-01  . . . . . . . . . . . . . 17
       Full Copyright Statement 16
   B.3 Changes from draft-ietf-xmpp-e2e-00  . . . . . . . . . . . . . 16
       Intellectual Property and Copyright Statements . . . . . . . . 18 17

1. Introduction

   This document describes an define a method for end-to-end signing and encryption method
   for use
   in the Extensible Messaging and Presence Protocol (XMPP) as
   defined by (XMPP). (For
   information about XMPP, see XMPP Core [1] and XMPP IM [2].  Object signing and
   encryption enable [2].) The
   method defined herein enables a sender to encrypt and/or sign an XML stanza
   instant message sent to a specific recipient, encrypt and/or sign such
   presence information that is directed to a stanza, specific user, and sign
   presence information that is broadcasted presence,
   and signal support for the method defined herein. to a specific user. This
   document thereby helps the XMPP specifications meet the requirements
   defined in RFC 2779 [6]. [3].

1.1 Terminology

   This document inherits the terminology defined in XMPP Core [1]. [1] and RFC
   2778 [4].

   The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
   "OPTIONAL" in this document are to be interpreted as described in RFC
   2119 [3]. [5].

1.2 Discussion Venue

   The authors welcome discussion and comments related to the topics
   presented in this document. The preferred forum is the
   <> mailing list, for which archives and subscription
   information are available at <

1.3 Intellectual Property Notice

   This document is in full compliance with all provisions of Section 10
   of RFC 2026. Parts of this specification use the term "jabber" for
   identifying namespaces and other protocol syntax. Jabber[tm] is a
   registered trademark of Jabber, Inc.  Jabber, Inc. grants permission
   to the IETF for use of the Jabber trademark in association with this
   specification and its successors, if any.

2. Requirements

   For the purposes of this document, we stipulate the following

   1.  Encryption must work with any stanza type (message, presence, or

   2.  The full XML stanza must be encrypted.

   3.  Encryption must be possible using either OpenPGP [4] or S/MIME

   4.  It must be possible to sign encrypted content.

   5.  It must be possible method defined MUST address encryption and signing
       requirements for minimal instant messaging and presence only, as
       those are defined in RFC 2779 [3]. The method is NOT REQUIRED to sign broadcasted presence.

   6.  Any namespaces used must conform
       support non-IM applications of XMPP, nor to support advanced
       instant messaging and presence functionality that is outside the
       scope of RFC 2799. In particular, the method MUST address the
       following requirements defined in RFC 2779:

       *  The IETF XML Registry [7].

3. Encrypting Stanzas

3.1 General Syntax

   Any stanza MAY be encrypted.  The full stanza protocol MUST be inserted as provide means to ensure confidence that a
   direct child of
          received message (NOTIFICATION or INSTANT MESSAGE) has not
          been corrupted or tampered with. (Section 2.5.1)

       *  The protocol MUST provide means to ensure confidence that a <payload/> element scoped
          received message (NOTIFICATION or INSTANT MESSAGE) has not
          been recorded and played back by the
   'urn:ietf:params:xml:ns:xmpp-e2e#payload' namespace. an adversary. (Section 2.5.2)

       *  The stanza data protocol MUST be preceded provide means to ensure that a sent message
          (NOTIFICATION or INSTANT MESSAGE) is only readable by another direct child of ENTITIES
          that the <payload/> element,
   namely an <id/> element. sender allows. (Section 2.5.3)

       *  The CDATA of the <id/> element protocol MUST be
   constructed according allow any client to use the following algorithm:

   1.  concatenate the sender's full JID (user@host/resource) with the
       recipient's full JID

   2.  concatenate means to ensure
          non-corruption, non-playback, and privacy, but the resulting string with protocol
          MUST NOT require that all clients use these means at all
          times. (Section 2.5.4)

       *  When A establishes a full ISO-8601 UTC
       timestamp including year, month, day, hours, minutes, seconds in
       the following format: yyyy-mm-dd-Thh:mm:ssZ (the timestamp must
       be UTC, no offsets are allowed)

   3.  hash the resulting string according SUBSCRIPTION to B's PRESENCE INFORMATION,
          the SHA1 algorithm

   4.  convert protocol MUST provide A means of verifying the hexidecimal SHA1 output to all lowercase.

   Before encryption, accurate
          receipt of the XML content B chooses to be encrypted will thus be disclose to A. (Section

       *  The protocol MUST provide A means of verifying that the
   following form:

   <payload xmlns='urn:ietf:params:xml:ns:xmpp-e2e#payload'>
          presence information is accurate, as sent by B. (Section

       *  The full <payload/> element (including all XML tag names and angle
   brackets) protocol MUST then be encrypted using either OpenPGP or S/MIME. provide A means of ensuring that no other
          PRINCIPAL C can see the content of M. (Section 5.4.6)

       *  The
   output protocol MUST be armored US-ASCII provide A means of ensuring that no other
          PRINCIPAL C can tamper with any headers removed.  The
   resulting cipher text M, and B means to verify that no
          tampering has occurred. (Section 5.4.7)

   2.  The method defined MUST then be provided enable interoperability with non-XMPP
       messaging systems that support Common Presence and Instant
       Messaging (CPIM) as defined by the CDATA of Instant Messaging and Presence
       (IMPP) Working Group. Therefore:

       *  Prior to encrypting or signing, the
   <stanza/> child format of an <x/> element scoped by instant
          message must conform to the
   'urn:ietf:params:xml:ns:xmpp-e2e' namespace, with CPIM Message Format defined in
          MSGFMT [6].

       *  Prior to encrypting or signing, the value format of the
   'type' attribute set presence
          information must conform to either "openpgp" or "smime" depending on
   which the CPIM Presence Information Data
          Format defined in PIDF [7].

   3.  The method was used. MUST follow the procedures (including the specific
       algorithms) defined in Common Profile for Instant Messaging [8]
       and Common Profile for Presence [9]. In particular, these
       documents specify:

       *  Encryption MUST use S/MIME [10] encryption with CMS [11]

       *  Signing MUST use S/MIME [10] signatures with CMS [11]

       *  The format of S/MIME algorithm SHOULD be AES [12].

3. Securing Messages

   In order to encrypt a message, a sending entity MUST use the stanza that results from
   following procedure:

   1.  Generate a "Message/CPIM" object as defined in MSGFMT [6].

   2.  Encrypt and/or sign both the foregoing procedure is headers and content of the "Message/
       CPIM" object as follows (no 'from' address is included specified in Requirement 3 of Section 2 above.

   3.  Provide the stanza to be
   encrypted, since that is stamped resulting multipart S/MIME object (see RFC 1847 [13])
       as the CDATA of an <e2e/> child of a <message/> stanza, with the
       <e2e/> element scoped by the sender's server):

       type='[value if provided]'
       id='[value if provided]'
       xml:lang='[value if provided]'>
     <x type='[openpgp|smime]'
         [encrypted content]

3.2 Encrypting Messages

   Message stanzas may be encrypted using 'urn:ietf:params:xml:ns:xmpp-e2e'
       namespace (note that this namespace name adheres to the syntax format
       defined above.

   Example: in The IANA XML Registry [14]).

   Example 1: Sender generates encrypted "Message/CPIM" object:

   Content-type: Message/CPIM

   From: Juliet Capulet <>
   To: Romeo Montague <>
   DateTime: 2003-05-14T11:45:36Z
   Subject: Imploring

   Content-type: text/xml; charset=utf-8
   Content-ID: <>

   Wherefore art thou, Romeo?
   Example 2: Sender generates signed message ('from' (the 'from' address on the
   XMPP message stanza is stamped by sender's server):

   <message to='' type='chat'>
     <x type='openpgp'
     <e2e xmlns='urn:ietf:params:xml:ns:xmpp-e2e'>

   The decoded payload is:

   <payload xmlns='urn:ietf:params:xml:ns:xmpp-e2e#payload'>
       <body>O Romeo, Romeo!
   Content-Type: multipart/signed; boundary=next;

   Content-type: Message/CPIM

   From: Juliet Capulet <>
   To: Romeo Montague <>
   DateTime: 2003-05-14T23:45:36Z
   Subject: Imploring

   Content-type: text/xml; charset=utf-8
   Content-ID: <>

   Wherefore art thou Romeo?</body> thou, Romeo?
   Content-Type: application/pkcs7-signature

   [signed body part]


3.3 Encrypting Presence

4. Securing Presence stanzas may be encrypted using the syntax defined above.  An

   In order to encrypt presence stanza information, a sending entity MUST be use
   the following procedure:

   1.  Generate an instance "application/cpim-pidf+xml" object defined in PIDF

   2.  Encrypt and/or sign the "application/cpim-pidf+xml" object as
       specified in Requirement 3 of directed presence;
   i.e., Section 2 above.

   3.  Provide the resulting S/MIME object as the CDATA of an <e2e/>
       child of a <presence/> stanza, with the <e2e/> element MUST possess a 'to' attribute
   specifying a specific intended recipient.  Presence information scoped by
       the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace (note that
   is intended for broadcasting this
       namespace name adheres to all subscribers the format defined in The IANA XML
       Registry [14]). The <presence/> stanza MUST NOT include a 'to'
       attribute, i.e., it must be

   Example: an instance of directed presence as
       defined in XMPP IM [2].

   Example 3: Sender generates "application/cpim-pidf+xml" object:

   Content-type: application/cpim-pidf+xml

   From: Juliet Capulet <>
   To: Romeo Montague <>
   DateTime: 2003-05-14T23:53:11Z

   Content-type: text/xml; charset=utf-8
   Content-ID: <>

   <?xml version="1.0" encoding="UTF-8"?>
   <presence xmlns="urn:ietf:params:xml:ns:pidf"
     <tuple id="h40zny"
       <note xml:lang="en">retired to the chamber</note>

   Example 4: Sender generates encrypted signed presence ('from' (the 'from' address on
   the XMPP presence stanza is stamped by sender's server):

   <presence to=''>
     <x type='openpgp'
     <e2e xmlns='urn:ietf:params:xml:ns:xmpp-e2e'>

   The decoded payload is:

   <payload xmlns='urn:ietf:params:xml:ns:xmpp-e2e#payload'>
   Content-Type: multipart/signed; boundary=next;

   Content-type: application/cpim-pid+xml

   From: Juliet Capulet <>
   To: Romeo Montague <>
   DateTime: 2003-05-14T23:53:11Z

   Content-type: text/xml; charset=utf-8
   Content-ID: <>

   <?xml version="1.0" encoding="UTF-8"?>
   <presence to=''>
       <status>retired to the chamber</status> xmlns="urn:ietf:params:xml:ns:pidf"
     <tuple id="h40zny"
       <note xml:lang="en">retired to the chamber</note>

3.4 Encrypting IQs

   IQ stanzas may be encrypted using the syntax defined above.

   Example: Sender generates encrypted IQ ('from' address
   Content-Type: application/pkcs7-signature

   [signed body part]


5. Secure Communications Through a Gateway

   A common method for achieving interoperability between two disparate
   services is stamped by
   sender's server):

   <iq to='' type='get' id='eq7-2521'>
     <x type='openpgp' xmlns='urn:ietf:params:xml:ns:xmpp-e2e'>

   The decoded payload is:

   <payload xmlns='urn:ietf:params:xml:ns:xmpp-e2e#payload'>
     <iq to='' type='get' id='eq7-2521'>
       <query xmlns='jabber:iq:version'/>

4. Signing Encrypted Content

   OpenPGP and S/MIME both allow an entity to either encrypt then sign,
   or sign then encrypt.  When signing first, the signatories are
   obscured by the encryption; when encrypting first, the signatories
   are exposed but through the signatures can be verified without decrypting.
   Because in XMPP use of a "gateway" that interprets the signatories are exposed by
   protocols of each service and translates them into the very act protocols of
   exchanging a stanza (since
   the 'from' other. CPIM [8] and 'to' addresses must CPP [9] define the common profiles to be
   exposed used
   for routing purposes), there would be no use in signing first interoperability between instant messaging and encrypting second.  Therefore, if signing is desired, it SHOULD
   be performed after encrypting.

5. Signing Broadcasted Presence

   An entity may want to sign presence information for broadcasting to
   all subscribers (i.e., services
   that comply with RFC 2779 [3]. In the presence stanza is not directed to case of communications between
   an XMPP service and a
   particular recipient, but is sent to all other entites that that have
   subscribed to non-XMPP service, we can visualize this
   relationship as follows:

   +-------------+         +-------------+         +-------------+
   |             |         |             |         |             |
   |    XMPP     |         |  CPIM/CPP   |         |  Non-XMPP   |
   |   Service   | <---->  |  Gateway    | <---->  |  Service    |
   |             |         |             |         |             |
   +-------------+         +-------------+         +-------------+

   The end-to-end encryption method defined herein enables the sender's presence).  Because exchange
   of encrypted and/or signed instant messages and presence
   MUST be directed to through
   CPIM/CPP gateways. In particular:

   o  When a particular recipient, signed gateway receives a secured XMPP message or presence for
   broadcasting MUST NOT be encrypted, only signed.  However, there is
   little stanza
      from the XMPP service that addressed to no value in signing a user on the entire stanza; therefore non-XMPP
      service, it is
   enough MUST remove the XMPP "wrapper" (everything down to sign only and
      including the user-provided CDATA of <e2e> and </e2e> tags) in order to reveal the <status/> element
   (note that this requires a signed presence broadcast
      multipart S/MIME object, then route the object to include some
   CDATA the non-XMPP
      service (first wrapping it in the <status/> element).  The process is as follows:

   1.  User provides CDATA for protocol used by the <status/> element.

   2.  Client application signs CDATA using OpenPGP non-XMPP
      service if necessary).

   o  When a gateway receives a secured non-XMPP instant message or S/MIME.

   3.  Client application inserts signed ASCII output as CDATA of the
       <signed/> child of an <x/> element that is scoped by
      presence document from the
       'urn:ietf:params:xml:ns:xmpp-e2e' namespace and non-XMPP service that includes a
       'type' attribute whose value is either "openpgp" or "smime".

   4.  Client application adds <x/> element to remainder of presence
       stanza and sends addressed to server with no 'to' attribute.

   5.  Server stamps 'from' address, enabling recipient to check bare
       JID (user@domain) of 'from' address against User-IDs defined a
      user on the XMPP service, it MUST remove the non-XMPP "wrapper"
      (if any) in order to reveal the sender's key multipart S/MIME object, wrap the
      object in an XMPP message or certificate.

   Example: Sender generates signed presence:

     <status>retired presence "wrapper" (including the
      <e2e> and </e2e> tags), and then route the XMPP stanza to the chamber</status>
     <x type='openpgp' xmlns='urn:ietf:params:xml:ns:xmpp-e2e'>
   </presence> XMPP

6. IANA Considerations

   A URN sub-namespace for signed and encrypted content in the
   Extensible Messaging and Presence Protocol (XMPP) is defined as

   URI: urn:ietf:params:xml:ns:xmpp-e2e

   Specification: [RFCXXXX]

   Description: This is the XML namespace name for signed and encrypted
      content in the Extensible Messaging and Presence Protocol as
      defined by [RFCXXXX].

   Registrant Contact: IETF, XMPP Working Group, <>

7. Security Considerations

   Replay attacks

   Detailed security considerations for instant messaging and presence
   protocols are made more difficult using this method because of
   the inclusion of a unique ID given in the encrypted object.  Key exchange
   may rely on the web of trust model used on the OpenPGP keys network.
   There is no RFC 2779 [3], specifically in Sections 5.1
   through 5.4.

   The end-to-end security method to check a fingerprint or ownership of defined here MAY result in exchanging
   secured instant messages and presence information through a key other
   than checking the user IDs on gateway
   that implements CPIM [8] and CPP [9]. Such a key.  A key or certificate SHOULD
   have associated gateway MUST be
   compliant with it the Jabber ID minimum security requirements of the sender.  One instant
   messaging and presence protocols with which it interfaces. The
   introduction of gateways to the
   User-IDs defined security model of instant messaging
   and presence in RFC 2779 also introduces some new risks. End-to-end
   security properties (especially confidentiality and integrity)
   between instant messaging and presence user agents that interface
   through a sender's key or certificate MUST CPIM/CPP gateway can be provided only if common formats are
   supported. The need for end-to-end security is thus met by this
   specification through the bare
   JID (user@domain) use of the 'from' address stamped common formats, specifically MSGFMT
   [6] for instant messages and PIDF [7] for presence information.
   Common formats are further ensured by requiring the sender's
   server on the XML stanzas that the sender generates; a client that
   receives signed or encypted stanzas from the sender MUST check the
   sender's bare JID against the User-IDs defined in the sender's key or
   certificate, use of multipart
   S/MIME [10] objects, as well as CMS [11] EnvelopeData for encryption
   and SHOULD discard the stanza or warn CMS [11] SignedData for signing. Finally, the recipient
   before presenting algorithm used
   SHOULD be AES [12], since it is expected that AES best suits the stanza to
   capabilities of many platforms. However, an IETF specification for
   the recipient if use of AES is still incomplete at the bare JID does
   not match. time of writing.

Normative References

   [1]   Saint-Andre, P. and J. Miller, "XMPP Core (draft-ietf-xmpp-core-
        10, work in progress)", April 2003.

   [2]  Saint-Andre, P. Miller, "XMPP Core",
         draft-ietf-xmpp-core-12 (work in progress), May 2003.

   [2]   Saint-Andre, P. and J. Miller, "XMPP Instant Messaging",
         draft-ietf-xmpp-im-11 (work in progress), May 2003.

   [3]   Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging /
         Presence Protocol Requirements", RFC 2779, February 2000.

   [4]   Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and J. Miller, "XMPP
         Instant Messaging (draft-
        ietf-xmpp-im-09, work in progress)", April 2003.

   [3] Messaging", RFC 2778, February 2000, <http://>.

   [5]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [4]  Callas, J., Donnerhacke, L., Finney, H.

   [6]   Atkins, D. and R. Thayer, "OpenPGP G. Klyne, "Common Presence and Instant Messaging
         Message Format", RFC 2440, November 1998.

   [5] draft-ietf-impp-cpim-msgfmt-08 (work in
         progress), January 2003.

   [7]   Fujimoto, S., Sugano, H., Klyne, G., Bateman, A., Carr, W. and
         J. Peterson, "CPIM Presence Information Data Format",
         draft-ietf-impp-cpim-pidf-08 (work in progress), May 2003.

   [8]   Crocker, D. and J. Peterson, "Common Profile for Instant
         Messaging (CPIM)", draft-ietf-impp-im-02 (work in progress),
         March 2003.

   [9]   Crocker, D. and J. Peterson, "Common Profile for Presence
         (CPP)", draft-ietf-impp-pres-02 (work in progress), March 2003.

   [10]  Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
         2633, June 1999.

Informative References

   [6]  Day, M., Aggarwal, S., Mohr, G.

   [11]  Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369,
         August 2002.

   [12]  Housley, R. and J. Vincent, "A Model Schaad, "Use of the AES Encryption Algorithm
         and RSA-OAEP Key Transport in CMS", draft-ietf-smime-aes-alg-06
         (work in progress), January 2003.

   [13]  Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security
         Multiparts for
        Presence MIME: Multipart/Signed and Instant Messaging", Multipart/Encrypted",
         RFC 2779, February 2000,

   [7] 1847, October 1995.

   [14]  Mealling, M., "The IANA XML Registry", draft-mealling-iana-
         draft-mealling-iana-xmlns-registry-04 (work in progress), June

Authors' Addresses

Author's Address

   Peter Saint-Andre
   Jabber Software Foundation


   Joe Hildebrand
   Jabber, Inc.


Appendix A. XML Schemas Schema for urn:ietf:params:xml:ns:xmpp-e2e

   The following XML schemas are schema is descriptive, not normative.

A.1 urn:ietf:params:xml:ns:xmpp-e2e

   <?xml version='1.0' encoding='UTF-8'?>


     <xs:element name='x'>
           <xs:element ref='signed' minOccurs='0' maxOccurs='1'/>
           <xs:element ref='stanza' minOccurs='0' maxOccurs='1'/>
         <xs:attribute name='type' use='required'/>
             <xs:restriction base='xs:NCName'>
               <xs:enumeration value='openpgp'/>
               <xs:enumeration value='smime'/>

     <xs:element name='signed' type='xs:string'/>
     <xs:element name='stanza' type='xs:string'/>


A.2 urn:ietf:params:xml:ns:xmpp-e2e#payload

   <?xml version='1.0' encoding='UTF-8'?>


     <xs:element name='payload'>
         <xs:element ref='id' maxOccurs='1'/>
         <xs:any namespace='jabber:client' maxOccurs='1'/>

     <xs:element name='id' name='e2e' type='xs:string'/>


Appendix B. Revision History

   Note to RFC Editor: please remove this entire appendix, and the
   corresponding entries in the table of contents, prior to publication.

B.1 Changes from draft-ietf-xmpp-e2e-02

   o  Completely revised to use CPIM/CPP.

B.2 Changes from draft-ietf-xmpp-e2e-01

   o  Removed old Section 6 (Signalling Support via Presence) -- the
      ability to sign broadcasted presence made it redundant.

   o  Made small editorial changes to address RFC Editor requirements.


B.3 Changes from draft-ietf-xmpp-e2e-00

   o  Added support for all stanza types.

   o  Specified that the full stanza is encrypted.

   o  Added support for S/MIME in addition to OpenPGP.

   o  Specified that encrypted presence must be directed to a specific

   o  Specified order of encrypting and signing.

   o  Added support for signing broadcasted presence.

   o  Added IANA considerations.

   o  Changed namespace to 'urn:ietf:params:xml:ns:xmpp-e2e'.

   o  Added XML schema.

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive

Full Copyright Statement

   Copyright (C) The Internet Society (2003). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns. assignees.

   This document and the information contained herein is provided on an


   Funding for the RFC Editor function is currently provided by the
   Internet Society.