Protocol Action: 'End-to-End Object Encryption in the Extensible Messaging and Presence Protocol (XMPP)' to Proposed Standard
The IESG <iesg-secretary@ietf.org> Mon, 26 July 2004 14:42 UTC
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05163; Mon, 26 Jul 2004 10:42:42 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bp6i5-0003J2-64; Mon, 26 Jul 2004 10:44:13 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bp6bp-00030s-9e; Mon, 26 Jul 2004 10:37:45 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bp6b8-0002kG-KE; Mon, 26 Jul 2004 10:37:04 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03632; Mon, 26 Jul 2004 10:36:59 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bp6bJ-0002bC-TM; Mon, 26 Jul 2004 10:37:14 -0400
Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1Bp6Xu-0002Ob-Db; Mon, 26 Jul 2004 10:33:42 -0400
X-test-idtracker: no
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Message-Id: <E1Bp6Xu-0002Ob-Db@megatron.ietf.org>
Date: Mon, 26 Jul 2004 10:33:42 -0400
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: xmpp chair <presnick@qualcomm.com>, xmpp mailing list <xmppwg@jabber.org>, Internet Architecture Board <iab@iab.org>, xmpp chair <lisa@osafoundation.org>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: Protocol Action: 'End-to-End Object Encryption in the Extensible Messaging and Presence Protocol (XMPP)' to Proposed Standard
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ietf-announce.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
Sender: ietf-announce-bounces@ietf.org
Errors-To: ietf-announce-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
The IESG has approved the following document: - 'End-to-End Object Encryption in the Extensible Messaging and Presence Protocol (XMPP) ' <draft-ietf-xmpp-e2e-09.txt> as a Proposed Standard This document is the product of the Extensible Messaging and Presence Protocol Working Group. The IESG contact persons are Scott Hollenbeck and Ted Hardie. Technical Summary The "End-to-End Object Encryption in XMPP" document defines the mechanisms that would allow an XMPP sender to construct an encrypted and/or signed S/MIME body that is decrypted only at the final recipient, even though there may be several XMPP intermediaries along the path. Because intermediaries may exist and need to know how to route the message, the encrypted message is wrapped in an unencrypted envelope. The message may be an instant message intended for display, or a presence message intended to update the recipient's knowledge of the sender's state, or another type of message. In addition to working for XMPP networks, this specification also allows for the possibility of working over heterogeneous links, through the use of the CPIM standard instant message format and the PIDF standard presence information format (rather than the formats unique to XMPP which are normally transformed in gateways). Gateways to non-XMPP protocols can remove the XMPP envelope and readdress the secured payload for another protocol. The next concern is how the certificate used to sign or encrypt the message is verified against the sender's address. The e2e spec constrains what format the XMPP address must appear in within the certificate, and where. Timestamp checking is required so that this end-to-end encryption and signing can also protect from replay attacks. Finally, the mandatory to implement technologies are SHA-1, RSA and AES. Working Group Summary The working group has done a lot of review of this document, and even been careful to solicit and respond to outside review. There have been several issues but the chairs believe consensus has been reached. Protocol Quality Lisa Dusseault, Pete Resnick, and Scott Hollenbeck have reviewed this document for the IESG. RFC Editor Note: Please remove Appendix B. Please replace instances of "XXXX" in section 12.1 with "RFC" and the RFC number to be assigned to this document. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce