protoXEP OpenPGP for XMPP Pubsub: version 0.0.3

- Base64 is not needed for the key (it's a passphrase)
- Specify that as least on <message/> should be encrypted for sender other devices
- Recommend minimum length for shared secret

inbox/pubsub-encryption.xml

@@ -30,6 +30,18 @@
     <email>goffi@goffi.org</email>
     <jid>goffi@jabber.fr</jid>
   </author>
+  <revision>
+    <version>0.0.3</version>
+    <date>2022-10-10</date>
+    <initials>jp</initials>
+    <remark>
+      <ul>
+        <li>Base64 is not needed for the key (it's a passphrase)</li>
+        <li>Specify that as least on &MESSAGE; should be encrypted for sender other devices</li>
+        <li>Recommend minimum length for shared secret</li>
+      </ul>
+    </remark>
+  </revision>
   <revision>
     <version>0.0.2</version>
     <date>2022-10-10</date>
@@ -72,7 +84,7 @@
 
   <section2 topic='Encrypting Pubsub Item' anchor='encrypt'>
     <p>Juliet wants to create a private blog (using &xep0277;) that she only share with her confidante and her lover. To make sure that her family, who manages her XMPP server, can't read the content, she want to use end-to-end encryption.</p>
-    <p>To do so, her client generates a "shared secret" by generating a cryptographically strong key that will be used to symmetrically encrypt new items. This key MUST be associated with an ID, which MUST be an unique sequence of characters usable in an XML attribute. She will later share this key with entities allowed to access the blog as explained below.</p>
+    <p>To do so, her client creates a "shared secret" by generating a cryptographically strong key that will be used to symmetrically encrypt new items. This key MUST be associated with an ID, which MUST be an unique sequence of characters usable in an XML attribute. She will later share this key with entities allowed to access or publish on the blog as explained below.</p>
     <p>From now on, all items that Juliet publishes on the node SHOULD be symmetrically encrypted with the shared secret by using OpenPGP symmetric encryption.</p>
     <p>To publish an encrypted item, an &lt;encrypted/&gt; element qualified by the 'urn:xmpp:openpgp:pubsub:0' namespace MUST be used as payload. This element MUST contain a 'secret' attribute whose value is the ID of the shared secret used. The content of the element is a base64 encoded Symmetric-Key Encrypted Session Key Packet as specified at <cite>RFC 4880</cite> <link url='http://tools.ietf.org/html/rfc4880#section-5.3'>§ 5.3</link> (in a similar way as <link url='https://xmpp.org/extensions/xep-0373.html#backup-encryption'>secret key backup is encoded in XEP-0373</link>). The encrypted content is the item payload that would normally be used.</p>
     <p>The encrypted node SHOULD have a "whitelist" access model as specified in &xep0060;. Juliet's client ensure that either by creating a new node with suitable access model, or by changing the access model of existing node.</p>
@@ -105,7 +117,8 @@
       <li>if the key is revoked (due to <link url='#revocation_rotation'>shared secret rotation</link>), it must have a 'revoked' attribute with the value "true".</li>
     </ul>
       <p>The &lt;shared-secret/&gt; SHOULD have a 'type' attribute whose value is the pubsub#type that the node would have if it were plain text (i.e. the semantic type information of decrypted data in the node, usually the namespace of the decrypted payload). </p>
-    <p>The content of the &lt;shared-secret/&gt; element MUST be the base64 encoded shared secret.</p>
+    <p>The content of the &lt;shared-secret/&gt; element MUST be the shared secret (i.e. the passphrase used to symmetrically encode items).</p>
+    <p>She send messages with the encrypted shared secret to her nurse, Romeo and herself (so her other devices get the shared secret too).</p>
     <p>Entities MUST always use the most recently generated shared secret to encrypt new items (the 'timestamp' attribute is used to check generation date and time).</p>
 
   <p>
@@ -119,7 +132,7 @@
     id='1234-abcd-5678-efgh'
     type='http://www.w3.org/2005/Atom'
     >
-    <!-- BASE64_ENCODED_SHARED_SECRET -->
+    ZSRD5lK9mz-5VHNyu2N1XLiJZ8I87jkv85ceZkVrOGA
   </shared-secret>
   ]]></example>
 
@@ -151,8 +164,10 @@
 </section1>
 
 <section1 topic='Business Rules' anchor='rules'>
+  <p>The shared secret and revocation SHOULD be generated by node owner.</p>
+  <p>&MESSAGE; with encrypted &lt;shared-secret/&gt; or &lt;revoke/&gt; elements MUST be sent to everybody who must have access to the node. At least one of the encrypted payload SHOULD be encrypted for the sender themselves (either by sending the &MESSAGE; directly to the sender, or to decrypt a copy received with &xep0280;), so other devices of the sender can get the shared secret too.</p>
   <p>When &xep0470; are used, the attachment node SHOULD have the same access model (i.e. whitelist as recommended in <link url="#security">Security Considerations</link>) as the encrypted node, with authorized entities synchronized (this should be done automatically for <link url='https://xmpp.org/extensions/xep-0470.html#full-compliance'>fully compliant services</link>). The items published to attachment node itself MUST be encrypted using this protocol. Due to <link url='https://xmpp.org/extensions/xep-0470.html#validity-check'>validity check of attachment items</link>, the encrypted element MUST be a child of a XEP-0470's &lt;attachments/&gt; element, instead of being the &lt;item/&gt; payload as usual. Note that this will prevent the <link url="https://xmpp.org/extensions/xep-0470.html#summary-node">summary feature</link> to work with encrypted elements, and the end-user client will have to do the summary itself, this is an inevitable trade-off when using e2ee.</p>
-  <p>The "pubsub#type" of an encrypted item is always "urn:xmpp:openpgp:pubsub:0", thus no information is leaked on the content of the node, and all encrypted node can easily be retrieved by using &xep0462;.</p>
+  <p>The "pubsub#type" of an encrypted item is always "urn:xmpp:openpgp:pubsub:0", thus no information is leaked on the content of the node, and all encrypted nodes can easily be retrieved by using &xep0462;.</p>
   <p>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.</p>
 </section1>
 
@@ -188,6 +203,7 @@
     <li>To decrypt archives and future items, clients most probably cache plain text version of items, and shared secret. If one device with access to an encrypted node is compromised, all items from the node should be considered compromised, and shared secret should be rotated.</li>
     <li>For the same reason, client SHOULD encrypt data at rest (even if the device is stolen, data should not be accessible without some cryptographic key).</li>
     <li>Note that only the shared key sender is authenticated (by &xep0373;'s &lt;signcrypt/&gt;), not the items publishers, meaning that encrypted items could be published by anybody in possession of the shared secret. Pubsub items authentication will be treated in a separated XEP.</li>
+    <li>The shared secret should be long enough to avoid brute force attacks. A secret of at least 32 characters is recommended.</li>
   </ul>
 </section1>