XEP-Remarks/XEP-0373: OpenPGP for XMPP

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)

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.