protoXEP OpenPGP for XMPP Pubsub: version 0.0.6

- add forgotten "jid" and "node" attribute to <revoke/>
- clarify that <openpgp/> wrapper is used

inbox/pubsub-encryption.xml

@@ -30,6 +30,17 @@
     <email>goffi@goffi.org</email>
     <jid>goffi@jabber.fr</jid>
   </author>
+  <revision>
+    <version>0.0.6</version>
+    <date>2022-10-12</date>
+    <initials>jp</initials>
+    <remark>
+      <ul>
+        <li>add forgotten "jid" and "node" attribute to &lt;revoke/&gt;</li>
+        <li>clarify that &lt;openpgp/&gt; wrapper is used</li>
+      </ul>
+    </remark>
+  </revision>
   <revision>
     <version>0.0.5</version>
     <date>2022-10-12</date>
@@ -130,7 +141,7 @@
   </section2>
 
   <section2 topic='Transmit Shared Secret' anchor='transmit_secret'>
-    <p>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 &lt;signcrypt/&gt; as specified in <link url='https://xmpp.org/extensions/xep-0373.html#exchange'>XEP-0373 "Exchanging OpenPGP Encrypted and Signed Data"</link>. The encrypted payload of the &lt;signcrypt/&gt; MUST contain a &lt;shared-secret/&gt; element qualified by the 'urn:xmpp:openpgp:pubsub:0' namespace. This element MUST have the following attributes:</p>
+    <p>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 &lt;openpgp/&gt; element wrapping a &lt;signcrypt/&gt; as specified in <link url='https://xmpp.org/extensions/xep-0373.html#exchange'>XEP-0373 "Exchanging OpenPGP Encrypted and Signed Data"</link>. The encrypted payload of the &lt;signcrypt/&gt; MUST contain a &lt;shared-secret/&gt; element qualified by the 'urn:xmpp:openpgp:pubsub:0' namespace. This element MUST have the following attributes:</p>
     <ul>
       <li>a 'timestamp' attribute whose value is the datetime of the shared key generation. Datetime format is specified in &xep0082;.</li>
       <li>a 'jid' attribute with bare JID of the pubsub/PEP service;</li>
@@ -169,18 +180,19 @@
 
   <section2 topic='Revocation and Shared Secret Rotation' anchor='revocation_rotation'>
     <p>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.</p>
-    <p>To rotate a key, a &MESSAGE; must be sent to all people which got the shared secret. The &MESSAGE; MUST contain a XEP-0373 &lt;signcrypt/&gt; element whose payload is an encrypted &lt;revoke/&gt; 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 &lt;revoke/&gt; element MAY have one or more &lt;reason/&gt; child element(s) which contain a human readable message explaining the reason of the revocation. The &lt;reason/&gt; element MAY contain an 'xml:lang' attribute with the language code of the text, and there MAY be several &lt;reason/&gt; elements if and only if they have distinct xml:lang. A revoked key MUST NOT be used to encrypt new items.</p>
+    <p>To rotate a key, a &MESSAGE; must be sent to all people which got the shared secret. The &MESSAGE; MUST contain a XEP-0373 &lt;openpgp/&gt; element with a &lt;signcrypt/&gt; element whose payload is an encrypted &lt;revoke/&gt; 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.</p>
+    <p>Optionally, the &lt;revoke/&gt; element MAY have one or more &lt;reason/&gt; child element(s) which contain a human readable message explaining the reason of the revocation. The &lt;reason/&gt; element MAY contain an 'xml:lang' attribute with the language code of the text, and there MAY be several &lt;reason/&gt; elements if and only if they have distinct xml:lang. A revoked key MUST NOT be used to encrypt new items.</p>
     <p>Then a new shared secret MUST be generated and transmitted to all participants (excluding those who have seen their access revoked) as explained in <link url='#transmit_secret'>Transmit Shared Secret.</link></p>
     <p>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).</p>
   <p>
     Following example only show the &lt;revoke/&gt; element, as it is normally put as an encrypted payload of &xep0373; &lt;signcrypt/&gt; payload.
 </p>
   <example caption="revoke element (normally encrypted as part of XEP-0373's signcrypt payload)"><![CDATA[
-  <revoke xmlns='urn:xmpp:openpgp:pubsub:0' id='1234-abcd-5678-efgh'>
+  <revoke xmlns='urn:xmpp:openpgp:pubsub:0' jid='pubsub.capulet.lit' node='123abc' id='1234-abcd-5678-efgh'>
     <reason>Revoked access from an entity</reason>
   </revoke>
   ]]></example>
-    <p>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.</p>
+    <p>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.</p>
     <p>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 <link url='#transmit_secret'>Transmit Shared Secret.</link>) along with the currently used shared secret. This allows the new entity to decrypt the items encrypted with the old keys. The &lt;shared-secret/&gt; 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).</p>
   </section2>