summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3923.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3923.txt')
-rw-r--r--doc/rfc/rfc3923.txt1515
1 files changed, 1515 insertions, 0 deletions
diff --git a/doc/rfc/rfc3923.txt b/doc/rfc/rfc3923.txt
new file mode 100644
index 0000000..d23bc21
--- /dev/null
+++ b/doc/rfc/rfc3923.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+Network Working Group P. Saint-Andre
+Request for Comments: 3923 Jabber Software Foundation
+Category: Standards Track October 2004
+
+
+ End-to-End Signing and Object Encryption for the
+ Extensible Messaging and Presence Protocol (XMPP)
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004).
+
+Abstract
+
+ This memo defines methods of end-to-end signing and object encryption
+ for the Extensible Messaging and Presence Protocol (XMPP).
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 3. Securing Messages . . . . . . . . . . . . . . . . . . . . . 4
+ 4. Securing Presence . . . . . . . . . . . . . . . . . . . . . 9
+ 5. Securing Arbitrary XMPP Data . . . . . . . . . . . . . . . . 13
+ 6. Rules for S/MIME Generation and Handling . . . . . . . . . . 15
+ 7. Recipient Error Handling . . . . . . . . . . . . . . . . . . 18
+ 8. Secure Communications Through a Gateway . . . . . . . . . . 20
+ 9. urn:ietf:params:xml:xmpp-e2e Namespace . . . . . . . . . . . 21
+ 10. application/xmpp+xml Media Type . . . . . . . . . . . . . . 21
+ 11. Security Considerations . . . . . . . . . . . . . . . . . . 22
+ 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 22
+ 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
+ A. Schema for urn:ietf:params:xml:ns:xmpp-e2e . . . . . . . . . 26
+ Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . 26
+ Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 27
+
+
+
+
+
+
+
+
+Saint-Andre Standards Track [Page 1]
+
+RFC 3923 XMPP E2E October 2004
+
+
+1. Introduction
+
+ This memo defines methods of end-to-end signing and object encryption
+ for the Extensible Messaging and Presence Protocol (XMPP). (For
+ information about XMPP, see [XMPP-CORE] and [XMPP-IM].) The method
+ specified herein enables a sender to sign and/or encrypt an instant
+ message sent to a specific recipient, sign and/or encrypt presence
+ information that is directed to a specific user, and sign and/or
+ encrypt any arbitrary XMPP stanza directed to a specific user. This
+ memo thereby helps the XMPP specifications meet the requirements
+ specified in [IMP-REQS].
+
+1.1. Terminology
+
+ This document inherits terminology defined in [CMS], [IMP-MODEL],
+ [SMIME], and [XMPP-CORE].
+
+ The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
+ "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in BCP
+ 14, RFC 2119 [TERMS].
+
+2. Requirements
+
+ For the purposes of this memo, we stipulate the following
+ requirements:
+
+ 1. The method defined MUST address signing and encryption
+ requirements for minimal instant messaging and presence, as those
+ are defined in [IMP-REQS]. In particular, the method MUST
+ address the following requirements, which are copied here
+ verbatim from [IMP-REQS]:
+
+ * The protocol MUST provide means to ensure confidence that a
+ 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
+ received message (NOTIFICATION or INSTANT MESSAGE) has not
+ been recorded and played back by an adversary. (Section
+ 2.5.2)
+
+ * The protocol MUST provide means to ensure that a sent message
+ (NOTIFICATION or INSTANT MESSAGE) is only readable by ENTITIES
+ that the sender allows. (Section 2.5.3)
+
+
+
+
+
+
+Saint-Andre Standards Track [Page 2]
+
+RFC 3923 XMPP E2E October 2004
+
+
+ * The protocol MUST allow any client to use the means to ensure
+ non-corruption, non-playback, and privacy, but the protocol
+ MUST NOT require that all clients use these means at all
+ times. (Section 2.5.4)
+
+ * When A establishes a SUBSCRIPTION to B's PRESENCE INFORMATION,
+ the protocol MUST provide A means of verifying the accurate
+ receipt of the content B chooses to disclose to A. (Section
+ 5.1.4)
+
+ * The protocol MUST provide A means of verifying that the
+ presence information is accurate, as sent by B. (Section
+ 5.3.1)
+
+ * The protocol MUST provide A means of ensuring that no other
+ PRINCIPAL C can see the content of M. (Section 5.4.6)
+
+ * The protocol MUST provide A means of ensuring that no other
+ PRINCIPAL C can tamper with M, and B means to verify that no
+ tampering has occurred. (Section 5.4.7)
+
+ 2. The method defined MUST enable interoperability with non-XMPP
+ messaging systems that support the Common Presence and Instant
+ Messaging (CPIM) specifications published by the Instant
+ Messaging and Presence (IMPP) Working Group. Two corollaries of
+ this requirement are:
+
+ * Prior to signing and/or encrypting, the format of an instant
+ message MUST conform to the CPIM Message Format defined in
+ [MSGFMT].
+
+ * Prior to signing and/or encrypting, the format of presence
+ information MUST conform to the CPP Presence Information Data
+ Format defined in [PIDF].
+
+ 3. The method MUST follow the required procedures (including the
+ specific algorithms) defined in [CPIM] and [CPP]. In particular,
+ these documents specify:
+
+ * Signing MUST use [SMIME] signatures with [CMS] SignedData.
+
+ * Encryption MUST use [SMIME] encryption with [CMS]
+ EnvelopeData.
+
+ 4. In order to enable interoperable implementations, sending and
+ receiving applications MUST implement the algorithms specified
+ under Mandatory-to-Implement Cryptographic Algorithms (Section
+ 6.10).
+
+
+
+Saint-Andre Standards Track [Page 3]
+
+RFC 3923 XMPP E2E October 2004
+
+
+ We further stipulate that the following functionality is out of scope
+ for this memo:
+
+ o Discovery of support for this protocol. An entity could discover
+ whether another entity supports this protocol by (1) attempting to
+ send signed or encrypted stanzas and receiving an error stanza
+ ("technical" discovery) or a textual message in reply ("social"
+ discovery) if the protocol is not supported, or (2) using a
+ dedicated service discovery protocol, such as [DISCO] or [CAPS].
+ However, the definition of a service discovery protocol is out of
+ scope for this memo.
+
+ o Signing or encryption of XMPP groupchat messages, which are
+ mentioned in [XMPP-IM] but not defined therein since they are not
+ required by [IMP-REQS]; such messages are best specified in [MUC].
+
+ o Signing or encryption of broadcasted presence as described in
+ [XMPP-IM] (the methods defined herein apply to directed presence
+ only).
+
+ o Signing or encryption of communications that occur within the
+ context of applications other than instant messaging and presence
+ as those are described in [IMP-MODEL] and [IMP-REQS].
+
+3. Securing Messages
+
+3.1. Process for Securing Messages
+
+ In order to sign and/or encrypt a message, a sending agent MUST use
+ the following procedure:
+
+ 1. Generate a "Message/CPIM" object as defined in [MSGFMT].
+
+ 2. Sign and/or encrypt both the headers and content of the
+ "Message/CPIM" object as specified in Requirement 3 of Section 2
+ above.
+
+ 3. Provide the resulting signed and/or encrypted object within an
+ XML CDATA section (see Section 2.7 of [XML]) contained in an
+ <e2e/> child of a <message/> stanza, where the <e2e/> element is
+ qualified by the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace as
+ specified more fully in Section 9 below.
+
+3.2. Example of a Signed Message
+
+ The following example illustrates the defined steps for signing a
+ message.
+
+
+
+
+Saint-Andre Standards Track [Page 4]
+
+RFC 3923 XMPP E2E October 2004
+
+
+ First, the sending agent generates a "Message/CPIM" object in
+ accordance with the rules and formats specified in [MSGFMT].
+
+ Example 1: Sender generates "Message/CPIM" object:
+
+ | Content-type: Message/CPIM
+ |
+ | From: Juliet Capulet <im:juliet@example.com>
+ | To: Romeo Montague <im:romeo@example.net>
+ | DateTime: 2003-12-09T11:45:36.66Z
+ | Subject: Imploring
+ |
+ | Content-type: text/plain; charset=utf-8
+ | Content-ID: <1234567890@example.com>
+ |
+ | Wherefore art thou, Romeo?
+
+ Once the sending agent has generated the "Message/CPIM" object, the
+ sending agent may sign it. The result is a multipart [SMIME] object
+ (see [MULTI]) that has a Content-Type of "multipart/signed" and
+ includes two parts: one whose Content-Type is "Message/CPIM" and
+ another whose Content-Type is "application/pkcs7-signature".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Saint-Andre Standards Track [Page 5]
+
+RFC 3923 XMPP E2E October 2004
+
+
+ Example 2: Sender generates multipart/signed object:
+
+ | Content-Type: multipart/signed; boundary=next;
+ | micalg=sha1;
+ | protocol=application/pkcs7-signature
+ |
+ | --next
+ | Content-type: Message/CPIM
+ |
+ | From: Juliet Capulet <im:juliet@example.com>
+ | To: Romeo Montague <im:romeo@example.net>
+ | DateTime: 2003-12-09T23:45:36.66Z
+ | Subject: Imploring
+ |
+ | Content-type: text/plain; charset=utf-8
+ | Content-ID: <1234567890@example.com>
+ |
+ | Wherefore art thou, Romeo?
+ | --next
+ | Content-Type: application/pkcs7-signature
+ | Content-Disposition: attachment;handling=required;\
+ | filename=smime.p7s
+ |
+ | [signed body part]
+ |
+ | --next--
+
+ The sending agent now wraps the "multipart/signed" object in an XML
+ CDATA section, which is contained in an <e2e/> element that is
+ included as a child element of the XMPP message stanza and that is
+ qualified by the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Saint-Andre Standards Track [Page 6]
+
+RFC 3923 XMPP E2E October 2004
+
+
+ Example 3: Sender generates XMPP message stanza:
+
+ | <message to='romeo@example.net/orchard' type='chat'>
+ | <e2e xmlns='urn:ietf:params:xml:ns:xmpp-e2e'>
+ | <![CDATA[
+ | Content-Type: multipart/signed; boundary=next;
+ | micalg=sha1;
+ | protocol=application/pkcs7-signature
+ |
+ | --next
+ | Content-type: Message/CPIM
+ |
+ | From: Juliet Capulet <im:juliet@example.com>
+ | To: Romeo Montague <im:romeo@example.net>
+ | DateTime: 2003-12-09T23:45:36.66Z
+ | Subject: Imploring
+ |
+ | Content-type: text/plain; charset=utf-8
+ | Content-ID: <1234567890@example.com>
+ |
+ | Wherefore art thou, Romeo?
+ | --next
+ | Content-Type: application/pkcs7-signature
+ | Content-Disposition: attachment;handling=required;\
+ | filename=smime.p7s
+ |
+ | [signed body part]
+ |
+ | --next--
+ | ]]>
+ | </e2e>
+ | </message>
+
+
+3.3. Example of an Encrypted Message
+
+ The following example illustrates the defined steps for encrypting a
+ message.
+
+ First, the sending agent generates a "Message/CPIM" object in
+ accordance with the rules and formats specified in [MSGFMT].
+
+
+
+
+
+
+
+
+
+
+Saint-Andre Standards Track [Page 7]
+
+RFC 3923 XMPP E2E October 2004
+
+
+ Example 4: Sender generates "Message/CPIM" object:
+
+ | Content-type: Message/CPIM
+ |
+ | From: Juliet Capulet <im:juliet@example.com>
+ | To: Romeo Montague <im:romeo@example.net>
+ | DateTime: 2003-12-09T11:45:36.66Z
+ | Subject: Imploring
+ |
+ | Content-type: text/plain; charset=utf-8
+ | Content-ID: <1234567890@example.com>
+ |
+ | Wherefore art thou, Romeo?
+
+ Once the sending agent has generated the "Message/CPIM" object, the
+ sending agent may encrypt it.
+
+ Example 5: Sender generates encrypted object:
+
+ | U2FsdGVkX19okeKTlLxa/1n1FE/upwn1D20GhPWqhDWlexKMUKYJInTWzERP+vcQ
+ | /OxFs40uc9Fx81a5/62p/yPb/UWnuG6SR6o3Ed2zwcusDImyyz125HFERdDUMBC9
+ | Pt6Z4cTGKBmJzZBGyuc3Y+TMBTxqFFUAxeWaoxnZrrl+LP72vwbriYc3KCMxDbQL
+ | Igc1Vzs5/5JecegMieNY24SlNyX9HMFRNFpbI64vLxYEk55A+3IYbZsluCFT31+a
+ | +GeAvJkvH64LRV4mPbUhENTQ2wbAwnOTvbLIaQEQrii78xNEh+MK8Bx7TBTvi4yH
+ | Ddzf9Sim6mtWsXaCAvWSyp0X91d7xRJ4JIgKfPzkxNsWJFCLthQS1p734eDxXVd3
+ | i08lEHzyll6htuEr59ZDAw==
+
+ The sending agent now wraps the encrypted object in an XML CDATA
+ section, which is contained in an <e2e/> element that is included as
+ a child element of the XMPP message stanza and that is qualified by
+ the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace.
+
+ Example 6: Sender generates XMPP message stanza:
+
+ | <message to='romeo@example.net/orchard' type='chat'>
+ | <e2e xmlns='urn:ietf:params:xml:ns:xmpp-e2e'>
+ | <![CDATA[
+ | U2FsdGVkX19okeKTlLxa/1n1FE/upwn1D20GhPWqhDWlexKMUKYJInTWzERP+vcQ
+ | /OxFs40uc9Fx81a5/62p/yPb/UWnuG6SR6o3Ed2zwcusDImyyz125HFERdDUMBC9
+ | Pt6Z4cTGKBmJzZBGyuc3Y+TMBTxqFFUAxeWaoxnZrrl+LP72vwbriYc3KCMxDbQL
+ | Igc1Vzs5/5JecegMieNY24SlNyX9HMFRNFpbI64vLxYEk55A+3IYbZsluCFT31+a
+ | +GeAvJkvH64LRV4mPbUhENTQ2wbAwnOTvbLIaQEQrii78xNEh+MK8Bx7TBTvi4yH
+ | Ddzf9Sim6mtWsXaCAvWSyp0X91d7xRJ4JIgKfPzkxNsWJFCLthQS1p734eDxXVd3
+ | i08lEHzyll6htuEr59ZDAw==
+ | ]]>
+ | </e2e>
+ | </message>
+
+
+
+
+Saint-Andre Standards Track [Page 8]
+
+RFC 3923 XMPP E2E October 2004
+
+
+4. Securing Presence
+
+4.1. Process for Securing Presence Information
+
+ In order to sign and/or encrypt presence information, a sending agent
+ MUST use the following procedure:
+
+ 1. Generate an "application/pidf+xml" object as defined in [PIDF].
+ 2. Sign and/or encrypt the "application/pidf+xml" object as
+ specified in Requirement 3 of Section 2 above.
+ 3. Provide the resulting signed and/or encrypted object within an
+ XML CDATA section (see Section 2.7 of [XML]) contained in an
+ <e2e/> child of a <presence/> stanza, where the <e2e/> element is
+ qualified by the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace. The
+ <presence/> stanza MUST include a 'to' attribute, i.e., it must
+ be an instance of directed presence as defined in [XMPP-IM].
+
+4.2. Example of Signed Presence Information
+
+ The following example illustrates the defined steps for signing
+ presence information.
+
+ First, the sending agent generates an "application/pidf+xml" object
+ in accordance with the rules and formats specified in [PIDF].
+
+ Example 7: Sender generates "application/pidf+xml" object:
+
+ | <?xml version="1.0" encoding="UTF-8"?>
+ | <presence xmlns="urn:ietf:params:xml:ns:pidf"
+ | xmlns:im="urn:ietf:params:xml:ns:pidf:im"
+ | entity="pres:juliet@example.com">
+ | <tuple id="hr0zny"
+ | <status>
+ | <basic>open</basic>
+ | <im:im>away</im:im>
+ | </status>
+ | <note xml:lang="en">retired to the chamber</note>
+ | <timestamp>2003-12-09T23:53:11.31</timestamp>
+ | </tuple>
+ | </presence>
+
+ Once the sending agent has generated the "application/pidf+xml"
+ object, the sending agent may sign it. The result is a multipart
+ [SMIME] object (see [MULTI]) that has a Content-Type of
+ "multipart/signed" and includes two parts: one whose Content-Type is
+ "application/pidf+xml" and another whose Content-Type is
+ "application/pkcs7-signature".
+
+
+
+
+Saint-Andre Standards Track [Page 9]
+
+RFC 3923 XMPP E2E October 2004
+
+
+ Example 8: Sender generates multipart/signed object:
+
+ | Content-Type: multipart/signed; boundary=next;
+ | micalg=sha1;
+ | protocol=application/pkcs7-signature
+ |
+ | --next
+ | Content-type: application/pidf+xml
+ | Content-ID: <2345678901@example.com>
+ |
+ | <xml version="1.0" encoding="UTF-8"?>
+ | <presence xmlns="urn:ietf:params:xml:ns:pidf"
+ | xmlns:im="urn:ietf:params:xml:ns:pidf:im"
+ | entity="pres:juliet@example.com">
+ | <tuple id="hr0zny">
+ | <status&gt;
+ | <basic>open</basic>
+ | <im:im>away</im:im>
+ | </status>
+ | <note xml:lang="en">retired to the chamber</note>
+ | <timestamp>2003-12-09T23:53:11.31Z</timestamp>
+ | </tuple>
+ | </presence>
+ | --next
+ | Content-Type: application/pkcs7-signature
+ | Content-Disposition: attachment;handling=required;\
+ | filename=smime.p7s
+ |
+ | [signed body part]
+ |
+ | --next--
+
+ The sending agent now wraps the "multipart/signed" object in an XML
+ CDATA section, which is contained in an <e2e/> element that is
+ included as a child element of the XMPP message stanza and that is
+ qualified by the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Saint-Andre Standards Track [Page 10]
+
+RFC 3923 XMPP E2E October 2004
+
+
+ Example 9: Sender generates XMPP presence stanza:
+
+ | <presence to='romeo@example.net/orchard'>
+ | <e2e xmlns='urn:ietf:params:xml:ns:xmpp-e2e'>
+ | <![CDATA[
+ | Content-Type: multipart/signed; boundary=next;
+ | micalg=sha1;
+ | protocol=application/pkcs7-signature
+ |
+ | --next
+ | Content-type: application/pidf+xml
+ | Content-ID: <2345678901@example.com>
+ |
+ | <xml version="1.0" encoding="UTF-8"?>
+ | <presence xmlns="urn:ietf:params:xml:ns:pidf"
+ | xmlns:im="urn:ietf:params:xml:ns:pidf:im"
+ | entity="pres:juliet@example.com">
+ | <tuple id="hr0zny">
+ | <status>
+ | <basic>open</basic>
+ | <im:im>away</im:im>
+ | </status>
+ | <note xml:lang="en">retired to the chamber</note>
+ | <timestamp>2003-12-09T23:53:11.31Z</timestamp>
+ | </tuple>
+ | </presence>
+ | --next
+ | Content-Type: application/pkcs7-signature
+ | Content-Disposition: attachment;handling=required;\
+ | filename=smime.p7s
+ |
+ | [signed body part]
+ |
+ | --next--
+ | ]]>
+ | </e2e>
+ | </presence>
+
+4.3. Example of Encrypted Presence Information
+
+ The following example illustrates the defined steps for encrypting
+ presence information.
+
+ First, the sending agent generates an "application/pidf+xml" object
+ in accordance with the rules and formats specified in [PIDF].
+
+
+
+
+
+
+Saint-Andre Standards Track [Page 11]
+
+RFC 3923 XMPP E2E October 2004
+
+
+ Example 10: Sender generates "application/pidf+xml" object:
+
+ | <?xml version="1.0" encoding="UTF-8"?>
+ | <presence xmlns="urn:ietf:params:xml:ns:pidf"
+ | xmlns:im="urn:ietf:params:xml:ns:pidf:im"
+ | entity="pres:juliet@example.com">
+ | <tuple id="hr0zny"
+ | <status>
+ | <basic>open</basic>
+ | <im:im>away</im:im>
+ | </status>
+ | <note xml:lang="en">retired to the chamber</note>
+ | <timestamp>2003-12-09T23:53:11.31</timestamp>
+ | </tuple>
+ | </presence>
+
+ Once the sending agent has generated the "application/pidf+xml"
+ object, the sending agent may encrypt it.
+
+ Example 11: Sender generates encrypted object:
+
+ | U2FsdGVkX18VJPbx5GMdFPTPZrHLC9QGiVP+ziczu6zWZLFQxae6O5PP6iqpr2No
+ | zOvBVMWvYeRAT0zd18hr6qsqKiGl/GZpAAbTvPtaBxeIykxsd1+CX+U+iw0nEGCr
+ | bjiQrk0qUKJ79bNxwRnqdidjhyTpKSbOJC0XZ8CTe7AE9KDM3Q+uk+O3jrqX4byL
+ | GBlKThbzKidxz32ObojPEEwfFiM/yUeqYUP1OcJpUmeQ8lcXhD6tcx+m2MAyYYLP
+ | boKQxpLknxRnbM8T/voedlnFLbbDu69mOlxDPbr1mHZd3hDsyFudb1fb4rI3Kw0K
+ | Nq+3udr2IkysviJDgQo+xGIQUG/5sED/mAaPRlj4f/JtTzvT4EaQTawv69ntXfKV
+ | MCr9KdIMMdjdJzOJkYLoAhNVrcZn5tw8WsJGwuKuhYb/SShy7InzOapPaPAl7/Mm
+ | PHj7zj3NZ6EEIweDOuAwWlIG/dT506tci27+EW7JnXwMPnFMkF+6a7tr/0Y+iiej
+ | woJxUIBqCOgX+U7srHpK2NYtNTZ7UQp2V0yEx1JV8+Y=
+
+ The sending agent now wraps the encrypted object in an XML CDATA
+ section, which is contained in an <e2e/> element that is included as
+ a child element of the XMPP message stanza and that is qualified by
+ the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Saint-Andre Standards Track [Page 12]
+
+RFC 3923 XMPP E2E October 2004
+
+
+ Example 12: Sender generates XMPP presence stanza:
+
+ | <presence to='romeo@example.net/orchard'>
+ | <e2e xmlns='urn:ietf:params:xml:ns:xmpp-e2e'>
+ | <![CDATA[
+ | U2FsdGVkX18VJPbx5GMdFPTPZrHLC9QGiVP+ziczu6zWZLFQxae6O5PP6iqpr2No
+ | zOvBVMWvYeRAT0zd18hr6qsqKiGl/GZpAAbTvPtaBxeIykxsd1+CX+U+iw0nEGCr
+ | bjiQrk0qUKJ79bNxwRnqdidjhyTpKSbOJC0XZ8CTe7AE9KDM3Q+uk+O3jrqX4byL
+ | GBlKThbzKidxz32ObojPEEwfFiM/yUeqYUP1OcJpUmeQ8lcXhD6tcx+m2MAyYYLP
+ | boKQxpLknxRnbM8T/voedlnFLbbDu69mOlxDPbr1mHZd3hDsyFudb1fb4rI3Kw0K
+ | Nq+3udr2IkysviJDgQo+xGIQUG/5sED/mAaPRlj4f/JtTzvT4EaQTawv69ntXfKV
+ | MCr9KdIMMdjdJzOJkYLoAhNVrcZn5tw8WsJGwuKuhYb/SShy7InzOapPaPAl7/Mm
+ | PHj7zj3NZ6EEIweDOuAwWlIG/dT506tci27+EW7JnXwMPnFMkF+6a7tr/0Y+iiej
+ | woJxUIBqCOgX+U7srHpK2NYtNTZ7UQp2V0yEx1JV8+Y=
+ | ]]>
+ | </e2e>
+ | </presence>
+
+5. Securing Arbitrary XMPP Data
+
+ The foregoing sections of this memo describe how to secure "least
+ common denominator" messaging and presence data of the kind that can
+ be directly translated into the MSGFMT or PIDF formats. However,
+ XMPP possesses a third base-level stanza type (<iq/>) in addition to
+ <message/> and <presence/>, as well as the ability to include
+ extended XML data within arbitrary child elements of the three core
+ stanza types. Therefore, it would be desirable to secure such data
+ if possible.
+
+ Because [MSGFMT] specifies the ability to encapsulate any MIME type,
+ the approach taken in this memo is to include arbitrary XMPP data in
+ an XML media type named "application/xmpp+xml" as specified more
+ fully in Section 10 below.
+
+ The following examples illustrate the structure of the
+ "application/xmpp+xml" MIME type. (Note: The
+ 'http://jabber.org/protocol/evil' namespace used in these examples is
+ associated with an April Fool's protocol written to be the instant
+ messaging equivalent of RFC 3514; it is included only as an instance
+ of extended information included in an XML stanza and should not be
+ taken seriously as a functional XMPP extension.)
+
+
+
+
+
+
+
+
+
+
+Saint-Andre Standards Track [Page 13]
+
+RFC 3923 XMPP E2E October 2004
+
+
+ Example 13: Message stanza with extended data contained in
+ "application/xmpp+xml" MIME type:
+
+ | <?xml version='1.0' encoding='UTF-8'?>
+ | <xmpp xmlns='jabber:client'>
+ | <message
+ | from='iago@example.com/pda'
+ | to='emilia@example.com/cell'>
+ | <body>
+ | I told him what I thought, and told no more
+ | Than what he found himself was apt and true.
+ | </body>
+ | <evil xmlns='http://jabber.org/protocol/evil'/>
+ | </message>
+ | </xmpp>
+
+ Example 14: Presence stanza with extended data contained in
+ "application/xmpp+xml" MIME type:
+
+ | <?xml version='1.0' encoding='UTF-8'?>
+ | <xmpp xmlns='jabber:client'>
+ | <presence from='iago@example.com/pda'>
+ | <show>dnd</show>
+ | <status>Fomenting dissension</status>
+ | <evil xmlns='http://jabber.org/protocol/evil'/>
+ | </presence>
+ | </xmpp>
+
+ Example 15: IQ stanza with extended data contained in "application/
+ xmpp+xml" MIME type:
+
+ | <?xml version='1.0' encoding='UTF-8'?>
+ | <xmpp xmlns='jabber:client'>
+ | <iq type='result'
+ | from='iago@example.com/pda'
+ | to='emilia@example.com/cell'
+ | id='evil1'>
+ | <query xmlns='jabber:iq:version'>
+ | <name>Stabber</name>
+ | <version>666</version>
+ | <os>FiendOS</os>
+ | </query>
+ | <evil xmlns='http://jabber.org/protocol/evil'/>
+ | </iq>
+ | </xmpp>
+
+
+
+
+
+
+Saint-Andre Standards Track [Page 14]
+
+RFC 3923 XMPP E2E October 2004
+
+
+ Just as with the "Message/CPIM" and "application/pidf+xml" objects,
+ the "application/xmpp+xml" object would be signed and/or encrypted,
+ then encapsulated within an XML CDATA section (see Section 2.7 of
+ [XML]) contained in an <e2e/> child of a <presence/> stanza, where
+ the <e2e/> element is qualified by the
+ 'urn:ietf:params:xml:ns:xmpp-e2e' namespace.
+
+6. Rules for S/MIME Generation and Handling
+
+6.1. Certificate Enrollment
+
+ [SMIME] does not specify how to obtain a certificate from a
+ certificate authority, but instead mandates that every sending agent
+ must already have a certificate. The PKIX Working Group has, at the
+ time of this writing, produced two separate standards for certificate
+ enrollment: [CMP] and [CMC]. Which method to use for certificate
+ enrollment is outside the scope of this memo.
+
+6.2. Certificate Retrieval
+
+ A receiving agent MUST provide some certificate retrieval mechanism
+ in order to gain access to certificates for recipients of digital
+ envelopes. This memo does not address how S/MIME agents handle
+ certificates, only what they do after a certificate has been
+ validated or rejected. S/MIME certification issues are covered in
+ [CERT].
+
+ However, at a minimum, for initial S/MIME deployment, a user agent
+ SHOULD automatically generate a message to an intended recipient
+ requesting that recipient's certificate in a signed return message.
+ Receiving and sending agents SHOULD also provide a mechanism to allow
+ a user to "store and protect" certificates for correspondents in such
+ a way so as to guarantee their later retrieval.
+
+6.3. Certificate Names
+
+ End-entity certificates used by XMPP entities in the context of this
+ memo SHOULD contain a valid instant messaging and presence address.
+ The address SHOULD be specified as both an 'im:' URI (for instant
+ messaging, as defined in [CPIM]) and a 'pres:' URI (for presence, as
+ defined in [CPP]); each of these URIs SHOULD be specified in a
+ separate GeneralName entry of type uniformResourceIdentifier inside
+ the subjectAltName (i.e., two separate entries). Information in the
+ subject distinguished name SHOULD be ignored.
+
+ Each URI MUST be of the form <im:address> or <pres:address>, where
+ the "address" portion is an XMPP address (also referred to as a
+ Jabber Identifier or JID) as defined in [XMPP-CORE], prepended with
+
+
+
+Saint-Andre Standards Track [Page 15]
+
+RFC 3923 XMPP E2E October 2004
+
+
+ the 'im:' or 'pres:' URI scheme. The address SHOULD be of the form
+ <node@domain> (i.e., a "bare JID"), although any valid JID form MAY
+ be used.
+
+ The value of the JID contained in the XMPP 'from' attribute MUST
+ match a JID provided in the signer's certificate, with the exception
+ that the resource identifier portion of the JID contained in the
+ 'from' attribute SHOULD be ignored for matching purposes.
+
+ Receiving agents MUST check that the sending JID matches a JID
+ provided in the signer's certificate, with the exception that the
+ resource identifier portion of the JID contained in the 'from'
+ attribute SHOULD be ignored for matching purposes. A receiving agent
+ SHOULD provide some explicit alternate processing of the stanza if
+ this comparison fails, which may be to display a message informing
+ the recipient of the addresses in the certificate or other
+ certificate details.
+
+ The subject alternative name extension is used in S/MIME as the
+ preferred means to convey the instant messaging and presence address
+ that corresponds to the entity for this certificate. Any XMPP
+ address present in the certificate MUST be encoded using the ASN.1
+ Object Identifier "id-on-xmppAddr" as specified in Section 5.1.1 of
+ [XMPP-CORE].
+
+6.4. Transfer Encoding
+
+ Because it is expected that XMPP applications will not interface with
+ older 7-bit systems, the transfer encoding (as defined in Section
+ 3.1.2 of [SMIME]) MUST be "binary".
+
+6.5. Order of Signing and Encrypting
+
+ If a stanza is both signed and encrypted, it SHOULD be signed first,
+ then encrypted.
+
+6.6. Inclusion of Certificates
+
+ If the sender and recipient are involved in an active messaging
+ session over a period of time, the sending agent SHOULD include the
+ sender's certificate along with at least one encrypted message stanza
+ every five minutes. Outside the context of an active messaging
+ session, the sending agent SHOULD include the sender's certificate
+ along with each encrypted message stanza. A sending agent MAY
+ include the sender's certificate along with each encrypted presence
+ stanza. However, a sending agent SHOULD NOT include a certificate
+ more than once every five minutes.
+
+
+
+
+Saint-Andre Standards Track [Page 16]
+
+RFC 3923 XMPP E2E October 2004
+
+
+6.7. Attachment and Checking of Signatures
+
+ Sending agents SHOULD attach a signature to each encrypted XML
+ stanza. If a signature is attached, a Content-Disposition header
+ field (as defined in [DISP]) SHOULD be included to specify how the
+ signature is to be handled by the receiving application.
+
+ If the receiving agent determines that the signature attached to an
+ encrypted XML stanza is invalid, it SHOULD NOT present the stanza to
+ the intended recipient (human or application), SHOULD provide some
+ explicit alternate processing of the stanza (which may be to display
+ a message informing the recipient that the attached signature is
+ invalid), and MAY return a stanza error to the sender as described
+ under Recipient Error Handling (Section 7).
+
+6.8. Decryption
+
+ If the receiving agent is unable to decrypt the encrypted XML stanza,
+ it SHOULD NOT present the stanza to the intended recipient (human or
+ application), SHOULD provide some explicit alternate processing of
+ the stanza (which may be to display a message informing the recipient
+ that it has received a stanza that cannot be decrypted), and MAY
+ return a stanza error to the sender as described under Recipient
+ Error Handling (Section 7).
+
+6.9. Inclusion and Checking of Timestamps
+
+ Timestamps are included in "Message/CPIM" and "application/pidf+xml"
+ objects to help prevent replay attacks. All timestamps MUST conform
+ to [DATETIME] and be presented as UTC with no offset, including
+ fractions of a second as appropriate. Absent a local adjustment to
+ the sending agent's perceived time or the underlying clock time, the
+ sending agent MUST ensure that the timestamps it sends to the
+ receiver increase monotonically (if necessary by incrementing the
+ seconds fraction in the timestamp if the clock returns the same time
+ for multiple requests). The following rules apply to the receiving
+ application:
+
+ o It MUST verify that the timestamp received is within five minutes
+ of the current time.
+
+ o It SHOULD verify that the timestamp received is greater than any
+ timestamp received in the last 10 minutes which passed the
+ previous check.
+
+
+
+
+
+
+
+Saint-Andre Standards Track [Page 17]
+
+RFC 3923 XMPP E2E October 2004
+
+
+ o If any of the foregoing checks fails, the timestamp SHOULD be
+ presented to the receiving entity (human or application) marked as
+ "old timestamp", "future timestamp", or "decreasing timestamp",
+ and the receiving entity MAY return a stanza error to the sender
+ as described under Recipient Error Handling (Section 7).
+
+6.10. Mandatory-to-Implement Cryptographic Algorithms
+
+ All implementations MUST support the following algorithms.
+ Implementations MAY support other algorithms as well.
+
+ For CMS SignedData:
+
+ o The SHA-1 message digest as specified in [CMS-ALG] section 2.1.
+
+ o The RSA (PKCS #1 v1.5) with SHA-1 signature algorithm, as
+ specified in [CMS-ALG] section 3.2.
+
+ For CMS EnvelopedData:
+
+ o The RSA (PKCS #1 v1.5) key transport, as specified in [CMS-ALG]
+ section 4.2.1.
+
+ o The AES-128 encryption algorithm in CBC mode, as specified in
+ [CMS-AES].
+
+7. Recipient Error Handling
+
+ When an XMPP entity receives an XML stanza containing data that is
+ signed and/or encrypted using the protocol described herein, several
+ scenarios are possible:
+
+ Case #1: The receiving application does not understand the protocol.
+
+ Case #2: The receiving application understands the protocol and is
+ able to decrypt the payload and verify the sender's signature.
+
+ Case #3: The receiving application understands the protocol and is
+ able to decrypt the payload and verify the sender's signature, but
+ the timestamps fail the checks specified above under Checking of
+ Timestamps (Section 6.9).
+
+ Case #4: The receiving application understands the protocol and is
+ able to decrypt the payload but is unable to verify the sender's
+ signature.
+
+ Case #5: The receiving application understands the protocol but is
+ unable to decrypt the payload.
+
+
+
+Saint-Andre Standards Track [Page 18]
+
+RFC 3923 XMPP E2E October 2004
+
+
+ In Case #1, the receiving application MUST do one and only one of the
+ following: (1) ignore the <e2e/> extension, (2) ignore the entire
+ stanza, or (3) return a <service-unavailable/> error to the sender,
+ as described in [XMPP-CORE].
+
+ In Case #2, the receiving application MUST NOT return a stanza error
+ to the sender, since this is the success case.
+
+ In Case #3, the receiving application MAY return a <not-acceptable/>
+ error to the sender (as described in [XMPP-CORE]), optionally
+ supplemented by an application-specific error condition element
+ <bad-timestamp/> as shown below:
+
+ Example 16: Recipient returns <not-acceptable/> error:
+
+ <message from='romeo@example.net/orchard' type='chat'>
+ <e2e xmlns='urn:ietf:params:xml:ns:xmpp-e2e'>
+ [CDATA section here]
+ </e2e>
+ <error type='modify'>
+ <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
+ <bad-timestamp xmlns='urn:ietf:params:xml:xmpp-e2e'/>
+ </error>
+ </message>
+
+ In Case #4, the receiving application SHOULD return a
+ <not-acceptable/> error to the sender (as described in [XMPP-CORE]),
+ optionally supplemented by an application-specific error condition
+ element <unverified-signature/> as shown below:
+
+ Example 17: Recipient returns <not-acceptable/> error:
+
+ <message from='romeo@example.net/orchard' type='chat'>
+ <e2e xmlns='urn:ietf:params:xml:ns:xmpp-e2e'>
+ [CDATA section here]
+ </e2e>
+ <error type='modify'>
+ <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
+ <unverified-signature xmlns='urn:ietf:params:xml:xmpp-e2e'/>
+ </error>
+ </message>
+
+ In Case #5, the receiving application SHOULD return a <bad-request/>
+ error to the sender (as described in [XMPP-CORE]), optionally
+ supplemented by an application-specific error condition element
+ <decryption-failed/> as shown below:
+
+
+
+
+
+Saint-Andre Standards Track [Page 19]
+
+RFC 3923 XMPP E2E October 2004
+
+
+ Example 18: Recipient returns <bad-request/> error:
+
+ <message from='romeo@example.net/orchard' type='chat'>
+ <e2e xmlns='urn:ietf:params:xml:ns:xmpp-e2e'>
+ [CDATA section here]
+ </e2e>
+ <error type='modify'>
+ <bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
+ <decryption-failed xmlns='urn:ietf:params:xml:xmpp-e2e'/>
+ </error>
+ </message>
+
+8. Secure Communications Through a Gateway
+
+ A common method for achieving interoperability between two disparate
+ services is through the use of a "gateway" that interprets the
+ protocols of each service and translates them into the protocols of
+ the other. The CPIM specifications (specifically [MSGFMT] and [PIDF]
+ define the common profiles to be used for interoperability between
+ instant messaging and presence services that comply with [IMP-REQS].
+ In the case of communications between an XMPP service and a non-XMPP
+ service, we can visualize this relationship as follows:
+
+ +-------------+ +-------------+ +------------+
+ | | | | | |
+ | XMPP | | XMPP-CPIM | | Non-XMPP |
+ | Service | <----> | Gateway | <----> | Service |
+ | | | | | |
+ +-------------+ +-------------+ +------------+
+
+ The end-to-end encryption method defined herein enables the exchange
+ of encrypted and/or signed instant messages and presence through an
+ XMPP-CPIM gateway. In particular:
+
+ o When a gateway receives a secured XMPP message or presence stanza
+ from the XMPP service that is addressed to a user on the non-XMPP
+ service, it MUST remove the XMPP "wrapper" (everything down to and
+ including the <e2e> and </e2e> tags) in order to reveal the
+ multipart S/MIME object, then route the object to the non-XMPP
+ service (first wrapping it in the protocol used by the non-XMPP
+ service if necessary).
+
+
+
+
+
+
+
+
+
+
+Saint-Andre Standards Track [Page 20]
+
+RFC 3923 XMPP E2E October 2004
+
+
+ o When a gateway receives a secured non-XMPP instant message or
+ presence document from the non-XMPP service that is addressed to a
+ user on the XMPP service, it MUST remove the non-XMPP "wrapper"
+ (if any) in order to reveal the multipart S/MIME object, wrap the
+ object in an XMPP message or presence "wrapper" (including the
+ <e2e> and </e2e> tags), and then route the XMPP stanza to the XMPP
+ service.
+
+ The wrapped S/MIME object MUST be immutable and MUST NOT be modified
+ by an XMPP-CPIM gateway.
+
+9. urn:ietf:params:xml:xmpp-e2e Namespace
+
+ The <e2e xmlns='urn:ietf:params:xml:ns:xmpp-e2e'/> element is a
+ wrapper for an XML CDATA section (see Section 2.7 of [XML]) that
+ contains a "Message/CPIM", "application/pidf+xml", or
+ "application/xmpp+xml" object. Thus the
+ 'urn:ietf:params:xml:xmpp-e2e' namespace has no inherent semantics,
+ and the semantics of the encapsulated object are defined by one of
+ the following specifications:
+
+ o [MSGFMT] for "Message/CPIM"
+ o [PIDF] for "application/pidf+xml"
+ o [XMPP-CORE] for "application/xmpp+xml"
+
+ Although the "application/xmpp+xml" media type is specified in this
+ document, the <xmpp/> element is simply a wrapper for a <message/>,
+ <presence/>, or <iq/> stanza, where the semantics of those stanza
+ types are specified in [XMPP-CORE].
+
+ Given that the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace has no
+ inherent semantics and specifies a using protocol only, versioning is
+ the responsibility of the protocols that define the encapsulated
+ objects ([MSGFMT], [PIDF], and [XMPP-CORE]).
+
+10. application/xmpp+xml Media Type
+
+ The "application/xmpp+xml" media type adheres to the guidelines
+ specified in [XML-MEDIA]. The root element for this MIME type is
+ <xmpp/>, and the root element MUST contain one and only one child
+ element, corresponding to one of the XMPP stanza types (i.e.,
+ message, presence, or iq) if the default namespace is 'jabber:client'
+ or 'jabber:server' as defined in [XMPP-CORE]. The character encoding
+ for this XML media type MUST be UTF-8, in accordance with Section
+ 11.5 of [XMPP-CORE].
+
+
+
+
+
+
+Saint-Andre Standards Track [Page 21]
+
+RFC 3923 XMPP E2E October 2004
+
+
+11. Security Considerations
+
+ This entire memo discusses security. Detailed security
+ considerations for instant messaging and presence protocols are given
+ in [IMP-REQS] (Sections 5.1 through 5.4), and for XMPP in particular
+ are given in [XMPP-CORE] (Sections 12.1 through 12.6). In addition,
+ all of the security considerations specified in [XML-MEDIA] apply to
+ the "application/xmpp+xml" media type.
+
+ The end-to-end security method defined here MAY result in exchanging
+ secured instant messages and presence information through a gateway
+ that implements the CPIM specifications. Such a gateway MUST be
+ compliant with the minimum security requirements of the instant
+ messaging and presence protocols with which it interfaces.
+
+12. IANA Considerations
+
+12.1. XML Namespace Name for e2e Data in XMPP
+
+ A URN sub-namespace of signed and encrypted content for the
+ Extensible Messaging and Presence Protocol (XMPP) is defined as
+ follows. (This namespace name adheres to the format defined in
+ [XML-REG].)
+
+ URI: urn:ietf:params:xml:ns:xmpp-e2e
+ Specification: RFC 3923
+ Description: This is an XML namespace name of signed and encrypted
+ content for the Extensible Messaging and Presence Protocol as
+ defined by RFC 3923.
+ Registrant Contact: IESG, <iesg@ietf.org>
+
+12.2. Content-type Registration for "application/xmpp+xml"
+
+ To: ietf-types@iana.org
+
+ Subject: Registration of MIME media type application/xmpp+xml
+
+ MIME media type name: application
+ MIME subtype name: xmpp+xml
+ Required parameters: (none)
+ Optional parameters: (charset) Same as charset parameter of
+ application/xml as specified in RFC 3023; per Section 11.5 of
+ [XMPP-CORE], the charset must be UTF-8.
+ Encoding considerations: Same as encoding considerations of
+ application/xml as specified in RFC 3023; per Section 11.5 of
+ [XMPP-CORE], the encoding must be UTF-8.
+
+
+
+
+
+Saint-Andre Standards Track [Page 22]
+
+RFC 3923 XMPP E2E October 2004
+
+
+ Security considerations: All of the security considerations specified
+ in RFC 3023 and [XMPP-CORE] apply to this XML media type. Refer
+ to Section 11 of RFC 3923.
+ Interoperability considerations: (none)
+ Specification: RFC 3923
+ Applications which use this media type: XMPP-compliant instant
+ messaging and presence systems.
+ Additional information: (none)
+ Person and email address to contact for further information: IESG,
+ <iesg@ietf.org>
+ Intended usage: COMMON
+ Author/Change controller: IETF, XMPP Working Group
+
+13. References
+
+13.1. Normative References
+
+ [CERT] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
+ Extensions (S/MIME) Version 3.1 Certificate Handling",
+ RFC 3850, July 2004.
+
+ [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
+ 3852, July 2004.
+
+ [CMS-AES] Schaad, J., "Use of the Advanced Encryption Standard
+ (AES) Encryption Algorithm in Cryptographic Message
+ Syntax (CMS)", RFC 3565, July 2003.
+
+ [CMS-ALG] Housley, R., "Cryptographic Message Syntax (CMS)
+ Algorithms", RFC 3370, August 2002.
+
+ [CPIM] Peterson, J., "Common Profile for Instant Messaging
+ (CPIM)", RFC 3860, August 2004.
+
+ [CPP] Peterson, J., "Common Profile for Presence (CPP)", RFC
+ 3859, August 2004.
+
+ [DATETIME] Klyne, G. and C. Newman, "Date and Time on the
+ Internet: Timestamps", RFC 3339, July 2002.
+
+ [DISP] Troost, R., Dorner, S., and K. Moore, Ed.,
+ "Communicating Presentation Information in Internet
+ Messages: The Content-Disposition Header Field", RFC
+ 2183, August 1997.
+
+ [IMP-MODEL] Day, M., Rosenberg, J., and H. Sugano, "A Model for
+ Presence and Instant Messaging", RFC 2778, February
+ 2000.
+
+
+
+Saint-Andre Standards Track [Page 23]
+
+RFC 3923 XMPP E2E October 2004
+
+
+ [IMP-REQS] Day, M., Aggarwal, S., Mohr, G., and J. Vincent,
+ "Instant Messaging/Presence Protocol Requirements", RFC
+ 2779, February 2000.
+
+ [MSGFMT] Klyne, G. and D. Atkins, "Common Presence and Instant
+ Messaging (CPIM): Message Format", RFC 3862, August
+ 2004.
+
+ [MULTI] Galvin, J., Murphy, S., Crocker, S., and N. Freed,
+ "Security Multiparts for MIME: Multipart/Signed and
+ Multipart/Encrypted", RFC 1847, October 1995.
+
+ [PIDF] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr,
+ W., and J. Peterson, "Presence Information Data Format
+ (PIDF)", RFC 3863, August 2004.
+
+ [SMIME] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
+ Extensions (S/MIME) Version 3.1 Message Specification",
+ RFC 3851, July 2004.
+
+ [TERMS] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [XML-MEDIA] Murata, M., St. Laurent, S. and D. Kohn, "XML Media
+ Types", RFC 3023, January 2001.
+
+ [XMPP-CORE] Saint-Andre, P., Ed., "Extensible Messaging and
+ Presence Protocol (XMPP): Core", RFC 3920, October
+ 2004.
+
+ [XMPP-IM] Saint-Andre, P., Ed., "Extensible Messaging and
+ Presence Protocol (XMPP) Instant Messaging and
+ Presence", RFC 3921, October 2004.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Saint-Andre Standards Track [Page 24]
+
+RFC 3923 XMPP E2E October 2004
+
+
+13.2. Informative References
+
+ [CAPS] Hildebrand, J. and P. Saint-Andre, "Entity
+ Capabilities", JSF JEP 0115, August 2004.
+
+ [CMC] Myers, M., Liu, X., Schaad, J. and J. Weinstein,
+ "Certificate Management Messages over CMS", RFC 2797,
+ April 2000.
+
+ [CMP] Adams, C. and S. Farrell, "Internet X.509 Public Key
+ Infrastructure Certificate Management Protocols", RFC
+ 2510, March 1999.
+
+ [DISCO] Hildebrand, J., Millard, P., Eatmon, R. and P. Saint-
+ Andre, "Service Discovery", JSF JEP 0030, July 2004.
+
+ [MUC] Saint-Andre, P., "Multi-User Chat", JSF JEP 0045, June
+ 2004.
+
+ [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
+ "Extensible Markup Language (XML) 1.0 (3rd ed)", W3C
+ REC-xml, February 2004, <http://www.w3.org/TR/REC-xml>.
+
+ [XML-REG] Mealling, M., "The IETF XML Registry", BCP 81, RFC
+ 3688, January 2004.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Saint-Andre Standards Track [Page 25]
+
+RFC 3923 XMPP E2E October 2004
+
+
+Appendix A. Schema for urn:ietf:params:xml:ns:xmpp-e2e
+
+ The following XML schema is descriptive, not normative.
+
+ <?xml version='1.0' encoding='UTF-8'?>
+
+ <xs:schema
+ xmlns:xs='http://www.w3.org/2001/XMLSchema'
+ targetNamespace='urn:ietf:params:xml:ns:xmpp-e2e'
+ xmlns='urn:ietf:params:xml:ns:xmpp-e2e'
+ elementFormDefault='qualified'>
+
+ <xs:element name='e2e' type='xs:string'/>
+
+ <xs:element name='decryption-failed' type='empty'/>
+ <xs:element name='signature-unverified' type='empty'/>
+ <xs:element name='bad-timestamp' type='empty'/>
+
+ <xs:simpleType name='empty'>
+ <xs:restriction base='xs:string'>
+ <xs:enumeration value=''/>
+ </xs:restriction>
+ </xs:simpleType>
+
+ </xs:schema>
+
+Author's Address
+
+ Peter Saint-Andre
+ Jabber Software Foundation
+
+ EMail: stpeter@jabber.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Saint-Andre Standards Track [Page 26]
+
+RFC 3923 XMPP E2E October 2004
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
+ REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
+ INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights 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; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the IETF's procedures with respect to rights in IETF Documents can
+ be found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at ietf-
+ ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Saint-Andre Standards Track [Page 27]
+