End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)
RFC 3923

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    xmpp mailing list <xmppwg@xmpp.org>, 
    xmpp chair <xmpp-chairs@tools.ietf.org>
Subject: Protocol Action: 'End-to-End Object Encryption in the 
         Extensible Messaging and Presence Protocol (XMPP)' to Proposed 

The IESG has approved the following document:

- 'End-to-End Object Encryption in the Extensible Messaging and Presence 
   Protocol (XMPP) '
   <draft-ietf-xmpp-e2e-10.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 Lisa Dusseault.

A URL of this Internet-Draft is:

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

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.