XEP-0473: OpenPGP for XMPP Pubsub

1. Introduction¶

Publish-Subscribe (XEP-0060) [1] and Personal Eventing Protocol (XEP-0163) [2] are widely used XMPP features. However, items are published in plain text, making them readable by server administrators or anybody having administrator level access on the pubsub/PEP services.

Although this is not a problem for data intended to be published publicly, there are many cases where it may be desirable to make the data inaccessible to anybody but the selected recipients, or in other words to end-to-end encrypt the data.

This specification aims to provide an easy way to e2e encrypt items of a pubsub node, and to share access with other entities. It is compatible with all existing pubsub/PEP features, which makes it possible to use securily features such a geolocation, private blogs, private calendar events, data forms, etc.

2. Requirements¶

The design goals of this XEP are:

• work with basic standard pubsub/PEP service, no extra feature needed;
• be generic and work with any protocol using pubsub: once decrypted, the items should be parsable as if they were plain text;
• be able to share with other entities the means to decipher the elements;
• be able to easily share the means of decrypting items with new entities, even after the items have been published;
• be able to modify the means of decryption to make the new elements inaccessible to certain entities even if they have had access to the previous elements;

3. Glossary¶

• e2ee: end-to-end encryption
• Shared Secret: a cryptographically strong random string used to symmetrically encrypt items
• Encrypted Node: pubsub node whose items are end-2-end encrypted using this protocol.

4. Overview¶

To encrypt a pubsub node, each item is symmetrically encrypted with a shared secret using OpenPGP symmetric encryption. The secret is shared with other entities using e2e encrypted messages with OpenPGP for XMPP (XEP-0373) [3]. If an entity's access is revoked or a shared secret may have been compromised, a new shared secret is generated and new items are encrypted with it.

5. Use Cases¶

<iq
  type='set'
  from='juliet@capulet.lit/chamber'
  to='pubsub.capulet.lit'
  id='encrypted1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='123abc'>
      <item id="encrypt_123">
        <encrypted xmlns='urn:xmpp:openpgp:pubsub:0' key='1234-abcd-5678-efgh'>
          <!-- BASE64_OPENPGP_SYMMETRICALLY_ENCRYPTED_ITEM -->
        </encrypted>
      </item>
    </publish>
  </pubsub>
</iq>

  <shared-secret
    xmlns='urn:xmpp:openpgp:pubsub:0'
    jid='pubsub.capulet.lit'
    node='123abc'
    id='1234-abcd-5678-efgh'
    timestamp='2022-10-10T13:24:31Z'
    type='http://www.w3.org/2005/Atom'
    >
    ZSRD5lK9mz-5VHNyu2N1XLiJZ8I87jkv85ceZkVrOGA
  </shared-secret>
  

  <revoke xmlns='urn:xmpp:openpgp:pubsub:0' jid='pubsub.capulet.lit' node='123abc' id='1234-abcd-5678-efgh'>
    <reason>Revoked access from an entity</reason>
  </revoke>
  

6. Business Rules¶

The shared secret and revocation SHOULD be generated by node owner.

<message/> with encrypted <shared-secret/> or <revoke/> elements MUST be sent to everybody who must have access to the node. At least one of the encrypted payload SHOULD be encrypted for the sender themselves (either by sending the <message/> directly to the sender, or to decrypt a copy received with Message Carbons (XEP-0280) [6]), so other devices of the sender can get the shared secret too.

When Pubsub Attachments (XEP-0470) [7] are used, the attachment node SHOULD have the same access model (i.e. whitelist as recommended in Security Considerations) as the encrypted node, with authorized entities synchronized (this should be done automatically for fully compliant services). The items published to attachment node itself MUST be encrypted using this protocol. Due to validity check of attachment items, the encrypted element MUST be a child of a XEP-0470's <attachments/> element, instead of being the <item/> payload as usual. Note that this will prevent the summary feature to work with encrypted elements, and the end-user client will have to do the summary itself, this is an inevitable trade-off when using e2ee.

The "pubsub#type" of an encrypted item is always "urn:xmpp:openpgp:pubsub:0", thus no information is leaked on the content of the node, and all encrypted nodes can easily be retrieved by using PubSub Type Filtering (XEP-0462) [8].

Note that encrypted items MAY be mixed with plain text items: for instance if a blog is public, but some of its items are private. However the proper handling of this use case is out of scope of this specification.

7. Implementation Notes¶

This specification uses OpenPGP for XMPP (XEP-0373) [3] independently of OpenPGP for XMPP Instant Messaging (XEP-0374) [9], implementations SHOULD avoid double encryption (e.g. by excluding <openpgp/> element qualified by 'urn:xmpp:openpgp:0' namespace from encryption by XEP-0374 implementation), and MUST ensure that element is correctly decrypted. Double encryption should be checked, and the <openpgp/> element MUST be decrypted even if OXIM (XEP-0374) is not being used.

8. Discovering Support¶

If a client supports the protocol specified in this XEP, it MUST advertise it by including the "urn:xmpp:openpgp:pubsub:0" discovery feature in response to a Service Discovery (XEP-0030) [10] information request:

<iq type='get'
    from='juliet@example.org/balcony'
    to='romeo@example.org/orchard'
    id='disco1'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

<iq type='result'
    from='romeo@example.org/orchard'
    to='juliet@example.org/balcony'
    id='disco1'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    ...
    <feature var='urn:xmpp:openpgp:pubsub:0'/>
    ...
  </query>
</iq>

9. Security Considerations¶

• When receiving a <shared-secret/> or a <revoke/> element, the receiving client MUST ensure that the signing sender is the same as the one for all known shared secrets of this pubsub node (usually a node owner). This prevents a malicious actor for misleading the client into using a non-legitimate secret.
• To limit the surface of attack, the access model of an encrypted node should be set to "whitelist" and only people having the shared key should be allowed to retrieve encrypted items.
• If the shared key is compromised, or a user access is revoked, the key MUST be rotated. However, only new items are encrypted with the new key, any previous item should be considered as compromised too.
• Sometimes client may use metadata to construct item ID, this is notably the case for some Microblogging Over XMPP (XEP-0277) [4] implementation, as the resulting item ID is used to generate user friendly URLs. To avoid metadata leakage, clients SHOULD NOT derivate the item ID from any data of the item when pubsub encryption is used.
• Some protocols define prefixes for nodes, this is for instance the case for XEP-0277 Comments. If the prefix is not essential to make the feature work (which is the case for XEP-0277 comments), the client SHOULD NOT use the usual prefix to avoid leaking informations on the content of the node. The prefix defined in Pubsub Attachments (XEP-0470) [7] MUST be used as usually, as it is essential to retrieve the attachment node, and it's generic and thus doesn't leak information on the node content.
• To decrypt archives and future items, clients most probably cache plain text version of items, and shared secret. If one device with access to an encrypted node is compromised, all items from the node should be considered compromised, and shared secret should be rotated.
• For the same reason, client SHOULD encrypt data at rest (even if the device is stolen, data should not be accessible without some cryptographic key).
• Note that only the shared key sender is authenticated (by OpenPGP for XMPP (XEP-0373) [3]'s <signcrypt/>), not the items publishers, meaning that encrypted items could be published by anybody in possession of the shared secret. Pubsub items authentication will be treated in a separated XEP.
• The shared secret should be long enough to avoid brute force attacks. A secret of at least 32 characters is recommended.

10. IANA Considerations¶

TODO

11. XMPP Registrar Considerations¶

TODO

12. XML Schema¶

TODO

13. Acknowledgements¶

Thanks to Tim Henkes for his advices and NLNet foundation/NGI0 Discovery for funding.

Appendices

Appendix A: Document Information¶

Series

XEP

Number

0473

Publisher

XMPP Standards Foundation

Status

Experimental

Type

Standards Track

Version

0.1.0

Last Updated

2022-12-13

Approving Body

XMPP Council

Dependencies

XMPP Core, XEP-0001, XEP-0004, XEP-0060, XEP-0373

Supersedes

None

Superseded By

None

Short Name

oxps

Source Control

HTML

This document in other formats: XML  PDF

Appendix B: Author Information¶

Jérôme Poisson

Email

goffi@goffi.org

JabberID

goffi@jabber.fr

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 following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

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.1.0 (2022-12-13)¶
   Accepted by vote of Council on 2022-10-19.
   XEP Editor (jsc)
2. Version 0.0.6 (2022-10-12)¶
   • add forgotten "jid" and "node" attribute to <revoke/>
   • clarify that <openpgp/> wrapper is used
   jp
3. Version 0.0.5 (2022-10-12)¶
   • add forgotten "timestamp" in example
   • add implementation node on double encryption
   • add clarification that sender should be a node owner
   jp
4. Version 0.0.4 (2022-10-11)¶
   • add a security note to indicate that <shared-secret/> and <revoke/> sender must be checked.
   jp
5. Version 0.0.3 (2022-10-10)¶
   • Base64 is not needed for the key (it's a passphrase)
   • Specify that as least on <message/> should be encrypted for sender other devices
   • Recommend minimum length for shared secret
   jp
6. Version 0.0.2 (2022-10-10)¶

   Remove useless references to XEP-0374 + acknowledgements

   jp
7. Version 0.0.1 (2022-10-09)¶

   First draft.

   jp

Appendix I: Bib(La)TeX Entry

@report{poisson2022oxps,
  title = {OpenPGP for XMPP Pubsub},
  author = {Poisson, Jérôme},
  type = {XEP},
  number = {0473},
  version = {0.1.0},
  institution = {XMPP Standards Foundation},
  url = {https://xmpp.org/extensions/xep-0473.html},
  date = {2022-10-09/2022-12-13},
}

END