protoXEP OpenPGP for XMPP Pubsub: version 0.0.6

- add forgotten "jid" and "node" attribute to <revoke/>
- clarify that <openpgp/> wrapper is used
This commit is contained in:
Jérôme Poisson 2022-10-12 14:35:50 +02:00
parent 19a87bfc38
commit 8c41ff5c61
1 changed files with 16 additions and 4 deletions

View File

@ -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>