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