End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)
RFC 3923
Document | Type | RFC - Proposed Standard (October 2004; Errata) | |
---|---|---|---|
Author | Peter Saint-Andre | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 3923 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Scott Hollenbeck | ||
Send notices to | (None) |
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. (SectionShow full document text