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)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 3923 (Proposed Standard)
|
|
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)
Show full document text