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, secret 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 and one secret key item. Force all Clients to publish with the same item id "current" (XEP-0060) to prevent problems with multiple items in the node.

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.