mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-21 16:55:07 -05:00
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
parent
19a87bfc38
commit
8c41ff5c61
@ -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 <revoke/></li>
|
||||
<li>clarify that <openpgp/> 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 <signcrypt/> 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 <signcrypt/> MUST contain a <shared-secret/> 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 <openpgp/> element wrapping a <signcrypt/> 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 <signcrypt/> MUST contain a <shared-secret/> 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 <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.</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 <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.</p>
|
||||
<p>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.</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 <revoke/> element, as it is normally put as an encrypted payload of &xep0373; <signcrypt/> 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 <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).</p>
|
||||
</section2>
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user