mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-21 16:55:07 -05:00
XEP-0384: Release version 0.8.0
Update to XEP-0420 version 0.4.0 and adjust namespace: * Replace SCE's old 'content' element by its new 'envelope' element * Replace SCE's old 'payload' element by its new 'content' element * Update SCE's namespace to 'urn:xmpp:sce:1' * Update namespace to 'urn:xmpp:omemo:2'
This commit is contained in:
Melvin Keskin
parent
36ee4ec0b2
commit
8b02d0e79a
50
xep-0384.xml
50
xep-0384.xml
@ -1,9 +1,9 @@
|
||||
<?xml version='1.0' encoding='UTF-8'?>
|
||||
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
||||
<!ENTITY content "<content/>">
|
||||
<!ENTITY envelope "<envelope/>">
|
||||
<!ENTITY payload "<payload/>">
|
||||
<!ENTITY % ents SYSTEM "xep.ent">
|
||||
<!ENTITY ns "urn:xmpp:omemo:1">
|
||||
<!ENTITY ns "urn:xmpp:omemo:2">
|
||||
<!ENTITY nsdevices "urn:xmpp:omemo:1:devices">
|
||||
<!ENTITY nsbundles "urn:xmpp:omemo:1:bundles">
|
||||
%ents;
|
||||
@ -57,6 +57,20 @@
|
||||
<email>xmpp@larma.de</email>
|
||||
<jid>jabber@larma.de</jid>
|
||||
</author>
|
||||
<revision>
|
||||
<version>0.8.0</version>
|
||||
<date>2020-11-05</date>
|
||||
<initials>melvo</initials>
|
||||
<remark>
|
||||
<p>Update to XEP-0420 version 0.4.0 and adjust namespace:</p>
|
||||
<ul>
|
||||
<li>Replace SCE's old 'content' element by its new 'envelope' element</li>
|
||||
<li>Replace SCE's old 'payload' element by its new 'content' element</li>
|
||||
<li>Update SCE's namespace to 'urn:xmpp:sce:1'</li>
|
||||
<li>Update namespace to 'urn:xmpp:omemo:2'</li>
|
||||
</ul>
|
||||
</remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.7.0</version>
|
||||
<date>2020-09-05</date>
|
||||
@ -98,7 +112,7 @@
|
||||
<li>Specify OMEMO encryption for XEP-0045 Multi-User Chats.</li>
|
||||
<li>Use XEP-0420: Stanza Content Encryption.</li>
|
||||
<li>Use AES256/CBC to encrypt SCE payload.</li>
|
||||
<li>Change namespace to <tt>&ns;</tt></li>
|
||||
<li>Change namespace to <tt>urn:xmpp:omemo:1</tt></li>
|
||||
<li>Use wrapping 'keys' element for key elements in 'header'.</li>
|
||||
<li>Define threat model</li>
|
||||
<li>Change the state back to Experimental</li>
|
||||
@ -495,12 +509,12 @@
|
||||
<p>
|
||||
In order to send a message, extension elements that are deemed sensible first have to be
|
||||
encrypted. For this purpose, extensions that are only intended to be accessible to the recipient
|
||||
are placed inside a &xep0420; &content; element, which is then encrypted using a message key.
|
||||
are placed inside a &xep0420; &envelope; element, which is then encrypted using a message key.
|
||||
For this reason OMEMO defines its own SCE profile.
|
||||
</p>
|
||||
<section3 topic='SCE Profile' anchor='sce'>
|
||||
<p>
|
||||
An OMEMO SCE &content; element
|
||||
An OMEMO SCE &envelope; element
|
||||
</p>
|
||||
<ul>
|
||||
<li>MUST contain an <rpad/> affix element. This is used to prevent an attacker from gaining insights about the content of a message based on the length of the ciphertext.</li>
|
||||
@ -508,21 +522,21 @@
|
||||
<li>SHOULD contain a <from/> affix element.</li>
|
||||
<li>MUST contain a <to/> affix element whenever a message is sent via a group chat (MUC/MIX). This is used to prevent the server from silently converting a group message into a private message and vice versa.</li>
|
||||
</ul>
|
||||
<example caption='Plaintext SCE content element'><![CDATA[
|
||||
<content xmlns='urn:xmpp:sce:0'>
|
||||
<payload>
|
||||
<example caption='Plaintext SCE envelope element'><![CDATA[
|
||||
<envelope xmlns='urn:xmpp:sce:1'>
|
||||
<content>
|
||||
<body xmlns='jabber:client'>
|
||||
Hello World!
|
||||
</body>
|
||||
</payload>
|
||||
</content>
|
||||
<rpad>...</rpad>
|
||||
<from jid='romeo@montague.lit'/>
|
||||
</content>]]>
|
||||
</envelope>]]>
|
||||
</example>
|
||||
</section3>
|
||||
<section3 topic='Encryption' anchor='encrypt'>
|
||||
<p>
|
||||
The &content; element is encrypted as described in the section about <link url='#protocol-message_encryption'>Message Encryption</link>.
|
||||
The &envelope; element is encrypted as described in the section about <link url='#protocol-message_encryption'>Message Encryption</link>.
|
||||
</p>
|
||||
<p>
|
||||
Clients MUST only consider the devices on the <tt>&nsdevices;</tt> node of each recipient (i.e. including their own devices node, but excluding itself).
|
||||
@ -533,7 +547,7 @@
|
||||
An OMEMO encrypted message is specified to include an <encrypted> element in the <tt>&ns;</tt> namespace. It contains up to two child nodes, the <header> and the &payload; element. The <header> element must always be present, the &payload; element must be present unless an empty OMEMO message is sent, as described below.
|
||||
The <header> element has an attribute named 'sid' referencing the device id of the sending device and contains one or multiple <keys> elements, each with an attribute 'jid' of one of the recipients bare JIDs, as well as one or multiple <key> elements.
|
||||
A <key> element has an attribute named 'rid' referencing the device id of the recipient device, and an attribute named 'kex' which defaults to 'false' and indicates if the enclosed encrypted message includes a key exchange. The key and HMAC encrypted using the long-standing OMEMO session for that recipient device are encoded using base64 and placed as text content into the <key> element.
|
||||
The encrypted &content; element is encoded using base64 and placed as text content into the &payload; element.
|
||||
The encrypted &envelope; element is encoded using base64 and placed as text content into the &payload; element.
|
||||
</p>
|
||||
<!-- TODO: <p>Note that following &rfc6120; (section 8.4.), clients MUST ignore XML attributes and elements that are qualified with an unknown namespace, in order to allow for protocol extensions.</p> (qualified attributes are evil, right?) -->
|
||||
<p>A special case are <em>empty</em> OMEMO messages, which are used in various places throughout the protocol purely to manage sessions and not to transfer content. With empty OMEMO messages, the step of creating and encrypting the &payload; element is skipped. Instead of encrypting the key and authentication tag of the &payload; ciphertext with the Double Ratchet session, 32 zero-bytes are encrypted with the Double Ratchet session directly. The resulting OMEMOKeyExchange or OMEMOAuthenticatedMessage are put into <key> elements as usual, but the &payload; element is omitted altogether, so that the <encrypted> element only contains a <header>.</p>
|
||||
@ -551,7 +565,7 @@
|
||||
</keys>
|
||||
</header>
|
||||
<payload>
|
||||
base64/encoded/message/key/encrypted/content/element
|
||||
base64/encoded/message/key/encrypted/envelope/element
|
||||
</payload>
|
||||
</encrypted>
|
||||
<store xmlns='urn:xmpp:hints'/>
|
||||
@ -579,16 +593,16 @@
|
||||
Any existing double ratchet sessions SHOULD remain intact. At any point any party MAY
|
||||
revert their decision and go back to sending OMEMO encrypted messages again.</p>
|
||||
<example caption='A client signaling that it’s account no longer wants to receive OMEMO-encrypted messages'><![CDATA[
|
||||
<content xmlns='urn:xmpp:sce:0'>
|
||||
<payload>
|
||||
<envelope xmlns='urn:xmpp:sce:1'>
|
||||
<content>
|
||||
<opt-out xmlns=']]>&ns;<![CDATA['>
|
||||
<reason>
|
||||
Sorry, but for compliance reasons I need a permanent,
|
||||
server-side, record of our conversation.
|
||||
</reason>
|
||||
</opt-out>
|
||||
</payload>
|
||||
</content>
|
||||
</content>
|
||||
</envelope>
|
||||
]]></example>
|
||||
</section2>
|
||||
<section2 topic='Group Chats' anchor='group-chats'>
|
||||
@ -647,7 +661,7 @@
|
||||
</keys>
|
||||
</header>
|
||||
<payload>
|
||||
base64/encoded/message/key/encrypted/content/element
|
||||
base64/encoded/message/key/encrypted/envelope/element
|
||||
</payload>
|
||||
</encrypted>
|
||||
<store xmlns='urn:xmpp:hints'/>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user