XEP-Remarks/XEP-0373: OpenPGP for XMPP

This is a page for information about XEP-Remarks/XEP-0373: OpenPGP for XMPP, including errata, comments, questions, and implementation experience.

Key publication, notification and retrieval

The XEP has undergone already one change regarding key publication, notification and retrieval of key material. The initial used approach was found to be quite traffic demanding, because the full key data was pushed to interested entities every time they appeared online. Thus it was decided to split the key into metadata and data PubSub/PEP nodes.

While it turned out to work quite well, it is not elegant with regard to the mechanisms the involved protocols provide. From a pure "what the specification describes" pont-of-view, an ideal solution would possibly be to

• Use a single node per key type (public- / secret-key)
• Use XEP-0060 "notification only" nodes (configuration value: pubsub#deliver_payloads), which would only push the node id to the subscribed entity (but was only recently implemented in prosody and the feature is not discoverable, most likely because it appears to be mandatory by XEP-0060).
• Use a timestamp, possibly in XEP-0082 DateTime profile format, as item IDs

• Use a fixed string for the PubSub/PEP node names (like it is already done right now for the metadata nodes)

• Use Singleton Node (XEP-0060) for the metadata node, public key node. The option max_items=1 when retrieving the node content is an optional feature not supported by all servers. There is no need to have more than one item in these nodes, there should at any point always only one public key list, one public key per public key node. Force all Clients to publish with the same item id "current" (XEP-0060) to prevent problems with multiple items in the node.

• Consider to publishing one secret key per item with a item-id=fingerprint instead of concatenating multiple keys together
  • Problems with current XEP behavior:

    - Clients cannot know if their secret key is stored without pulling the payload and looking into it (A bad client could overwrite the key)

    - Clients have to pull from time to time the full secret key node, and look into the payload if their key ist still in storage

  • Upsides with new approach:

    - Clients can efficiently find out with a disco of the node if their secret key is still in storage

    - Clients can efficiently get a list of all secret keys + fingerprints, without pulling the payload and doing gpg operations

    - Clients can then ask the user which secret key should be pulled / they want to use

    - Less likely to run into a stanza size limit

  • Possible Downsides:

    - Clients should make sure to encrypt all secret keys with the same backup code for ease of use (they will have to ask the user for it)

• Mention that generating the PGP key with a password would lead to multiple password entrys for the user (once to restore the backup from the secret node, then a second time to use the key). To get broad adoption it should be as easy as possible, meaning no password on the key itself. Also it should be discouraged to use an already existing key which is used in other context than IM (like email), rather create a new key just for the IM context. This and the no password suggestion would lead to a much easier implementation because GPG Agent (no password on the key) is out of the picture and you dont have to deal with messages that can not be decrypted instantly but at a later point.

Although there appears to be no direct way to query the PubSub/PEP service if it supports pubsub#deliver_payloads, it may be possible for entities to probe the availability of this feature by attempting to create a "dummy" node where pubsub#deliver_payloads is set to true. IIRC recent changes to XEP-0060 require services to return an error on unknown configuration values. But this is fragile until this requirement is deployed widely. So ultimately, the entity possibly also wants to verify if setting has been respected and became effective.