XEP-0420: Stanza Content Encryption

1. Introduction¶

There is a number of different end-to-end encryption mechanisms that can be used to secure user communication against unauthorized access from malicious third parties. Popular examples for this are OMEMO Encryption (XEP-0384) [1] and OpenPGP for XMPP (XEP-0373) [2].

While the latter allows for encryption of arbitrary extension elements, protocols such as OMEMO Encryption (XEP-0384) [1] were historically limited to only encrypt the body of a message. This approach is not very flexible and prevents the combined usage with XMPP extension protocols such as Stateless Inline Media Sharing (XEP-0385) [3] or Last Message Correction (XEP-0308) [4] as their extension elements cannot be included in the encrypted part of the message, therefore leaking information about the message content.

This extension protocol proposes a solution to aforementioned issues by generalizing the OpenPGP Content Elements (eg. <signcrypt>) introduced by OpenPGP for XMPP (XEP-0373) [2] for the use with other encryption protocols.

2. Requirements¶

This proposal widens the scope of the security guarantees given by the used encryption mechanism from just the body of the message to various extension elements. It is intended to serve as a "one size fits all" solution for extension element encryption in XMPP.

In order to achieve its goal, Stanza Content Encryption does the following:

• Define elements that hold sensitive information
• Speficy rules about how extension elements are encrypted and embedded in the message
• Specify rules about which elements are allowed inside and outside the protected domain

3. Glossary¶

4. Affix Elements¶

In order to prevent certain attacks, different affix elements MAY be added as direct child elements of the <envelope/> element.

<time stamp='2004-01-25T06:05:00+01:00'/>
<to jid='missioncontrol@houston.nasa.gov'/>
<from jid='opportunity@mars.planet'/>
<rpad>C1DHN9HK-9A25tSmwK4hU!Jji9%GKYK^syIlHJT9TnI4</rpad>

  

Encryption protocols that make use of Stanza Content Encryption MUST define their own profiles that describe mandatory behaviour of which of these elements are used. They MAY also define and add their own specific affix elements.

5. Motivation¶

Some end-to-end encryption protocols like OMEMO Encryption (XEP-0384) [1] were historically limited to encryption of the message body only. This approach excludes other extension elements from the protected domain of the payload element, exposing them to potential attackers.

<message from='narrator@jabber.org'
         to='viewer@jabber.org'>
  <encrypted xmlns='eu.siacs.conversations.axolotl'>
    <header sid='27183'>
      ...
    </header>
    <payload>
      SSBnb3QgaW4gZXZlcnlvbmUncyBob3N0aWxlIGxpdHRsZSBmYWNlLiBZZXMsIHRoZXNlIGFyZSBi
      cnVpc2VzIGZyb20gZmlnaHRpbmcuIFllcywgSSdtIGNvbWZvcnRhYmxlIHdpdGggdGhhdC4gSSBh
      bSBlbmxpZ2h0ZW5lZC4=
    </payload>
  </encrypted>
  <x xmlns='jabber:x:oob'>
    <url>https://en.wikipedia.org/wiki/Fight_Club#Plot</url>
  </x>
</message>

  

The example above leaks information about the communication through the unencrypted OOB extension element.

Stanza Content Encryption is not limited to <message/> stanzas; <iq/> stanzas can be encrypted as well.

<iq from='doctor@shakespeare.lit/pda'
    id='get-data-1'
    to='ladymacbeth@shakespeare.lit/castle'
    type='get'>
  <data xmlns='urn:xmpp:bob'
        cid='sha1+8f35fef110ffc5df08d579a50083ff9308fb6242@bob.xmpp.org'/>
</iq>

  

<iq from='ladymacbeth@shakespeare.lit/castle'
    id='get-data-1'
    to='doctor@shakespeare.lit/pda'
    type='result'>
  <data xmlns='urn:xmpp:bob'
        cid='sha1+8f35fef110ffc5df08d579a50083ff9308fb6242@bob.xmpp.org'
        max-age='86400'
        type='image/png'>
    iVBORw0KGgoAAAANSUhEUgAAAAoAAAAKCAYAAACNMs+9AAAABGdBTUEAALGP
    C/xhBQAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1FB9YGARc5KB0XV+IA
    AAAddEVYdENvbW1lbnQAQ3JlYXRlZCB3aXRoIFRoZSBHSU1Q72QlbgAAAF1J
    REFUGNO9zL0NglAAxPEfdLTs4BZM4DIO4C7OwQg2JoQ9LE1exdlYvBBeZ7jq
    ch9//q1uH4TLzw4d6+ErXMMcXuHWxId3KOETnnXXV6MJpcq2MLaI97CER3N0
    vr4MkhoXe0rZigAAAABJRU5ErkJggg==
  </data>
</iq>

  

6. Use Cases¶

<envelope xmlns='urn:xmpp:sce:1'>
  <content>
    <body xmlns='jabber:client'>[...]</body>
    <x xmlns='jabber:x:oob'>
      <url>https://en.wikipedia.org/wiki/Fight_Club#Plot</url>
    </x>
  </content>
</envelope>
    

<message from='narrator@jabber.org'
         to='viewer@jabber.org'>
  <encrypted xmlns='urn:xmpp:encryption:stub:sce:1'>
    <payload>
      PGNvbnRlbnQgeG1sbnM9J3Vybjp4bXBwOnNjZTowJz48cGF5bG9hZD48Ym9keSB4bWxucz0namFi
      YmVyOmNsaWVudCc+SSBnb3QgaW4gZXZlcnlvbmUncyBob3N0aWxlIGxpdHRsZSBmYWNlLiBZZXMs
      IHRoZXNlIGFyZSBicnVpc2VzIGZyb20gZmlnaHRpbmcuIFllcywgSSdtIGNvbWZvcnRhYmxlIHdp
      dGggdGhhdC4gSSBhbSBlbmxpZ2h0ZW5lZC48L2JvZHk+PHggeG1sbnM9J2phYmJlcjp4Om9vYic+
      PHVybD5odHRwczovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9GaWdodF9DbHViI1Bsb3Q8L3VybD48
      L3g+PC9wYXlsb2FkPjwvY29udGVudD4=
    </payload>
  </encrypted>
</message>
    

<envelope xmlns='urn:xmpp:sce:1'>
  <content>
    <data xmlns='urn:xmpp:bob'
        cid='sha1+8f35fef110ffc5df08d579a50083ff9308fb6242@bob.xmpp.org'/>
  </content>
  <from jid='doctor@shakespeare.lit/pda'/>
  <to jid='ladymacbeth@shakespear.lit/castle'/>
</envelope>

    

<iq from='doctor@shakespeare.lit/pda'
    id='get-data-1'
    to='ladymacbeth@shakespeare.lit/castle'
    type='get'>
  <encrypted xmlns='urn:xmpp:encryption:stub:sce:1'>
    <payload>
      V2FpdCwgd2hhdD8gQXJlIHlvdSBzZXJpb3VzPyBEaWQgeW91IHJlYWxseSBqdXN0IGdyYWIgeW91
      ciBmYXZvdXJpdGUgYmFzZTY0IGRlY29kZXIganVzdCB0byBjaGVjayB0aGlzIGRvY3VtZW50IGZv
      ciBoaWRkZW4gbWVzc2FnZXM/IFdoYXQgYXJlIHlvdSBzb21lIGtpbmQgb2YgbmVyZD8gU29tZSBn
      ZWVrIHdpdGggYSBiaW5hcnkgd3Jpc3Qgd2F0Y2g/
    </payload>
  </encrypted>
</iq>
    

<envelope xmlns='urn:xmpp:sce:1'>
  <content>
    <data xmlns='urn:xmpp:bob'
        cid='sha1+8f35fef110ffc5df08d579a50083ff9308fb6242@bob.xmpp.org'
        max-age='86400'
        type='image/png'>
    iVBORw0KGgoAAAANSUhEUgAAAAoAAAAKCAMAAAC67D+PAAAAclBMVEUAAADYZArfaA9GIAoBAAGN
    QA3MXgniaAiEOgZMIATDXRXZZhHUZBHIXhDrbQ6sUQ7OYA2TRAubRwqMQQq7VQlKHgMAAAK5WRfJ
    YBOORBFoMBCwUQ/ycA6FPgvbZQpeKglNJQmrTQeOPgQyFwR6MwACAABRPE/oAAAAW0lEQVQI1xXI
    Rw6EMBTAUP8kJKENnaF37n9FQPLCekAgzklhgCwfrlNHEXhrvCsxaU/SwLGAFuIWZFpBERtKm9Xf
    JqH+vVWh4POqgHrsAtht095b+geYRSl57QHSPgP3+CwvAAAAAABJRU5ErkJggg==
    </data>
  </content>
  <from jid='ladymacbeth@shakespear.lit/castle'/>
  <to jid='doctor@shakespeare.lit/pda'/>
</envelope>
    

<iq from='ladymacbeth@shakespeare.lit/castle'
    id='get-data-1'
    to='doctor@shakespeare.lit/pda'
    type='result'>
  <encrypted xmlns='urn:xmpp:encryption:stub:sce:1'>
    <payload>
      PGNvbnRlbnQgeG1sbnM9J3Vybjp4bXBwOnNjZTowJz4KICA8cGF5bG9hZD4KICAgIDxkYXRhIHht
      bG5zPSd1cm46eG1wcDpib2InCiAgICAgICAgY2lkPSdzaGExKzhmMzVmZWYxMTBmZmM1ZGYwOGQ1
      NzlhNTAwODNmZjkzMDhmYjYyNDJAYm9iLnhtcHAub3JnJwogICAgICAgIG1heC1hZ2U9Jzg2NDAw
      JwogICAgICAgIHR5cGU9J2ltYWdlL3BuZyc+CiAgICBpVkJPUncwS0dnb0FBQUFOU1VoRVVnQUFB
      QW9BQUFBS0NBTUFBQUM2N0QrUEFBQUFjbEJNVkVVQUFBRFlaQXJmYUE5R0lBb0JBQUdOCiAgICBR
      QTNNWGduaWFBaUVPZ1pNSUFURFhSWFpaaEhVWkJISVhoRHJiUTZzVVE3T1lBMlRSQXViUndxTVFR
      cTdWUWxLSGdNQUFBSzVXUmZKCiAgICBZQk9PUkJGb01CQ3dVUS95Y0E2RlBndmJaUXBlS2dsTkpR
      bXJUUWVPUGdReUZ3UjZNd0FDQUFCUlBFL29BQUFBVzBsRVFWUUkxeFhJCiAgICBSdzZFTUJUQVVQ
      OGtKS0VObmFGMzduOUZRUExDZWtBZ3prbGhnQ3dmcmxOSEVYaHJ2Q3N4YVUvU3dMR0FGdUlXWkZw
      QkVSdEttOVhmCiAgICBKcUgrdlZXaDRQT3FnSHJzQXRodDA5NWIrZ2VZUlNsNTdRSFNQZ1AzK0N3
      dkFBQUFBQUJKUlU1RXJrSmdnZz09CiAgICA8L2RhdGE+CiAgPC9wYXlsb2FkPgogIDxmcm9tIGpp
      ZD0nbGFkeW1hY2JldGhAc2hha2VzcGVhci5saXQvY2FzdGxlJy8+CiAgPHRvIGppZD0nZG9jdG9y
      QHNoYWtlc3BlYXJlLmxpdC9wZGEnLz4KPC9jb250ZW50Pgo=
    </payload>
  </encrypted>
</iq>
    

7. Sending an encrypted stanza¶

In order to send an encrypted stanza without leaking extension elements, the sender prepares the stanza by placing the sensitive extension elements inside a <content/> element and that inside an <envelope/> element. Sensitive extension elements are those elements that are not mentioned explicitly in Server-processed Elements.

Depending on the encryption-specific SCE-profile, some affix elements are added as child elements of the <envelope/> element.

The <envelope/> element is then serialized into XML and encrypted using the SCE-specific profile of the encryption mechanism in place. The result is appended to the stanza.

In case of a message stanza, a fallback <body/> MUST NOT be added to the message. Because of that, the sender appends an unencrypted <store/> hint as specified in Message Processing Hints (XEP-0334) [7].

The sender appends an unencrypted <encryption/> element as specified in Explicit Message Encryption (XEP-0380) [8]..

The stanza can then be sent to the recipient.

8. Receiving an encrypted stanza¶

The recipient of the stanza decrypts its encrypted payload. The result is the <envelope/> element containing the <content/> element and the affix elements as direct child elements. Depending on the affix profiles specified by the used encryption protocol, the affix elements are verified to prevent certain attacks from taking place.

Afterwards, the extension elements inside the <content/> element are checked against the permitted list and any disallowed elements are discarded.

As a last step, the original unencrypted stanza is recreated by replacing the <envelope/> element of the stanza with the elements inside of the <content/> element.

9. Server-processed Elements¶

There are certain extension elements which are required to be available to the server in order to do stanza routing and processing. Additionally there are some elements that MUST be filtered by the server. Allowing for those elements to be included in, and parsed from the encrypted payload would allow a malicious client to perform a number of attacks.

Contrary to this, other elements are considered sensitive and MUST NOT be available in plaintext outside the <envelope/> element.

Below is a non-exhaustive list of elements that are definitely forbidden inside the <envelope/> element and permitted as direct child elements of the message. This list is completemented by a list provided by the registrar.

Elements listed there MUST NOT be included in <content/> elements and instead be sent in plain as children of the root stanza. Receiving clients MUST discard elements in that list if found inside of a <content/> element.

10. Business Rules¶

Unencrypted <envelope/> elements are NOT ALLOWED as child elements of the stanza and MUST be dropped.

Elements in the <content/> element MUST be identified using an element name and namespace. Notably the <body/> element MUST contain a valid namespace (i.e. "jabber:client").

The recipient MUST verify that the decrypted <envelope/> element contains valid XML before processing it any further. Invalid XML MUST be rejected.

After verifying the integrity of the <envelope/> element, the recipient needs to make sure that no server-processed elements are found inside of it. Any forbidden elements MUST be dropped before the message is processed any further.

Furthermore the receiving client MUST ignore any extension elements considered as sensitive which are found outside of the <envelope/> element, especially as direct unencrypted child elements of the enclosing stanza.

Since a chat message encrypted with SCE MUST NOT contain a <body/> element, it is not eligible for MAM message storage (Message Archive Management (XEP-0313) [11]). Therefore sending entities MUST append an unencrypted Message Processing Hints (XEP-0334) [7] <store/> hint as a direct child element to the message.

11. Implementation Notes¶

12. Security Considerations¶

For the sake of simplicity, the examples in this document are not encrypted. A real-world implementation MUST make use of real cryptographic protocols.

13. XMPP Registrar Considerations¶

The registrar provides a list of server-processed elements to complement Server-processed Elements.

The list consists of the namespace, the tag name or names, as well as a description giving the reason why the element(s) are to be exlusively server-processed.

14. XML Schema¶

<?xml version='1.0' encoding='UTF-8'?>
<xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema'
           targetNamespace='urn:xmpp:sce:1'
           xmlns='urn:xmpp:sce:1'>

    <xs:element name='envelope'>
        <xs:complexType>
            <xs:all>
                <xs:element ref='content'/>
                <xs:element ref='rpad' minOccurs='0' maxOccurs='1'/>
                <xs:element ref='time' minOccurs='0' maxOccurs='1'/>
                <xs:element ref='to' minOccurs='0' maxOccurs='1'/>
                <xs:element ref='from' minOccurs='0' maxOccurs='1'/>
                <!-- additional encryption protocol-specific affix elements -->
            </xs:all>
        </xs:complexType>
    </xs:element>

    <xs:element name='content'>
        <xs:complexType>
            <xs:sequence>
                <!-- all kinds of extension elements -->
                <xs:any minOccurs="0"/>
            </xs:sequence>
        </xs:complexType>
    </xs:element>

    <xs:element name='rpad' type='xs:string'/>

    <xs:element name='time'>
        <xs:complexType>
            <xs:attribute name='stamp' type='xs:string' use='required'/>
        </xs:complexType>
    </xs:element>

    <xs:element name='to'>
        <xs:complexType>
            <xs:attribute name='jid' type='xs:string' use='required'/>
        </xs:complexType>
    </xs:element>

    <xs:element name='from'>
        <xs:complexType>
            <xs:attribute name='jid' type='xs:string' use='required'/>
        </xs:complexType>
    </xs:element>
</xs:schema>

15. Acknowledgements¶

Big thanks to the authors of OpenPGP for XMPP (XEP-0373) [2] (Florian Schmaus, Dominik Schürmann and Vincent Breitmoser) which heavily inspired the idea of this protocol.

Also thanks to Marvin Wißfeld, Tim Henkes, Daniel Gultsch, Melvin Keskin and Andreas Straub for their feedback.

Appendices

Appendix A: Document Information¶

Series

XEP

Number

0420

Publisher

XMPP Standards Foundation

Status

Experimental

Type

Standards Track

Version

0.5.0

Last Updated

2026-06-23

Approving Body

XMPP Council

Dependencies

XMPP Core, XEP-0082, XEP-0334, XEP-0380

Supersedes

None

Superseded By

None

Short Name

SCE

Source Control

HTML

This document in other formats: XML  PDF

Appendix B: Author Information¶

Paul Schaub

Email

vanitasvitae@riseup.net

JabberID

vanitasvitae@jabberhead.tk

Tim Henkes

Email

me@syndace.dev

JabberID

me@syndace.dev

Appendix C: Legal Notices¶

Appendix D: Relation to XMPP¶

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Appendix E: Discussion Venue¶

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <https://xmpp.org/community/> for a complete list.

Errata can be sent to <editor@xmpp.org>.

Appendix F: Requirements Conformance¶

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Appendix G: Notes¶

Appendix H: Revision History¶

Note: Older versions of this specification might be available at https://xmpp.org/extensions/attic/

1. Version 0.5.0 (2026-06-23)¶

   The time affix uses the DateTime profile of XEP-0082

   Longer rpads MUST NOT be rejected

   Add a minimum size target for random padding to add resistance against potential correlation attacks in case of short content and 0-length rpad

   Removed unhelpful Implementation Note warning about injection of decrypted stanzas

   Clarify fallback body policy

   Fix descriptions to apply to all stanzas instead of just messages

   Remove questionable SHOULD in the time affix handling and clarify the affix'es verification

   Request the registrar to provide a list of exclusively server-processed elements

   List XEP dependencies

   Add XML schema

   syndace
2. Version 0.4.1 (2021-11-18)¶

   Clarify bare JID usage and improve sentences:

   • Clarify usage of bare JIDs for affix elements
   • Improve and correct sentences about affix elements
   melvo
3. Version 0.4.0 (2021-04-07)¶

   Use 'envelope' and 'content' consistently by renaming elements

   Update namespace to urn:xmpp:sce:1

   melvo
4. Version 0.3.2 (2021-03-04)¶

   Cross-document editorial adjustments for inclusive language.

   mw
5. Version 0.3.1 (2020-11-03)¶

   Fix misspelling of 'whose'

   melvo
6. Version 0.3.0 (2020-07-03)¶

   Allow origin-id elements, disallow stanza-id and extended stanza addressing elements inside the payload element

   Clarify wording on stanza processed elements and improve XEP formatting

   Remove limitation of random padding content to base64 characters alone

   Chat messages MUST contain message processing store hint

   Credit where credit is due

   ps
7. Version 0.2.0 (2019-10-04)¶

   Specify IQ encryption

   Add examples and addenda

   ps
8. Version 0.1.0 (2019-07-30)¶
   Accepted by vote of Council on 2019-06-26.
   XEP Editor (jsc)
9. Version 0.0.1 (2019-06-03)¶

   First draft.

   ps

Appendix I: Bib(La)TeX Entry

@report{schaub2019sce,
  title = {Stanza Content Encryption},
  author = {Schaub, Paul and Henkes, Tim},
  type = {XEP},
  number = {0420},
  version = {0.5.0},
  institution = {XMPP Standards Foundation},
  url = {https://xmpp.org/extensions/xep-0420.html},
  date = {2019-06-03/2026-06-23},
}

END