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

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 09

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)

       *  When A establishes a SUBSCRIPTION to B's PRESENCE INFORMATION,
          the protocol MUST provide A means of verifying the accurate
          receipt of the content B chooses to disclose to A.  (Section
          5.1.4)

       *  The protocol MUST provide A means of verifying that the
          presence information is accurate, as sent by B.  (Section