diff --git a/xep-0384.xml b/xep-0384.xml index ce0739b6..f797a385 100644 --- a/xep-0384.xml +++ b/xep-0384.xml @@ -1,9 +1,9 @@ + - + %ents; @@ -57,6 +57,20 @@ xmpp@larma.de jabber@larma.de + + 0.8.0 + 2020-11-05 + melvo + +

Update to XEP-0420 version 0.4.0 and adjust namespace:

+ + + 0.7.0 2020-09-05 @@ -98,7 +112,7 @@
  • Specify OMEMO encryption for XEP-0045 Multi-User Chats.
  • Use XEP-0420: Stanza Content Encryption.
  • Use AES256/CBC to encrypt SCE payload.
    • -
  • Change namespace to &ns;
    • +
  • Change namespace to urn:xmpp:omemo:1
  • Use wrapping 'keys' element for key elements in 'header'.
  • Define threat model
  • Change the state back to Experimental
    • @@ -495,12 +509,12 @@

    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.

    - An OMEMO SCE &content; element + An OMEMO SCE &envelope; element

    - - + + Hello World! - + ... -]]> +]]>

    - The &content; element is encrypted as described in the section about Message Encryption. + The &envelope; element is encrypted as described in the section about Message Encryption.

    Clients MUST only consider the devices on the &nsdevices; 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 &ns; 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.

    A special case are empty 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>.

    @@ -551,7 +565,7 @@ - base64/encoded/message/key/encrypted/content/element + base64/encoded/message/key/encrypted/envelope/element @@ -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.

    - + + Sorry, but for compliance reasons I need a permanent, server-side, record of our conversation. - - + + ]]> @@ -647,7 +661,7 @@ - base64/encoded/message/key/encrypted/content/element + base64/encoded/message/key/encrypted/envelope/element