18
edits
Difference between revisions of "XEP-Remarks/XEP-0373: OpenPGP for XMPP"
Jump to navigation
Jump to search
XEP-Remarks/XEP-0373: OpenPGP for XMPP (view source)
Revision as of 19:54, 30 August 2018
, 19:54, 30 August 2018Add new secret key node ideas
(Add note about Singleton Node) |
(Add new secret key node ideas) |
||
| Line 8: | Line 8: | ||
* 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 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 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 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 | |||
* 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. | 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. | ||