End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: Internet Architecture Board <email@example.com>, RFC Editor <firstname.lastname@example.org>, xmpp mailing list <email@example.com>, xmpp chair <firstname.lastname@example.org> Subject: Protocol Action: 'End-to-End Object Encryption in the Extensible Messaging and Presence Protocol (XMPP)' to Proposed Standard 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: http://www.ietf.org/internet-drafts/draft-ietf-xmpp-e2e-10.txt
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.