From 19a87bfc38ed271d5a39f1b8c3664563d3150336 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Poisson?= Date: Wed, 12 Oct 2022 14:09:01 +0200 Subject: [PATCH] protoXEP OpenPGP for XMPP Pubsub: version 0.0.5 - add forgotten "timestamp" in example - add implementation node on double encryption - add clarification that sender should be a node owner --- inbox/pubsub-encryption.xml | 21 +++++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/inbox/pubsub-encryption.xml b/inbox/pubsub-encryption.xml index 42e6a02d..00235b07 100644 --- a/inbox/pubsub-encryption.xml +++ b/inbox/pubsub-encryption.xml @@ -31,9 +31,21 @@ goffi@jabber.fr - 0.0.4 + 0.0.5 2022-10-12 jp + +
    +
  • add forgotten "timestamp" in example
    • +
  • add implementation node on double encryption
    • +
  • add clarification that sender should be a node owner
    • +
+ + + + 0.0.4 + 2022-10-11 + jp
  • add a security note to indicate that <shared-secret/> and <revoke/> sender must be checked.
    • @@ -140,6 +152,7 @@ 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 @@ -181,6 +194,10 @@

    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.

    + +

    This specification uses &xep0373; independently of &xep0374;, 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.

    +     +

    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 &xep0030; information request:

    @@ -206,7 +223,7 @@
      -
    • 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. This prevents a malicious actor for misleading the client into using a non-legitimate secret.
      • +
    • 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 &xep0277; 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.