From 8c41ff5c612b5dc22c9cb6d5e39583e9754bb4ae Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Poisson?= Date: Wed, 12 Oct 2022 14:35:50 +0200 Subject: [PATCH] protoXEP OpenPGP for XMPP Pubsub: version 0.0.6 - add forgotten "jid" and "node" attribute to - clarify that wrapper is used --- inbox/pubsub-encryption.xml | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/inbox/pubsub-encryption.xml b/inbox/pubsub-encryption.xml index 00235b07..d57ca7f5 100644 --- a/inbox/pubsub-encryption.xml +++ b/inbox/pubsub-encryption.xml @@ -30,6 +30,17 @@ goffi@goffi.org goffi@jabber.fr + + 0.0.6 + 2022-10-12 + jp + +
    +
  • add forgotten "jid" and "node" attribute to <revoke/>
    • +
  • clarify that <openpgp/> wrapper is used
    • +
+ + 0.0.5 2022-10-12 @@ -130,7 +141,7 @@ -

Now that Juliet has started to publish encrypted items on a blog, she wants to share the secret key with her confidante and her lover. To do so she uses a e2ee &MESSAGE; stanza by using a <signcrypt/> as specified in XEP-0373 "Exchanging OpenPGP Encrypted and Signed Data". The encrypted payload of the <signcrypt/> MUST contain a <shared-secret/> element qualified by the 'urn:xmpp:openpgp:pubsub:0' namespace. This element MUST have the following attributes:

+

Now that Juliet has started to publish encrypted items on a blog, she wants to share the secret key with her confidante and her lover. To do so she uses a e2ee &MESSAGE; stanza by using an <openpgp/> element wrapping a <signcrypt/> as specified in XEP-0373 "Exchanging OpenPGP Encrypted and Signed Data". The encrypted payload of the <signcrypt/> MUST contain a <shared-secret/> element qualified by the 'urn:xmpp:openpgp:pubsub:0' namespace. This element MUST have the following attributes:

  • a 'timestamp' attribute whose value is the datetime of the shared key generation. Datetime format is specified in &xep0082;.
  • a 'jid' attribute with bare JID of the pubsub/PEP service;
    • @@ -169,18 +180,19 @@

    If there is any doubt about the compromise of a shared secret or if access to the encrypted node is revoked for an entity, the shared secret SHOULD BE rotated.

    -

    To rotate a key, a &MESSAGE; must be sent to all people which got the shared secret. The &MESSAGE; MUST contain a XEP-0373 <signcrypt/> element whose payload is an encrypted <revoke/> element qualified by the 'urn:xmpp:openpgp:pubsub:0' namespace, which MUST have an 'id' attribute whose value is the shared secret ID. Optionally, the <revoke/> element MAY have one or more <reason/> child element(s) which contain a human readable message explaining the reason of the revocation. The <reason/> element MAY contain an 'xml:lang' attribute with the language code of the text, and there MAY be several <reason/> elements if and only if they have distinct xml:lang. A revoked key MUST NOT be used to encrypt new items.

    +

    To rotate a key, a &MESSAGE; must be sent to all people which got the shared secret. The &MESSAGE; MUST contain a XEP-0373 <openpgp/> element with a <signcrypt/> element whose payload is an encrypted <revoke/> element qualified by the 'urn:xmpp:openpgp:pubsub:0' namespace, which MUST have a 'jid' attribute whose value is the JID of the pubsub/PEP service where the node is, a 'node' attribute whose value is the name of the node, and an 'id' attribute whose value is the shared secret ID.

    +

    Optionally, the <revoke/> element MAY have one or more <reason/> child element(s) which contain a human readable message explaining the reason of the revocation. The <reason/> element MAY contain an 'xml:lang' attribute with the language code of the text, and there MAY be several <reason/> elements if and only if they have distinct xml:lang. A revoked key MUST NOT be used to encrypt new items.

    Then a new shared secret MUST be generated and transmitted to all participants (excluding those who have seen their access revoked) as explained in Transmit Shared Secret.

    Note that if an entity's access is revoked, it SHOULD also be removed from the node's whitelist (if "whitelist" has been used as access model as recommended).

    Following example only show the <revoke/> element, as it is normally put as an encrypted payload of &xep0373; <signcrypt/> payload.

    + Revoked access from an entity ]]> -

    Items published before the key rotation SHOULD NOT be re-encrypted as it would be resource intensive, and revoked entities may have made a copy.

    +

    Items published before the key rotation SHOULD NOT be re-encrypted as it would be resource intensive, and revoked entities may have made a copy anyway.

    When access to the shared secret is granted to a new entity, all previously used keys SHOULD be transmitted (with their 'revoked' attribute set to "true" as explained in Transmit Shared Secret.) along with the currently used shared secret. This allows the new entity to decrypt the items encrypted with the old keys. The <shared-secret/> elements can either be sent in the same encrypted payload of a single &MESSAGE;, or split into multiple encrypted &MESSAGE;, it's up to the implementation to decide which is better (keep in mind that too many shared secrets in a single message may reach the maximum stanza size limit at some point, even if this limit is not likely to be reached for most usual cases).