From df74d7437980a7bc3d09a751cd902442f993ca84 Mon Sep 17 00:00:00 2001 From: Melvin Keskin Date: Sun, 3 Mar 2019 22:53:33 +0100 Subject: [PATCH 01/35] ProtoXEP Automatic Trust Transfer: First draft --- inbox/automatic-trust-transfer.xml | 340 +++++++++++++++++++++++++++++ 1 file changed, 340 insertions(+) create mode 100644 inbox/automatic-trust-transfer.xml diff --git a/inbox/automatic-trust-transfer.xml b/inbox/automatic-trust-transfer.xml new file mode 100644 index 00000000..a70d4ee3 --- /dev/null +++ b/inbox/automatic-trust-transfer.xml @@ -0,0 +1,340 @@ + + + OMEMO glossary OMEMO glossary <https://xmpp.org/extensions/xep-0384.html#glossary-general>." > +%ents; +]> + + +
+ Automatic Trust Transfer (ATT) + + ATT specifies an automatic transfer of trust in public identity keys used by the end-to-end encryption protocol OMEMO. + + &LEGALNOTICE; + xxxx + ProtoXEP + Standards Track + Standards + Council + + XMPP Core + XEP-0001 + XEP-0147 + XEP-0384 + + + + NOT_YET_ASSIGNED + + Melvin + Keskin + melvo@olomono.de + melvo@olomono.de + + + 0.0.1 + 2019-03-03 + mk +

First draft.

 + +
+ +

+ ATT is used for automatically establishing secure channels protected against active attacks between a new device and existing ones after a single mutual manual authentication between the new device and one of the existing ones. + It preserves the security level as if all devices had authenticated their keys manually. + A trusted third party is not required since a usual OMEMO message is used for transferring the information needed to authenticate a key or revoke the trust in that key. + Additionally, it will preserve the anonymity of the authentication and revocation since those messages are only sent to devices with authenticated keys. + That means that an attacker cannot detect whether an authentication or revocation took place. +

+

+ End-to-end encryption without verifying the authenticity of the public keys enables users to protect their communication against passive attacks. + That means an attacker cannot read the transferred messages without manipulating the exchanged messages or key material. + But without any other precautions active attacks are still possible. + If the exchanged keys are replaced with the key of an attacker, the end-to-end encrypted messages can be read by the attacker. +

+

+ When using &xep0384;, a public identity key is transmitted over a channel which is not protected against active attacks. + That key has to be authenticated by the receiving device over a channel which is protected against active attacks to maintain the confidentiality of sent OMEMO messages and ensuring the authenticity and integrity of received OMEMO messages. +

+

+ When using OMEMO, each device has a different identity key. + That makes it possible for new devices to use end-to-end encryption protecting against passive attacks without transmitting the private key over a secure channel from an existing device to the new one. + However, the downside of this approach is that it increases the number of authentications. +

+

+ The goal of key authentication is to build up an end-to-end encrypted communication network exclusively between devices with authenticated keys. + That network of devices trusting each other's keys can be seen as a complete graph with each device as a node and each authentication as an edge. + The number of edges grows for each new device by the number of existing nodes. + Without ATT all of those authentications have to be done manually. + With ATT though, only one mutal manual authentication is required. +

+

+ This means that each communication channel between the devices is resistant against active attacks. + To sustain such a secure communication across all devices, the new key of an own device has to be authenticated by all n own devices and all m devices of a contact. + This leads to a total of n * m authentications. + Two of them require user interaction like scanning each other's QR codes or comparing the key identifiers by hand. + The remaining authentications can be automated relying on the secure channel established by the two inital authentications and the secure channels created by that procedure. + Thus, less user interaction is needed for authenticating all keys involved in the secure communication while preserving the same security level. +

+

+ On the one hand, each new key has to be authenticated by a device that already belongs to the devices communicating with authenticated keys. + On the other hand, the device that introduces the new key has to authenticate the key of the device that already belongs to the devices communicating with authenticated keys. +

+

+ More precisely, that means the following: + After device 1 manually authenticated the key of device 2, a message called authentication message for the key of device 2 is sent automatically from device 1 to devices with already authenticated keys. + They can use the authentication message for an automatic authentication of the key of device 2 after they authenticated the key of device 1. +

+

+ When a key of an own device should not be trusted anymore by other own devices and devices of a contact, an appropriate message can be sent to those devices. + They can then revoke the trust in that key if the key of the sending device is already authenticated. +

+ + +
+ +
OMEMO message
+
Message encrypted with OMEMO
+ + +
Device
+
See Device in &omemo-glossary;
+ + +
Key
+
Public part of IdentityKey in &omemo-glossary;
+ + +
Key identifier
+
Identifier for a key (e.g., a fingerprint or the key itself)
+ + +
Key authentication
+
Verifying that a key received over an insecure channel is actually the one of the assumed device
+ + +
Manual key authentication
+
Key authentication with user interaction (e.g., QR code scanning, fingerprint verification)
+ + +
Automatic key authentication
+
Key authentication without user interaction (e.g., ATT)
+ + +
Trust message
+
+ OMEMO message which indicates that specific keys can be trusted or no longer trusted. + A trust message for a device's key sent to another device is a trust message that contains the key identifer of the given key for authentication or revocation. + If a trust message only contains key identifiers for authentication, it is called authentication message. + If it only contains keys identifiers for revocation, it is called revocation message. +
+ + +
Authentication message
+
+ An authentication message for a key is an OMEMO message which advises the receiving device to trust that key. +
+ + +
Revocation message
+
+ A revocation message for a key is an OMEMO message which advises the receiving device to not trust that key anymore. +
+ +
+ + + +

+ A trust message contains an XMPP URI defined by the following scheme: +

+ ?omemo-trust;=;=;<...>;=]]> + + + +

+ An authentication message contains an XMPP URI defined by the following scheme: +

+ ?omemo-trust;auth=;auth=;<...>;auth=]]> + + + +

+ A revocation message contains an XMPP URI defined by the following scheme: +

+ ?omemo-trust;revoke=;revoke=;<...>;revoke=]]> + + + + +

+ Alice would like to use OMEMO when communicating with Bob. + Alice has the devices A1, A2 and A3. + Bob has the device B1. + A1 has already authenticated the key of A2. + The other devices have not authenticated the keys of each other. +

+

+ Note that the examples in the following use cases are consecutive and therefore must be read chronologically to properly understand them. +

+ + +

+ Example: + A1 authenticates the key of B1. +

+

+ A device that manually authenticates the key of a contact's device MUST send an authentication message for +

+
    +
  1. +

    + the key that has been authenticated, to each own device with an already authenticated key. +

    +

    + Example: + A1 sends an authentication message for B1's key to A2. +

    +
    2. +
  2. +

    + each already authenticated key of all own devices, to the device whose key has been authenticated. +

    +

    + Example: + A1 sends an authentication message for A2's key to B1. +

    +
    3. +
+ + +

+ A device that receives an authentication message for a key of a contact's device from +

+
    +
  1. +

    + an own device +

    +

    + Example: + A2 authenticates B1's key by the authentication message from A1 as soon as A2 authenticated A1's key. +

    +
    2. +
  2. +

    + or another device of that contact +

    +

    + Example: + B1 authenticates A2's key by the authentication message from A1 as soon as B1 authenticated A1's key. +

    +
    3. +
+

+ MUST authenticate the key as soon as the key of the author of the authentication message is authenticated by the receiving device. +

+ + + + +

+ Example: + A1 authenticates the key of A3. +

+

+ A device that manually authenticates the key of an own device MUST send an authentication message for +

+
    +
  1. +

    + the key that has been authenticated to each other device with an already authenticated key. +

    +

    + Example: + A1 sends an authentication message for A3's key to A2 and B1. +

    +
    2. +
  2. +

    + each already authenticated key of all devices to the device whose key has been authenticated. +

    +

    + Example: + A1 sends an authentication message for A2's and B1's key to A3. +

    +
    3. +
+ + +

+ A device that receives an authentication message for a key of an own device from another own device MUST authenticate the key as soon as the key of the device that sent the authentication message is authenticated by the receiving device. +

+

+ Example: + A2 authenticates A3's key by the authentication message from A1 as soon as A2 authenticated A1's key. +

+ + + +

+ A client MAY send a revocation message for a key that is not trusted anymore by the sending client so that key will no longer be trusted by the receiving client. + A client receiving a revocation message SHOULD revoke the trust in the corresponding key. +

+

+ // TODO Further discussion has to take place before finalizing this section. +

+ + + +

+ A client MUST save the information of a trust message until the key of the sending device of that message is authenticated, so that the key can then be authenticated or revoked. + Afterwards the information of the trust message can be deleted. +

+

+ A client MUST save the information of a trust message until it has fetched the corresponding key so that the key can then be authenticated or revoked. + Afterwards the information of the trust message can be deleted. +

+

+ It can happen, that device 1 manually authenticates the key of device 2 while device 1 is offline. + If then device 3 also manually authenticated the same key and sends authentication messages for it while device 1 is still offline, there would be, after device 1 got online again and sent its authentication messages, several authentication messages with the same content circulating. + That would lead to unnecessary network load. + Therefore, a client that receives an authentication message MAY stop the sending of an authentication message with the same content to the same recipients. +

+ + + +

+ A client that receives a trust message SHOULD NOT display its bare content to the user. + Instead, the message SHOULD be hidden and the automatic authentication or revocation SHOULD take place in the background. + After a successful authentication or revocation, the user MAY be informed of that event. + The client MAY offer an option for requesting the user's confirmation before any automatic authentication or automatic revocation is performed. +

+ + +

+ It is more secure to be protected against passive attacks instead of not using any encryption. + If it is not possible to authenticate a key before encrypting with it but it is desired to communicate with the key's device, it is RECOMMENDED to blindly trust new keys until the first authentication has been made. +

+

+ Even ATT cannot protect the user against an attacker with a blindly trusted and undetected malicious key. + For this reason it is important to take special care of the following security aspects. +

+

+ If keys are blindly trusted until the first authentication, keys which are not authenticated by then MUST NOT be used any longer for encryption until they have been authenticated too. + New keys MUST also only be used for encryption after they have been authenticated. + Without these two additional precautions it is not possible to protect the user against attackers who introduced malicious keys before or after the first authentication. +

+ + + +

REQUIRED.

+ + +

REQUIRED.

+ + +

REQUIRED for protocol specifications.

+ + From 79d86c27324717405893cd5af2f98369ca64a75c Mon Sep 17 00:00:00 2001 From: Melvin Keskin Date: Fri, 8 Mar 2019 00:11:06 +0100 Subject: [PATCH 02/35] add link for XMPP URI to XEP-0147 --- inbox/automatic-trust-transfer.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/inbox/automatic-trust-transfer.xml b/inbox/automatic-trust-transfer.xml index a70d4ee3..1a0e9d6b 100644 --- a/inbox/automatic-trust-transfer.xml +++ b/inbox/automatic-trust-transfer.xml @@ -147,7 +147,7 @@

- A trust message contains an XMPP URI defined by the following scheme: + A trust message contains an XMPP URI (see &xep0147;) defined by the following scheme:

?omemo-trust;=;=;<...>;=]]> From 4c6492293fbc7bbe77a06c1bb75d2099cf2f3382 Mon Sep 17 00:00:00 2001 From: Melvin Keskin Date: Fri, 8 Mar 2019 00:22:25 +0100 Subject: [PATCH 03/35] shorten trust message types and their URIs --- inbox/automatic-trust-transfer.xml | 44 ++++++------------------------ 1 file changed, 8 insertions(+), 36 deletions(-) diff --git a/inbox/automatic-trust-transfer.xml b/inbox/automatic-trust-transfer.xml index 1a0e9d6b..ab1dd760 100644 --- a/inbox/automatic-trust-transfer.xml +++ b/inbox/automatic-trust-transfer.xml @@ -124,48 +124,20 @@
Trust message
- OMEMO message which indicates that specific keys can be trusted or no longer trusted. + OMEMO message which indicates that specific keys can be trusted (authentication) or no longer trusted (revocation). A trust message for a device's key sent to another device is a trust message that contains the key identifer of the given key for authentication or revocation. If a trust message only contains key identifiers for authentication, it is called authentication message. - If it only contains keys identifiers for revocation, it is called revocation message. -
- - -
Authentication message
-
- An authentication message for a key is an OMEMO message which advises the receiving device to trust that key. -
- - -
Revocation message
-
- A revocation message for a key is an OMEMO message which advises the receiving device to not trust that key anymore. + If it only contains key identifiers for revocation, it is called revocation message.
- - -

- A trust message contains an XMPP URI (see &xep0147;) defined by the following scheme: -

- ?omemo-trust;=;=;<...>;=]]> - - - -

- An authentication message contains an XMPP URI defined by the following scheme: -

- ?omemo-trust;auth=;auth=;<...>;auth=]]> - - - -

- A revocation message contains an XMPP URI defined by the following scheme: -

- ?omemo-trust;revoke=;revoke=;<...>;revoke=]]> - - + +

+ A trust message contains an XMPP URI (see &xep0147;) defined by the following scheme: +

+ ?omemo-trust;=;=;<...>;=]]> +

From 421fb2132ff47dad97688f877b4360cdcabef25b Mon Sep 17 00:00:00 2001 From: Melvin Keskin Date: Fri, 8 Mar 2019 00:27:17 +0100 Subject: [PATCH 04/35] improve parts for storing trust message infromation of section "Implementation Notes" --- inbox/automatic-trust-transfer.xml | 33 ++++++++++++++++++++++-------- 1 file changed, 25 insertions(+), 8 deletions(-) diff --git a/inbox/automatic-trust-transfer.xml b/inbox/automatic-trust-transfer.xml index ab1dd760..b5c1ca59 100644 --- a/inbox/automatic-trust-transfer.xml +++ b/inbox/automatic-trust-transfer.xml @@ -260,14 +260,31 @@ -

- A client MUST save the information of a trust message until the key of the sending device of that message is authenticated, so that the key can then be authenticated or revoked. - Afterwards the information of the trust message can be deleted. -

-

- A client MUST save the information of a trust message until it has fetched the corresponding key so that the key can then be authenticated or revoked. - Afterwards the information of the trust message can be deleted. -

+ +

+ A client MUST save the information of a trust message until the key of the device which sent the trust message is authenticated, so that the key can then be authenticated or revoked. + Afterwards the information of the trust message MAY be deleted. +

+

+ Example: + When Alice's device A1 authenticates the key of Bob's device B1, A1 sends a trust message containing the keys of Alice's other device A2 to B1. + If B1 has not already authenticated A1's key, B1 stores the information provided by the trust message. + B1 authenticates A1's key and is then able to automatically authenticate A2's key. +

+ + +

+ A client MUST save the information of a trust message until it has fetched the corresponding key so that the key can then be authenticated or revoked. + Afterwards the information of the trust message can be deleted. +

+

+ Example: + Alice's device A1 receives an authentication message from Bob's device B1. + That authentication message contains the key for Bob's other device B2. + If A1 has not already fetched B2's key, A1 stores the information provided by the trust message. + A1 fetches B2's key and is then able to automatically authenticate A2's key. +

+

It can happen, that device 1 manually authenticates the key of device 2 while device 1 is offline. If then device 3 also manually authenticated the same key and sends authentication messages for it while device 1 is still offline, there would be, after device 1 got online again and sent its authentication messages, several authentication messages with the same content circulating. From 470513ee0470dfeb697d5c28c81b7cfdec18db3d Mon Sep 17 00:00:00 2001 From: Melvin Keskin Date: Fri, 8 Mar 2019 01:19:09 +0100 Subject: [PATCH 05/35] remove less important part of section "Implementation Notes" --- inbox/automatic-trust-transfer.xml | 6 ------ 1 file changed, 6 deletions(-) diff --git a/inbox/automatic-trust-transfer.xml b/inbox/automatic-trust-transfer.xml index b5c1ca59..b71ab63b 100644 --- a/inbox/automatic-trust-transfer.xml +++ b/inbox/automatic-trust-transfer.xml @@ -285,12 +285,6 @@ A1 fetches B2's key and is then able to automatically authenticate A2's key.

-

- It can happen, that device 1 manually authenticates the key of device 2 while device 1 is offline. - If then device 3 also manually authenticated the same key and sends authentication messages for it while device 1 is still offline, there would be, after device 1 got online again and sent its authentication messages, several authentication messages with the same content circulating. - That would lead to unnecessary network load. - Therefore, a client that receives an authentication message MAY stop the sending of an authentication message with the same content to the same recipients. -

From daa82d7b508107593710ccca696b438af7bc0dc4 Mon Sep 17 00:00:00 2001 From: Melvin Keskin Date: Fri, 8 Mar 2019 12:26:08 +0100 Subject: [PATCH 06/35] add "mutual key authentication" to glossary --- inbox/automatic-trust-transfer.xml | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/inbox/automatic-trust-transfer.xml b/inbox/automatic-trust-transfer.xml index b71ab63b..ee5f4ebb 100644 --- a/inbox/automatic-trust-transfer.xml +++ b/inbox/automatic-trust-transfer.xml @@ -121,6 +121,10 @@
Automatic key authentication
Key authentication without user interaction (e.g., ATT)
+ +
Mutual key authentication
+
Key authentication in which two devices authenticate the key of each other
+
Trust message
From 1934979a2dbb657630edd013f4ba0435ad283021 Mon Sep 17 00:00:00 2001 From: Melvin Keskin Date: Fri, 8 Mar 2019 21:07:27 +0100 Subject: [PATCH 07/35] shorten introduction --- inbox/automatic-trust-transfer.xml | 40 ++++++------------------------ 1 file changed, 7 insertions(+), 33 deletions(-) diff --git a/inbox/automatic-trust-transfer.xml b/inbox/automatic-trust-transfer.xml index ee5f4ebb..631394d7 100644 --- a/inbox/automatic-trust-transfer.xml +++ b/inbox/automatic-trust-transfer.xml @@ -44,14 +44,14 @@ ATT is used for automatically establishing secure channels protected against active attacks between a new device and existing ones after a single mutual manual authentication between the new device and one of the existing ones. It preserves the security level as if all devices had authenticated their keys manually. A trusted third party is not required since a usual OMEMO message is used for transferring the information needed to authenticate a key or revoke the trust in that key. - Additionally, it will preserve the anonymity of the authentication and revocation since those messages are only sent to devices with authenticated keys. - That means that an attacker cannot detect whether an authentication or revocation took place. + Additionally, it preserves the anonymity of the authentication and revocation since those messages are only sent to devices with authenticated keys. + That means an attacker cannot detect whether an authentication or revocation took place.

- End-to-end encryption without verifying the authenticity of the public keys enables users to protect their communication against passive attacks. - That means an attacker cannot read the transferred messages without manipulating the exchanged messages or key material. + End-to-end encryption without verifying the authenticity of the keys enables users to protect their communication against passive attacks. + This means an attacker cannot read the transferred messages without manipulating the exchanged keys. But without any other precautions active attacks are still possible. - If the exchanged keys are replaced with the key of an attacker, the end-to-end encrypted messages can be read by the attacker. + If an attacker replaces the exchanged keys with a malicious key, the end-to-end encrypted messages can be read and manipulated by the attacker.

When using &xep0384;, a public identity key is transmitted over a channel which is not protected against active attacks. @@ -61,34 +61,8 @@ When using OMEMO, each device has a different identity key. That makes it possible for new devices to use end-to-end encryption protecting against passive attacks without transmitting the private key over a secure channel from an existing device to the new one. However, the downside of this approach is that it increases the number of authentications. -

-

- The goal of key authentication is to build up an end-to-end encrypted communication network exclusively between devices with authenticated keys. - That network of devices trusting each other's keys can be seen as a complete graph with each device as a node and each authentication as an edge. - The number of edges grows for each new device by the number of existing nodes. - Without ATT all of those authentications have to be done manually. - With ATT though, only one mutal manual authentication is required. -

-

- This means that each communication channel between the devices is resistant against active attacks. - To sustain such a secure communication across all devices, the new key of an own device has to be authenticated by all n own devices and all m devices of a contact. - This leads to a total of n * m authentications. - Two of them require user interaction like scanning each other's QR codes or comparing the key identifiers by hand. - The remaining authentications can be automated relying on the secure channel established by the two inital authentications and the secure channels created by that procedure. - Thus, less user interaction is needed for authenticating all keys involved in the secure communication while preserving the same security level. -

-

- On the one hand, each new key has to be authenticated by a device that already belongs to the devices communicating with authenticated keys. - On the other hand, the device that introduces the new key has to authenticate the key of the device that already belongs to the devices communicating with authenticated keys. -

-

- More precisely, that means the following: - After device 1 manually authenticated the key of device 2, a message called authentication message for the key of device 2 is sent automatically from device 1 to devices with already authenticated keys. - They can use the authentication message for an automatic authentication of the key of device 2 after they authenticated the key of device 1. -

-

- When a key of an own device should not be trusted anymore by other own devices and devices of a contact, an appropriate message can be sent to those devices. - They can then revoke the trust in that key if the key of the sending device is already authenticated. + Without ATT all authentications have to be done manually. + With ATT though, only one mutal manual authentication per new key is required.

From 8347c3888936e4e195dd0ada51728e57583c2f99 Mon Sep 17 00:00:00 2001 From: Melvin Keskin Date: Sat, 9 Mar 2019 18:50:41 +0100 Subject: [PATCH 08/35] create new section "Advantages" --- inbox/automatic-trust-transfer.xml | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/inbox/automatic-trust-transfer.xml b/inbox/automatic-trust-transfer.xml index 631394d7..8f1ced54 100644 --- a/inbox/automatic-trust-transfer.xml +++ b/inbox/automatic-trust-transfer.xml @@ -110,6 +110,28 @@ + +

+ The goal of key authentication is to create an end-to-end encrypted communication network exclusively of devices with authenticated keys. + As a result every communication channel between those devices is resistant against active attacks. +

+

+ The network of devices which authenticated each other's keys can be seen as a complete graph with each device as a node and each mutual authentication as an edge. + The number of edges grows for each new device by the number of existing nodes. + That means to sustain a secure communication across all devices, a new key has to be authenticated by all n existing devices and vice versa. +

+

+ One of those n mutual authentications requires user interaction like scanning each other's QR codes or comparing each other's key identifiers by hand. + That is the initial mutual manual authentication. + The remaining authentications can be automated relying on the secure channel established by the inital mutual manual authentication and the secure channels already created by the same procedure between the rest of the devices. +

+

+ For creating the described complete graph with n nodes, a total of T(n) = (n*(n-1))/2 ∊ O(n²) mutual authentications are needed. + When using ATT, only T(n) = n-1 ∊ O(n) of them have to be made manually. + All remaining authentications can be performed automatically. + Thus, less user interaction is needed for authenticating all keys involved in the secure communication while preserving the same security level. +

+

A trust message contains an XMPP URI (see &xep0147;) defined by the following scheme: From 7adb7769f55e4bd16a10f95063831c311660ebd2 Mon Sep 17 00:00:00 2001 From: Melvin Keskin Date: Sat, 9 Mar 2019 20:28:37 +0100 Subject: [PATCH 09/35] create new section "General Procedure" --- inbox/automatic-trust-transfer.xml | 44 ++++++++++++++++++++++++++++++ 1 file changed, 44 insertions(+) diff --git a/inbox/automatic-trust-transfer.xml b/inbox/automatic-trust-transfer.xml index 8f1ced54..85f62815 100644 --- a/inbox/automatic-trust-transfer.xml +++ b/inbox/automatic-trust-transfer.xml @@ -132,6 +132,50 @@ Thus, less user interaction is needed for authenticating all keys involved in the secure communication while preserving the same security level.

+ +

+ This section explains the basic procedure of autmomatically authenticating or revoking a key by a trust message. + It does not specify the detailed behaviour which can be found in section Use Cases. + Instead, this section should rather show the fundamental idea behind it. +

+ +
    +
  1. +

    + Device 1 manually authenticates the key of device 2. + Device 1 automatically sends an authentication message for device 2's key to devices whose keys it has already authenticated and an authentication message for the keys of those devices to device 2. +

    +
    2. +
  2. +

    + Device 2 manually authenticates the key of device 1. + Device 2 automatically sends an authentication message for device 1's key to devices whose keys it has already authenticated and an authentication message for the keys of those devices to device 1. +

    +
    3. +
  3. +

    + Device 1 automatically authenticates the keys of the authentication message from device 2. + Each device receiving an authentication message from device 1 automatically authenticates device 2's key, if device 1's key has already been authenticated by it. + Each device receiving an authentication message from device 2 automatically authenticates the corresponding keys, if device 2's key has been authenticated by it. +

    +
    4. +
  4. +

    + Device 2 automatically authenticates the keys of the authentication message from device 1. + Each device receiving an authentication message from device 2 automatically authenticates device 1's key, if device 2's key has already been authenticated by it. + Each device receiving an authentication message from device 1 automatically authenticates the corresponding keys, if device 1's key has been authenticated by it. +

    +
    5. +
+ + +

+ Device 1 manually revokes the trust in the key of device 2. + Device 1 automatically sends a revocation message for device 2's key to devices whose keys it has already authenticated. + Each device receiving a revocation message from device 1 automatically revokes the trust in device 2's key, if device 1's key has already been authenticated by it. +

+ +

A trust message contains an XMPP URI (see &xep0147;) defined by the following scheme: From f68f4262030377ec1820a1ccae12f678c220fbb1 Mon Sep 17 00:00:00 2001 From: Melvin Keskin Date: Sat, 9 Mar 2019 20:53:16 +0100 Subject: [PATCH 10/35] create new section "Reducing The Number of Trust Messages" --- inbox/automatic-trust-transfer.xml | 35 ++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/inbox/automatic-trust-transfer.xml b/inbox/automatic-trust-transfer.xml index 85f62815..0eb54016 100644 --- a/inbox/automatic-trust-transfer.xml +++ b/inbox/automatic-trust-transfer.xml @@ -329,6 +329,41 @@ A1 fetches B2's key and is then able to automatically authenticate A2's key.

+ + +

+ For reducing the number of trust messages sent to a device, a client MAY use a URI containing multiple keys that have been authenticated shortly after another. +

+

+ Example: + Alice's device A1 authenticates the keys of Bob's devices B1 and B2 after scanning Bob's QR code containing their key identifiers. + A1 sends one authentication message for all of the authenticated keys. +

+ + +

+ Furthermore, a client MAY use &xep0280; for sending a trust message to all devices of a contact or to all own devices at once. + Then, by sending a trust message to the contact, each device of the contact and each own device gets the same trust message by the server. + Thus, a client needs to send the same trust message only once. + If not all devices of the contact should receive the trust message, the trust message MAY be sent to specific devices of the contact but for all own devices Message Carbons MAY be used and vice versa. + Even when a client does not already have a contact, the client MAY use Message Carbons for delivering a trust message to all own devices. +

+

+ Example: + Alice's device A1 authenticates the key of her device A2. + A1 sends the trust message for A2's key only once to all of Alice's and Bob's devices by using Message Carbons. +

+

+ Attention: + In that context, sending a trust message to all devices of a contact or to all own devices does not mean to encrypt it with the keys of all those devices. + Instead, it only means that all of those devices should receive the trust message even if it is not encrypted for some of them and thereby not decryptable by those devices. + Keep in mind that a trust message MUST only be encrypted for devices with authenticated keys. +

+

+ The drawback of using Message Carbons is that clients may show a message to the user that an OMEMO message received which has not been encrypted for the corresponding device. +

+ + From 3076f32686934817dcbda9d73d8383c99a939d80 Mon Sep 17 00:00:00 2001 From: Melvin Keskin Date: Sat, 9 Mar 2019 20:59:57 +0100 Subject: [PATCH 11/35] add key revocation terms to glossary and improve it --- inbox/automatic-trust-transfer.xml | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/inbox/automatic-trust-transfer.xml b/inbox/automatic-trust-transfer.xml index 0eb54016..7a5dfff4 100644 --- a/inbox/automatic-trust-transfer.xml +++ b/inbox/automatic-trust-transfer.xml @@ -93,12 +93,24 @@
Automatic key authentication
-
Key authentication without user interaction (e.g., ATT)
+
Key authentication without user interaction (e.g., via ATT)
Mutual key authentication
Key authentication in which two devices authenticate the key of each other
 + +
Key revocation
+
Revoking the trust in a key
+ + +
Manual key revocation
+
Key revocation with user interaction (e.g., clicking a "Revoke" button)
+ + +
Automatic key revocation
+
Key revocation without user interaction (e.g., via ATT)
+
Trust message
From f45b32f7f0f91db0f1cd470ae0f2ab3d735308f4 Mon Sep 17 00:00:00 2001 From: Evgeny Khramtsov Date: Tue, 12 Mar 2019 10:25:57 +0300 Subject: [PATCH 12/35] Update references to new XEPs and RFCs --- xep-0415.xml | 8 ++++---- xep-0416.xml | 14 +++++++------- xep.ent | 5 +++++ 3 files changed, 16 insertions(+), 11 deletions(-) diff --git a/xep-0415.xml b/xep-0415.xml index 1956a7b6..7e06a6cc 100644 --- a/xep-0415.xml +++ b/xep-0415.xml @@ -43,7 +43,7 @@ -

REsource LOcation And Discovery (RELOAD) (RFC6940) specifies a peer-to-peer (P2P) signaling protocol for general use on the Internet. This document defines an XMPP Usage of RELOAD that allows XMPP clients to establish peer-to-peer XMPP streams without routing them through XMPP servers.

+

REsource LOcation And Discovery (RELOAD) (&rfc6940;) specifies a peer-to-peer (P2P) signaling protocol for general use on the Internet. This document defines an XMPP Usage of RELOAD that allows XMPP clients to establish peer-to-peer XMPP streams without routing them through XMPP servers.

The XMPP Usage involves two basic functions:

  1. Address Location: XMPP clients can use the RELOAD data storage functionality to store a mapping from their XMPP address to their Node-ID in the overlay and to retrieve the Node-ID of other clients.
    2. @@ -82,13 +82,13 @@
    -
    RELOAD
    REsource LOcation And Discovery (RFC6940) - a P2P signaling protocol for general use on the Internet. The terminology and definitions from this protocol are used extensively in this document.
     +
    RELOAD
    REsource LOcation And Discovery (&rfc6940;) - a P2P signaling protocol for general use on the Internet. The terminology and definitions from this protocol are used extensively in this document.
    Address Location
    One or many RELOAD Node-IDs to which a peer-to-peer connection can be established in order to contact an owner of the XMPP address.
    -

    In XMPP Core &rfc6120;, a client fully relies on servers for its XMPP address location. In XMPP Usage of RELOAD, this location function is provided by the overlay as a whole. To register its location, a RELOAD peer stores an XmppLocation Resource Record for its own XMPP address using the XMPP-LOCATION Kind, which is formally defined below. Note that if a client wishes to set the location lifetime it MUST use lifetime of the basic RELOAD StoredData structure (see Section 7 of RFC6940).

    +

    In XMPP Core &rfc6120;, a client fully relies on servers for its XMPP address location. In XMPP Usage of RELOAD, this location function is provided by the overlay as a whole. To register its location, a RELOAD peer stores an XmppLocation Resource Record for its own XMPP address using the XMPP-LOCATION Kind, which is formally defined below. Note that if a client wishes to set the location lifetime it MUST use lifetime of the basic RELOAD StoredData structure (see Section 7 of &rfc6940;).

    As a simple example, consider Juliet with an XMPP address "juliet@capulet.lit" at Node-ID "1234". She might store the mapping "juliet@capulet.lit -> 1234" telling anyone who wants to contact her to establish a direct XMPP stream with node "1234".

    RELOAD peers can store two kinds of XMPP mappings,

      @@ -236,7 +236,7 @@ XMPP-LOCATION 0x5 - XEP-XOR + XEP-0415 diff --git a/xep-0416.xml b/xep-0416.xml index abf8502e..45dfd726 100644 --- a/xep-0416.xml +++ b/xep-0416.xml @@ -46,7 +46,7 @@
      E2E encryption
      For end-to-end encryption, XMPP clients may use certificates to mutually identify each other, i.e. check that the cryptographic key belongs to this exact XMPP address.
      External services
      An XMPP server may authenticate users of other servers at its local services, such as an HTTP Upload component (&xep0363;), e.g. for granting file uploads, or a TURN server (&rfc5766;).
       -
      XMPP Usage of RELOAD
      XMPP entities attached to the XOR overlay (XEP-XOR) are supposed to use certificates for mutual authentication.
       +
      XMPP Usage of RELOAD
      XMPP entities attached to the XOR overlay (XEP-0415) are supposed to use certificates for mutual authentication.
      SPAM protection
      Since certificate authorities are required to be Sybil resistant (XEP-EAX-CAR), a spammer is limited in ability to create accounts massively. Thus it is expected that SPAM dissemination will fall to negligible levels.
      Registration delegation
      XMPP accounts registration typically creates a huge burden for operators of public servers. An operator may want to delegate a registration of accounts of its own server to a trusted CA. The CA will validate the users' identities and will issue certificates for them. The users can use these certificates in c2s SASL EXTERNAL authentication at the operator's server as well as for e2e authentication with other entities.
      @@ -84,7 +84,7 @@
      1. The leaf certificate MUST be compliant with c2s SASL EXTERNAL authentication (&rfc6120;, &xep0178;).
        2. -
      2. The leaf certificate MUST be compliant with RELOAD authentication (RFC6940).
        3. +
      3. The leaf certificate MUST be compliant with RELOAD authentication (&rfc6940;).
       @@ -100,11 +100,11 @@
    • The certificate MUST NOT contain a basicConstraints extension with the cA boolean set to TRUE.
    • The certificate MUST include a CRL Distribution Points extension that specifies an URI of a Certificate Revocation List.
    • The certificate MUST possess a single XMPP address represented as an XmppAddr as specified under Section 13.7.1.4 of &rfc6120;.
      • -
    • The SubjectAltName field in the certificate MUST contain a single RELOAD URI as specified under Section 14.15 of RFC6940 encoded as uniformResourceIdentifier type. The "destination" part of the URI MUST be a RELOAD Node-ID. The Node-ID MAY be hexadecimal-encoded. The "overlay" part of the URI MUST be "xmpp.org". The "specifier" part of the URI MUST be empty.
      • +
    • The SubjectAltName field in the certificate MUST contain a single RELOAD URI as specified under Section 14.15 of &rfc6940; encoded as uniformResourceIdentifier type. The "destination" part of the URI MUST be a RELOAD Node-ID. The Node-ID MAY be hexadecimal-encoded. The "overlay" part of the URI MUST be "xmpp.org". The "specifier" part of the URI MUST be empty.
    • If the XMPP address doesn't contain non-ASCII characters, it MUST be encoded in the SubjectAltName field as rfc822Name type.

Note that the rules for leaf certificates comply with the rules defined for client certificates under Sections 13.7.1.1 and 13.7.1.4 of &rfc6120;. Thus they can be used for c2s SASL EXTERNAL authentication.

-

The requirement to possess a RELOAD URI and an rfc822Name address makes it possible to use the certificate for RELOAD authentication. Even if XOR extension (XEP-XOR) is unused, the RELOAD URI uniquely identifies a user device: a user MAY have several certificates assigned to their XMPP address but with different RELOAD URIs.

+

The requirement to possess a RELOAD URI and an rfc822Name address makes it possible to use the certificate for RELOAD authentication. Even if XOR extension (XEP-0415) is unused, the RELOAD URI uniquely identifies a user device: a user MAY have several certificates assigned to their XMPP address but with different RELOAD URIs.

The following rules apply to domain-associated certificates:

  1. The certificate MUST contain a keyUsage extension with the keyCertSign bit set.
    2. @@ -134,15 +134,15 @@

    An XMPP entity MAY maintain its own list of root certificates. However, in practice it's convenient to retrieve this list from a trusted source. For example, several organizations in the Internet maintain and provide such lists for certificates verification in the Web. This section specifies how the list of root certificates can be retrieved for the purpose of e2e authentication in XMPP.

    -

    Since the authentication is intended to be compliant with RELOAD and creating new document formats or DNS TXT records without exigency are in general discouraged, the Overlay Configuration document is reused to provide the list of root certificates (see Section 11.1 of RFC6940). The root certificates are PEM-encoded (RFC7468) with encapsulation boundaries removed and are included in <root-cert/> elements of the Overlay Configuration.

    -

    In order to retrieve the Overlay Configuration, an HTTP GET request is performed to "https://xmpp.org/.well-known/reload-config". The requesting UA MUST be prepared to process HTTP redirects. In the case of a failure, the UA MAY repeat the request. In this case exponential backoff MUST be applied. Since the list of root certifcates is not a subject for frequent updates, under normal conditions, the UA SHOULD NOT request the Overlay Configuration more often than once per day. Usage of 'If-Modified-Since' is RECOMMENDED (RFC7232).

    +

    Since the authentication is intended to be compliant with RELOAD and creating new document formats or DNS TXT records without exigency are in general discouraged, the Overlay Configuration document is reused to provide the list of root certificates (see Section 11.1 of &rfc6940;). The root certificates are PEM-encoded (&rfc7468;) with encapsulation boundaries removed and are included in <root-cert/> elements of the Overlay Configuration.

    +

    In order to retrieve the Overlay Configuration, an HTTP GET request is performed to "https://xmpp.org/.well-known/reload-config". The requesting UA MUST be prepared to process HTTP redirects. In the case of a failure, the UA MAY repeat the request. In this case exponential backoff MUST be applied. Since the list of root certifcates is not a subject for frequent updates, under normal conditions, the UA SHOULD NOT request the Overlay Configuration more often than once per day. Usage of 'If-Modified-Since' is RECOMMENDED (&rfc7232;).

    Further versions of this specification MAY extend the Overlay Configuration with new XML elements.

    An XMPP entity MAY want to publish its certificate so other XMPP entities MAY retrieve it. The method to accomplish this depends on the usage:

    • In the case of an ordinary XMPP usage (&rfc6120;) a special PEP node (&xep0163;) is used as specified in XEP-EAX-SIGN.
      • -
    • In the case of XMPP Usage of RELOAD (XEP-XOR) a peer is REQUIRED to store its certificate in the RELOAD overlay (see Section 8 of RFC6940).
      • +
    • In the case of XMPP Usage of RELOAD (XEP-0415) a peer is REQUIRED to store its certificate in the RELOAD overlay (see Section 8 of &rfc6940;).
     diff --git a/xep.ent b/xep.ent index 4af49a8e..be16cd99 100644 --- a/xep.ent +++ b/xep.ent @@ -671,7 +671,10 @@ THE SOFTWARE. RFC 6763 RFC 6763: DNS-Based Service Discovery <http://tools.ietf.org/html/rfc6763>." > RFC 6797 RFC 6797: HTTP Strict Transport Security (HSTS) <http://tools.ietf.org/html/rfc6797>." > RFC 6920 RFC 6920: Naming Things with Hashes <http://tools.ietf.org/html/rfc6920>." > +RFC 6940 RFC 6940: REsource LOcation And Discovery (RELOAD) Base Protocol <http://tools.ietf.org/html/rfc6940>." > RFC 7081 RFC 7081: CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) <http://tools.ietf.org/html/rfc7081>." > +RFC 7232 RFC 7232: Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests <http://tools.ietf.org/html/rfc7232>." > +RFC 7468 RFC 7468: Textual Encodings of PKIX, PKCS, and CMS Structures <http://tools.ietf.org/html/rfc7468>." > RFC 7469 RFC 7469: Public Key Pinning Extension for HTTP <http://tools.ietf.org/html/rfc7469>." > RFC 7519 RFC 7519: JSON Web Token (JWT) <http://tools.ietf.org/html/rfc7519>." > RFC 7572 RFC 7572: Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging <http://tools.ietf.org/html/rfc7572>." > @@ -1544,3 +1547,5 @@ IANA Service Location Protocol, Version 2 (SLPv2) Templates XMPP Compliance Suites 2019 (XEP-0412) XEP-0412: XMPP Compliance Suites 2019 <https://xmpp.org/extensions/xep-0412.html>." > Order-By (XEP-0413) XEP-0413: Order-By <https://xmpp.org/extensions/xep-0413.html>." > Cryptographic Hash Function Recommendations for XMPP (XEP-0414) XEP-0414: Cryptographic Hash Function Recommendations for XMPP <https://xmpp.org/extensions/xep-0414.html>." > +XMPP Over RELOAD (XEP-0415) XEP-0415: XMPP Over RELOAD (XOR) <https://xmpp.org/extensions/xep-0415.html>." > +E2E Authentication in XMPP (XEP-0416) XEP-0416: E2E Authentication in XMPP <https://xmpp.org/extensions/xep-0416.html>." > From 4e403e5bd2bf8b3d7641146890b23a4a764b72aa Mon Sep 17 00:00:00 2001 From: Melvin Keskin Date: Sat, 16 Mar 2019 17:21:55 +0100 Subject: [PATCH 13/35] improve introduction --- inbox/automatic-trust-transfer.xml | 30 +++++++++++++++++------------- 1 file changed, 17 insertions(+), 13 deletions(-) diff --git a/inbox/automatic-trust-transfer.xml b/inbox/automatic-trust-transfer.xml index 7a5dfff4..e553d92a 100644 --- a/inbox/automatic-trust-transfer.xml +++ b/inbox/automatic-trust-transfer.xml @@ -41,28 +41,32 @@

    - ATT is used for automatically establishing secure channels protected against active attacks between a new device and existing ones after a single mutual manual authentication between the new device and one of the existing ones. + ATT is used in conjunction with &xep0384; for automatically establishing secure channels protected against active attacks between a new device and existing ones after a single mutual manual authentication between the new device and one of the existing ones. It preserves the security level as if all devices had authenticated their keys manually. - A trusted third party is not required since a usual OMEMO message is used for transferring the information needed to authenticate a key or revoke the trust in that key. - Additionally, it preserves the anonymity of the authentication and revocation since those messages are only sent to devices with authenticated keys. + A trusted third party is not required since an ordinary OMEMO message is used for transferring the information needed to authenticate a public identity key or revoke the trust in that key. + Additionally, it preserves the anonymity of the authentication and revocation since those messages are only sent to devices with authenticated public identity keys. That means an attacker cannot detect whether an authentication or revocation took place.

    - End-to-end encryption without verifying the authenticity of the keys enables users to protect their communication against passive attacks. - This means an attacker cannot read the transferred messages without manipulating the exchanged keys. - But without any other precautions active attacks are still possible. - If an attacker replaces the exchanged keys with a malicious key, the end-to-end encrypted messages can be read and manipulated by the attacker. + End-to-end encryption without verifying the authenticity of the exchanged public identity keys only enables users to protect their communication against passive attacks. + This means an attacker cannot read encrypted messages in transit without actively intervening in the key exchange. + However, without any other precautions active attacks are still possible. + If an attacker replaces the exchanged keys with malicious ones, the end-to-end encrypted messages can be read and manipulated by the attacker.

    - When using &xep0384;, a public identity key is transmitted over a channel which is not protected against active attacks. + When using OMEMO, a public identity key is transmitted over a channel which is not protected against active attacks. That key has to be authenticated by the receiving device over a channel which is protected against active attacks to maintain the confidentiality of sent OMEMO messages and ensuring the authenticity and integrity of received OMEMO messages.

    - When using OMEMO, each device has a different identity key. - That makes it possible for new devices to use end-to-end encryption protecting against passive attacks without transmitting the private key over a secure channel from an existing device to the new one. - However, the downside of this approach is that it increases the number of authentications. - Without ATT all authentications have to be done manually. - With ATT though, only one mutal manual authentication per new key is required. + When using OMEMO, each device has a unique identity key. + For that reason it is not necessary to copy an existing private identity key to a new device enabling it to use end-to-end encryption. + Additionally, it can be used to stop encrypting for a specific device. + For example, that could be done automatically after a given number of sent messages without any reaction from the receiving device that would forward the double ratchet to ensure forward and backward secrecy. +

    +

    + However, the downside of that approach is that it increases the number of key authentications users need to do for each new device to be protected against active attacks. + Without ATT all n-1 mutual authentications per new key have to be done manually. + With ATT though, only one mutual manual authentication per new key is required.

    From c77564a67aa7f2e5c4052670409b80d79dd0c1ec Mon Sep 17 00:00:00 2001 From: Melvin Keskin Date: Sat, 16 Mar 2019 17:34:19 +0100 Subject: [PATCH 14/35] improve glossary --- inbox/automatic-trust-transfer.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/inbox/automatic-trust-transfer.xml b/inbox/automatic-trust-transfer.xml index e553d92a..72cb8522 100644 --- a/inbox/automatic-trust-transfer.xml +++ b/inbox/automatic-trust-transfer.xml @@ -73,7 +73,7 @@
    OMEMO message
    -
    Message encrypted with OMEMO
    +
    Message encrypted using OMEMO
    Device
    @@ -89,7 +89,7 @@
    Key authentication
    -
    Verifying that a key received over an insecure channel is actually the one of the assumed device
    +
    Verification that a key received over an insecure channel is actually the one of the assumed device
    Manual key authentication
    @@ -101,7 +101,7 @@
    Mutual key authentication
    -
    Key authentication in which two devices authenticate the key of each other
    +
    Key authentication in which two devices authenticate each other's key
    Key revocation
    From 88748e637eaa1e9c68e269c42765d53a5f4dfe53 Mon Sep 17 00:00:00 2001 From: Melvin Keskin Date: Sat, 16 Mar 2019 17:35:12 +0100 Subject: [PATCH 15/35] improve section "Advantages" --- inbox/automatic-trust-transfer.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/inbox/automatic-trust-transfer.xml b/inbox/automatic-trust-transfer.xml index 72cb8522..5bc75e14 100644 --- a/inbox/automatic-trust-transfer.xml +++ b/inbox/automatic-trust-transfer.xml @@ -132,12 +132,12 @@ As a result every communication channel between those devices is resistant against active attacks.

    - The network of devices which authenticated each other's keys can be seen as a complete graph with each device as a node and each mutual authentication as an edge. + The network of devices which authenticated each other's keys can be seen as a complete graph where each device is a node and each mutual authentication is an edge. The number of edges grows for each new device by the number of existing nodes. - That means to sustain a secure communication across all devices, a new key has to be authenticated by all n existing devices and vice versa. + This is due to the fact that in order to sustain secure channels between all devices, a new key has to be authenticated by all n existing devices and vice versa.

    - One of those n mutual authentications requires user interaction like scanning each other's QR codes or comparing each other's key identifiers by hand. + One of those n mutual authentications requires user interaction like scanning each other's QR code or comparing each other's key identifier by hand. That is the initial mutual manual authentication. The remaining authentications can be automated relying on the secure channel established by the inital mutual manual authentication and the secure channels already created by the same procedure between the rest of the devices.

    From f75a51c228f9f72d2ace680dc8e364380d928205 Mon Sep 17 00:00:00 2001 From: Melvin Keskin Date: Sat, 16 Mar 2019 17:35:54 +0100 Subject: [PATCH 16/35] improve section "General Procedure" --- inbox/automatic-trust-transfer.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/inbox/automatic-trust-transfer.xml b/inbox/automatic-trust-transfer.xml index 5bc75e14..c5e7c84f 100644 --- a/inbox/automatic-trust-transfer.xml +++ b/inbox/automatic-trust-transfer.xml @@ -152,20 +152,20 @@

    This section explains the basic procedure of autmomatically authenticating or revoking a key by a trust message. It does not specify the detailed behaviour which can be found in section Use Cases. - Instead, this section should rather show the fundamental idea behind it. + Instead, this section should rather show the fundamental idea behind ATT.

    1. Device 1 manually authenticates the key of device 2. - Device 1 automatically sends an authentication message for device 2's key to devices whose keys it has already authenticated and an authentication message for the keys of those devices to device 2. + Device 1 automatically sends an authentication message for device 2's key to devices whose keys it has already authenticated and another authentication message for the keys of those devices to device 2.

    2. Device 2 manually authenticates the key of device 1. - Device 2 automatically sends an authentication message for device 1's key to devices whose keys it has already authenticated and an authentication message for the keys of those devices to device 1. + Device 2 automatically sends an authentication message for device 1's key to devices whose keys it has already authenticated and another authentication message for the keys of those devices to device 1.

    3. From a8905733fdc451e971e1eea1ffe9dbb98865f130 Mon Sep 17 00:00:00 2001 From: Melvin Keskin Date: Sat, 16 Mar 2019 17:43:56 +0100 Subject: [PATCH 17/35] improve section "Use Cases" --- inbox/automatic-trust-transfer.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/inbox/automatic-trust-transfer.xml b/inbox/automatic-trust-transfer.xml index c5e7c84f..66b0f283 100644 --- a/inbox/automatic-trust-transfer.xml +++ b/inbox/automatic-trust-transfer.xml @@ -205,7 +205,7 @@ Alice has the devices A1, A2 and A3. Bob has the device B1. A1 has already authenticated the key of A2. - The other devices have not authenticated the keys of each other. + The other devices have not authenticated each other's key.

      Note that the examples in the following use cases are consecutive and therefore must be read chronologically to properly understand them. @@ -265,7 +265,7 @@

    - MUST authenticate the key as soon as the key of the author of the authentication message is authenticated by the receiving device. + MUST authenticate the key as soon as the key of the device which sent the authentication message is authenticated by the receiving device.

    From d75035dccac3c4ed98960119aaf50b7242f72949 Mon Sep 17 00:00:00 2001 From: Melvin Keskin Date: Sat, 16 Mar 2019 18:58:11 +0100 Subject: [PATCH 18/35] update date --- inbox/automatic-trust-transfer.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/inbox/automatic-trust-transfer.xml b/inbox/automatic-trust-transfer.xml index 66b0f283..cda615e3 100644 --- a/inbox/automatic-trust-transfer.xml +++ b/inbox/automatic-trust-transfer.xml @@ -34,7 +34,7 @@ 0.0.1 - 2019-03-03 + 2019-03-16 mk

    First draft.

         From 2f1a061f0d2be45c04fe6dcb27bf60fd4642cb71 Mon Sep 17 00:00:00 2001 From: Melvin Keskin Date: Sun, 17 Mar 2019 11:41:45 +0100 Subject: [PATCH 19/35] improve section "Use Cases" --- inbox/automatic-trust-transfer.xml | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/inbox/automatic-trust-transfer.xml b/inbox/automatic-trust-transfer.xml index cda615e3..b0ce34f3 100644 --- a/inbox/automatic-trust-transfer.xml +++ b/inbox/automatic-trust-transfer.xml @@ -204,7 +204,7 @@ Alice would like to use OMEMO when communicating with Bob. Alice has the devices A1, A2 and A3. Bob has the device B1. - A1 has already authenticated the key of A2. + A1 has already authenticated A2's key. The other devices have not authenticated each other's key.

    @@ -214,7 +214,7 @@

    Example: - A1 authenticates the key of B1. + A1 authenticates B1's key.

    A device that manually authenticates the key of a contact's device MUST send an authentication message for @@ -265,7 +265,7 @@

- MUST authenticate the key as soon as the key of the device which sent the authentication message is authenticated by the receiving device. + MUST authenticate the key as soon as the receiving device authenticated the key of the device which sent the authentication message.

@@ -273,7 +273,8 @@

Example: - A1 authenticates the key of A3. + A2 has already authenticated A1's and B1's key. + A2 authenticates A3's key.

A device that manually authenticates the key of an own device MUST send an authentication message for @@ -285,7 +286,7 @@

Example: - A1 sends an authentication message for A3's key to A2 and B1. + A2 sends an authentication message for A3's key to A1 and B1.

  • @@ -294,18 +295,18 @@

    Example: - A1 sends an authentication message for A2's and B1's key to A3. + A2 sends an authentication message for A1's and B1's key to A3.

    • - A device that receives an authentication message for a key of an own device from another own device MUST authenticate the key as soon as the key of the device that sent the authentication message is authenticated by the receiving device. + A device that receives an authentication message for a key of an own device from another own device MUST authenticate the key as soon as the receiving device authenticated the key of the device which sent the authentication message.

    Example: - A2 authenticates A3's key by the authentication message from A1 as soon as A2 authenticated A1's key. + A1 authenticates A3's key by the authentication message from A2 as soon as A1 authenticated A2's key.

    From eab01b84479766dffe9b717196d205ecdc6bc2ff Mon Sep 17 00:00:00 2001 From: Steve Kille Date: Mon, 18 Mar 2019 16:47:54 +0000 Subject: [PATCH 20/35] Remove MIX xmlns from pubsub channel info <item/> example --- xep-0369.xml | 25 +++++++++++-------------- 1 file changed, 11 insertions(+), 14 deletions(-) diff --git a/xep-0369.xml b/xep-0369.xml index e1251714..1595c2af 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -35,6 +35,14 @@ MIX-CORE &ksmithisode; &skille; + + 0.14.2 + 2019-03-18 + sek +

    + Replace <submission-id/> with XEP-0359; +

    +     0.14.1 2019-01-05 @@ -1226,21 +1234,10 @@

    - The messages sent to participants have a different message id to the originally submitted message. This does not impact most recipients, but it does not allow the message originator to correlate the message with the submitted message. To address this the MIX channel MUST include an additional <submission-id> element in the <mix> element of the message copy going back to the originator's bare JID. The <submission-id> element holds the original id provided by the sender. This enables the originator to correlate the received message with the message submitted. + The message originator may wish to correlate the reflected message with the submitted message. To do this, the originator should include an <origin-id> element in the message as specified in &xep0359;. +

    - - Harpier cries: 'tis time, 'tis time. - - thirdwitch - hag66@shakespeare.example - 92vax143g - - -]]> + From 62e7a5049e1d06739b40a3e2f6227b1c5d828e62 Mon Sep 17 00:00:00 2001 From: Steve Kille Date: Mon, 18 Mar 2019 16:54:24 +0000 Subject: [PATCH 21/35] Make Message Archiving Optional; --- xep-0369.xml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/xep-0369.xml b/xep-0369.xml index 1595c2af..804f8925 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -48,7 +48,8 @@ 2019-01-05 lnj

    - Remove MIX xmlns from pubsub channel info <item/> example + Remove MIX xmlns from pubsub channel info <item/> example; + Make Message Archiving Optional;

    @@ -1242,7 +1243,7 @@

    - All messages sent to a MIX channel MUST be archived using MAM in association with the MIX channel. All messages MUST also be archived on the server associated with each channel participant receiving the message, which enables clients to always retrieve messages from the clients MAM archive. Other channel nodes MAY be archived. + MIX channel nodes MAY be archived. In order to provide a service equivalent to MUC, it is necessary to archive messages sent to the channel. It is anticipated the most MIX services will archive at least messages using MAM.

    From abddabedea34d6b881f28e8ed8bbb3c1b5e6d894 Mon Sep 17 00:00:00 2001 From: Steve Kille Date: Mon, 18 Mar 2019 17:04:03 +0000 Subject: [PATCH 22/35] Clarify that participant node only contains real JIDs; --- xep-0369.xml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/xep-0369.xml b/xep-0369.xml index 804f8925..f7a905eb 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -50,6 +50,7 @@

    Remove MIX xmlns from pubsub channel info <item/> example; Make Message Archiving Optional; + Clarify that participant node only contains real JIDs;

    @@ -642,7 +643,7 @@ Where a nick is provided for a user, it is generally recommended to use this nick to display the user. This enables consistent representation of participants for all participants in the channel.

    - The real JID of the user MAY be held in the participants node. When the real JID is not present, the procedures defined in MIX-ANON must be followed. + The real JID of the user MAY be held in the participants node. When the real JID is not present, the procedures defined in MIX-ANON must be followed. Note that only the real JID may be held in participants node. Any JID derived from the stable ID MUST NOT be held. The user's JID is stored in a <jid/> child element of the <participant/> element.

    From f31e54e29b5acaefb61c2d8ac2ecc660e8ecbbf3 Mon Sep 17 00:00:00 2001 From: Steve Kille Date: Tue, 19 Mar 2019 08:46:19 +0000 Subject: [PATCH 23/35] Make Archiving Optional; --- xep-0405.xml | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/xep-0405.xml b/xep-0405.xml index 8c8921eb..9f141e64 100644 --- a/xep-0405.xml +++ b/xep-0405.xml @@ -38,11 +38,19 @@ MIX-PAM &ksmithisode; &skille; + + 0.4.0 + 2019-03-19 + sek + + Make Archiving Optional; + + 0.3.1 2019-01-13 lnj (Editor: jsc) - Whitespace changes and XML syntax fixes + White space changes and XML syntax fixes 0.3.0 @@ -186,7 +194,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa

    - Servers supporting this specification MUST advertise this to clients for which they wish to support this specification. A client wishing to use MIX MUST check for this capability in the local server before using MIX, by verifying support for the client's account. The capability is represented by the 'urn:xmpp:mix:pam:0' feature. + Servers supporting this specification MUST advertise this to clients for which they wish to support this specification. A client wishing to use MIX MUST check for this capability in the local server before using MIX, by verifying support for the client's account. The capability is represented by the 'urn:xmpp:mix:pam:0' feature. In addition to this the server MAY advertize the 'urn:xmpp:mix:pam:0#archive' feature, which shows that the local server archives MIX messages.

    + ]]> @@ -514,7 +523,8 @@ This approach enables flexible support of multiple clients for a MIX channel pa

    - Archive of MIX channel messages is done by the participant's server. Where a message is sent to the participant's server and discarded because there are no active clients, it will still be archived. This means that the messages will be available in the local archive and can be picked up by clients when they come online. + Archive of MIX channel messages MAY be performed by the participant's server. When this is done, the capability is advertized to MIX clients using the 'urn:xmpp:mix:pam:0#archive' feature. If archive is provided it MUST always be used, so that + where a message is sent to the participant's server and discarded because there are no active clients, it will still be archived. This means that when archiving is provided, the messages will be available in the local archive and can be picked up by clients when they come online.

    From 626ede0623734d25b6fc601c84e7aa44a46d2f4e Mon Sep 17 00:00:00 2001 From: Steve Kille Date: Tue, 19 Mar 2019 08:48:45 +0000 Subject: [PATCH 24/35] Bump namespace to pam:1; --- xep-0405.xml | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/xep-0405.xml b/xep-0405.xml index 9f141e64..f0ee8861 100644 --- a/xep-0405.xml +++ b/xep-0405.xml @@ -44,6 +44,7 @@ sek Make Archiving Optional; + Bump namespace to pam:1;     @@ -194,7 +195,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa

    - Servers supporting this specification MUST advertise this to clients for which they wish to support this specification. A client wishing to use MIX MUST check for this capability in the local server before using MIX, by verifying support for the client's account. The capability is represented by the 'urn:xmpp:mix:pam:0' feature. In addition to this the server MAY advertize the 'urn:xmpp:mix:pam:0#archive' feature, which shows that the local server archives MIX messages. + Servers supporting this specification MUST advertise this to clients for which they wish to support this specification. A client wishing to use MIX MUST check for this capability in the local server before using MIX, by verifying support for the client's account. The capability is represented by the 'urn:xmpp:mix:pam:1' feature. In addition to this the server MAY advertize the 'urn:xmpp:mix:pam:1#archive' feature, which shows that the local server archives MIX messages.

    - - + + ]]> @@ -231,7 +232,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa

    A user joins a channel by sending a MIX "client-join" command from one of the user's clients, which wraps the "join" command specified in &xep0369;. &xep0369; specifies how the join command works, and so this specification considers only the wrapping and client actions. - The <client-join/> is a child element of <iq/> element. The <client-join/> element is qualified by the 'urn:xmpp:mix:pam:0' namespace. The channel being joined is specified by a 'channel' attribute in the <client-join/> element, which is used by the server to correctly address the join. The <join> is specified in &xep0369; and is a child element of <client-join/>. + The <client-join/> is a child element of <iq/> element. The <client-join/> element is qualified by the 'urn:xmpp:mix:pam:1' namespace. The channel being joined is specified by a 'channel' attribute in the <client-join/> element, which is used by the server to correctly address the join. The <join> is specified in &xep0369; and is a child element of <client-join/>.

    - + @@ -294,7 +295,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa from='hag66@shakespeare.example' to='hag66@shakespeare.example/UUID-a1j/7533' id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> - + @@ -317,7 +318,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa

    Users generally remain in a channel for an extended period of time. The process for leaving a MIX channel is specified in &xep0369;. When a user desires to leave a channel, it will issue a client-leave request to the local server. - The <client-leave/> is a child element of <iq/> element. The <client-leave/> element is qualified by the 'urn:xmpp:mix:pam:0' namespace. The channel being left is specified by a 'channel' attribute in the <client-leave/> element, which is used by the server to correctly address the join. The <leave> is specified in &xep0369; and is a child element of <client-leave/>. + The <client-leave/> is a child element of <iq/> element. The <client-leave/> element is qualified by the 'urn:xmpp:mix:pam:1' namespace. The channel being left is specified by a 'channel' attribute in the <client-leave/> element, which is used by the server to correctly address the join. The <leave> is specified in &xep0369; and is a child element of <client-leave/>. This shown in the following example.

    @@ -326,7 +327,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa from='hag66@shakespeare.example/UUID-a1j/7533' to='hag66@shakespeare.example' id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> - @@ -369,7 +370,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa from='hag66@shakespeare.example' to='hag66@shakespeare.example/UUID-a1j/7533' id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> - + @@ -523,7 +524,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa

    - Archive of MIX channel messages MAY be performed by the participant's server. When this is done, the capability is advertized to MIX clients using the 'urn:xmpp:mix:pam:0#archive' feature. If archive is provided it MUST always be used, so that + Archive of MIX channel messages MAY be performed by the participant's server. When this is done, the capability is advertized to MIX clients using the 'urn:xmpp:mix:pam:1#archive' feature. If archive is provided it MUST always be used, so that where a message is sent to the participant's server and discarded because there are no active clients, it will still be archived. This means that when archiving is provided, the messages will be available in the local archive and can be picked up by clients when they come online.

    From 60937a902c8c3f1101ccdcad278617d0202f9f45 Mon Sep 17 00:00:00 2001 From: Steve Kille Date: Tue, 19 Mar 2019 09:01:58 +0000 Subject: [PATCH 25/35] Change message retrieval from archive to reflect that MIX-PAM archive is now optional; --- xep-0369.xml | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/xep-0369.xml b/xep-0369.xml index f7a905eb..7deb0d5e 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -41,6 +41,9 @@ sek

    Replace <submission-id/> with XEP-0359; + Make Message Archiving Optional; + Clarify that participant node only contains real JIDs; + Change message retrieval from archive to reflect that MIX-PAM archive is now optional;

    @@ -49,8 +52,6 @@ lnj

    Remove MIX xmlns from pubsub channel info <item/> example; - Make Message Archiving Optional; - Clarify that participant node only contains real JIDs;

    @@ -1253,10 +1254,11 @@

    - Clients will retrieve MIX messages using standard MAM protocol from the user's archive. The MAM query will filter based on the channel JID to enable access to messages from a given channel. This gives the user a simple mechanism to access all messages sent to the channel. MAM can be used to retrieve older messages that have not been cached by the client. + The client's local server MAY archive messages and advertise this capability as specified in &xep0405;. If this is done, + clients MUST retrieve MIX messages using standard MAM protocol from the user's archive. The MAM query will filter based on the channel JID to enable access to messages from a given channel. This gives the user a simple mechanism to access all messages sent to the channel. MAM can be used to retrieve older messages that have not been cached by the client.

    - Messages can also be retrieved from the channel by addressing MAM queries to the channel JID. This will behave like a standard MAM archive. This can be useful for administrators to access archived messages. It can also be useful for new channel participants to access the historical archives. + Messages can also be retrieved from the channel by addressing MAM queries to the channel JID. This will behave like a standard MAM archive. This can be useful for administrators to access archived messages. This enables new channel participants to access the historical archives.

    From 20124667e6c5a7fd4ba28d2ad32a382f7436fec5 Mon Sep 17 00:00:00 2001 From: Steve Kille Date: Tue, 19 Mar 2019 16:13:30 +0000 Subject: [PATCH 26/35] Bump namespace to core:1; --- xep-0369.xml | 85 ++++++++++++++++++++++++++-------------------------- 1 file changed, 43 insertions(+), 42 deletions(-) diff --git a/xep-0369.xml b/xep-0369.xml index 7deb0d5e..db510fa0 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -44,6 +44,7 @@ Make Message Archiving Optional; Clarify that participant node only contains real JIDs; Change message retrieval from archive to reflect that MIX-PAM archive is now optional; + Bump namespace to core:1;

    @@ -632,7 +633,7 @@ -

    Each channel participant is represented as an item of the 'urn:xmpp:mix:nodes:participants' channel node. Each item is named by the Stable Participant ID of the participant. For example '123456' might name the node item associated with participant 'hag66@shakespeare.example'. Information is stored in a <participant/> element qualified by the 'urn:xmpp:mix:core:0' namespace. +

    Each channel participant is represented as an item of the 'urn:xmpp:mix:nodes:participants' channel node. Each item is named by the Stable Participant ID of the participant. For example '123456' might name the node item associated with participant 'hag66@shakespeare.example'. Information is stored in a <participant/> element qualified by the 'urn:xmpp:mix:core:1' namespace.

    A Nick MAY be associated with a participant, which provides a user-oriented description of the participant. The nick associated with the user is stored in a <nick/> child element of the <participant/> element. The nick for each channel participant MUST be different to the nick of other participants (where nicks have been assigned). @@ -660,7 +661,7 @@ - + thirdwitch hag66@shakespeare.example @@ -694,7 +695,7 @@ - urn:xmpp:mix:core:0 + urn:xmpp:mix:core:1 Witches Coven @@ -763,7 +764,7 @@ ]]> -

    The MIX service then MUST return its identity and the features it supports, which MUST include the 'urn:xmpp:mix:core:0' feature, and the identity MUST have a category of 'conference' and a type of 'mix', as shown in the following example:

    +

    The MIX service then MUST return its identity and the features it supports, which MUST include the 'urn:xmpp:mix:core:1' feature, and the identity MUST have a category of 'conference' and a type of 'mix', as shown in the following example:

    - - + + ]]>

    - A MIX service MUST return the 'urn:xmpp:mix:core:0' feature and MAY return the other features listed here: + A MIX service MUST return the 'urn:xmpp:mix:core:1' feature and MAY return the other features listed here:

      -
    • 'urn:xmpp:mix:core:0': This indicates support of MIX, and is returned by all MIX services.
      • -
    • 'urn:xmpp:mix:core:0#searchable': This is shown in the above example and indicates that a the MIX Service MAY be searched for channels. This presence of this feature can be used by a client to guide the user to search for channels in a MIX service.
      • -
    • 'urn:xmpp:mix:core:0#create-channel': This is described in Checking for Permission to Create a Channel in support of channel administration. When an end user client needs to create channels, perhaps for short term usage, this feature helps the client to identify an MIX service to use. It enables a configuration where permanent (searchable) channels are placed in one MIX service and clients will be able to create channels in another MIX service which is not searchable.
      • +
    • 'urn:xmpp:mix:core:1': This indicates support of MIX, and is returned by all MIX services.
      • +
    • 'urn:xmpp:mix:core:1#searchable': This is shown in the above example and indicates that a the MIX Service MAY be searched for channels. This presence of this feature can be used by a client to guide the user to search for channels in a MIX service.
      • +
    • 'urn:xmpp:mix:core:1#create-channel': This is described in Checking for Permission to Create a Channel in support of channel administration. When an end user client needs to create channels, perhaps for short term usage, this feature helps the client to identify an MIX service to use. It enables a configuration where permanent (searchable) channels are placed in one MIX service and clients will be able to create channels in another MIX service which is not searchable.

    A MIX service MUST NOT advertise support for &xep0313;, as MAM is supported by the channels and not by the service. A MIX service MUST NOT advertise support for generic &xep0060;, as although MIX makes use of PubSub it is not a generic PubSub service.

    @@ -834,7 +835,7 @@ category='conference' name='A Dark Cave' type='mix'/> - + @@ -893,7 +894,7 @@ - urn:xmpp:mix:core:0 + urn:xmpp:mix:core:1 Witches Coven @@ -934,13 +935,13 @@ - + thirdwitch hag66@shakespeare.example - + top witch hecate@shakespeare.example @@ -973,7 +974,7 @@ - + ]]> @@ -988,7 +989,7 @@

    -

    A user joins a channel by sending a MIX "join" command from one of the user's clients, which will be relayed to the server as specified in MIX-PAM. There is no default set of nodes, so the user MUST specify the set of nodes to be subscribed to. To achieve the equivalent service to MUC, a user would subscribe to both messages and presence nodes. A user will typically subscribe to at least the message and/or presence nodes but MAY join and not subscribe to any nodes. Note that the presence node is specified in MIX-PRESENCE. The <join/> is a child element of <iq/> element. The <join/> element is qualified by the 'urn:xmpp:mix:core:0' namespace. The requested nodes are encoded as <subscribe/> child elements of the <join/> element. A nick MAY be specified as a <nick/> child elements of the <join/> element.

    +

    A user joins a channel by sending a MIX "join" command from one of the user's clients, which will be relayed to the server as specified in MIX-PAM. There is no default set of nodes, so the user MUST specify the set of nodes to be subscribed to. To achieve the equivalent service to MUC, a user would subscribe to both messages and presence nodes. A user will typically subscribe to at least the message and/or presence nodes but MAY join and not subscribe to any nodes. Note that the presence node is specified in MIX-PRESENCE. The <join/> is a child element of <iq/> element. The <join/> element is qualified by the 'urn:xmpp:mix:core:1' namespace. The requested nodes are encoded as <subscribe/> child elements of the <join/> element. A nick MAY be specified as a <nick/> child elements of the <join/> element.

    The join leads to the server subscribing the user to each of the requested nodes associated with the channel. The MIX service will also add the user to the participant list by injecting a new item into the "urn:xmpp:mix:nodes:participants" node automatically.

    The default MIX model is that only channel participants are allowed to subscribe to nodes. A MIX channel MAY allow non-participant subscription to some nodes. This will be handled by clients directly subscribing to the desired PubSub nodes.

    The user's server needs to make roster changes as part of the join functionality, as specified in MIX-PAM. This means that the join request to the MIX service will come from the user's server from the user's bare JID.

    @@ -997,7 +998,7 @@ from='hag66@shakespeare.example' to='coven@mix.shakespeare.example' id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> - + @@ -1014,7 +1015,7 @@ from='coven@mix.shakespeare.example' to='hag66@shakespeare.example' id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> - @@ -1036,7 +1037,7 @@ from='hag66@shakespeare.example' to='coven@mix.shakespeare.example' id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> - @@ -1055,7 +1056,7 @@ - + hag66@shakespeare.example third witch @@ -1068,14 +1069,14 @@

    - A user MAY subsequently modify subscription to nodes in a channel by sending a subscription modification request encoded as a <update-subscription/> child element of <iq/> element. The <update-subscription/> element is qualified by the 'urn:xmpp:mix:core:0' namespace. The requested notes are encoded as <subscribe/> child elements of the <update-subscription/> element with the node name encoded as a 'node' attribute. This modification goes directly from client to MIX channel, as this change does not impact the roster and so does not need any local action. The following example shows subscription modification. + A user MAY subsequently modify subscription to nodes in a channel by sending a subscription modification request encoded as a <update-subscription/> child element of <iq/> element. The <update-subscription/> element is qualified by the 'urn:xmpp:mix:core:1' namespace. The requested notes are encoded as <subscribe/> child elements of the <update-subscription/> element with the node name encoded as a 'node' attribute. This modification goes directly from client to MIX channel, as this change does not impact the roster and so does not need any local action. The following example shows subscription modification.

    - + @@ -1084,7 +1085,7 @@ from='coven@mix.shakespeare.example' to='hag66@shakespeare.example/UUID-a1j/7533' id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> - @@ -1095,13 +1096,13 @@

    -

    Users generally remain in a channel for an extended period of time. In particular the user remains as a participant the channel when the user goes offline. Note that this is different to &xep0045;, where the client leaves a room when going offline. So, leaving a MIX channel is a permanent action for a user across all clients. In order to leave a channel, the user's server sends a MIX "leave" command to the channel, as specified in MIX-PAM. The leave command is encoded as a <leave/> child element of <iq/> element. The <leave/> element is qualified by the 'urn:xmpp:mix:core:0' namespace. The following example shows a leave request to a MIX channel.

    +

    Users generally remain in a channel for an extended period of time. In particular the user remains as a participant the channel when the user goes offline. Note that this is different to &xep0045;, where the client leaves a room when going offline. So, leaving a MIX channel is a permanent action for a user across all clients. In order to leave a channel, the user's server sends a MIX "leave" command to the channel, as specified in MIX-PAM. The leave command is encoded as a <leave/> child element of <iq/> element. The <leave/> element is qualified by the 'urn:xmpp:mix:core:1' namespace. The following example shows a leave request to a MIX channel.

    - + ]]> @@ -1113,7 +1114,7 @@ from='coven@mix.shakespeare.example' to='hag66@shakespeare.example' id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> - + ]]>

    When the user leaves the channel, the MIX service is responsible for unsubscribing the user from all nodes in the channel and for removing the user from the participants list. Presence removal is specified in MIX-PRESENCE. @@ -1145,14 +1146,14 @@

  • The MIX service generates the nick.

    • - A user will typically set a nick when joining a channel and MAY update this nick from time to time. The user does this by sending a command to the channel to set the nick. This command is a <setnick/> child element of <iq/> element. The <setnick/> element is qualified by the 'urn:xmpp:mix:core:0' namespace. The nick is encoded as a <nick/> child element of the <setnick/> element. If the user wishes the channel to assign a nick (or knows that the channel will assign a nick) the nick field can be left blank, so that the user can see what is assigned in the result. + A user will typically set a nick when joining a channel and MAY update this nick from time to time. The user does this by sending a command to the channel to set the nick. This command is a <setnick/> child element of <iq/> element. The <setnick/> element is qualified by the 'urn:xmpp:mix:core:1' namespace. The nick is encoded as a <nick/> child element of the <setnick/> element. If the user wishes the channel to assign a nick (or knows that the channel will assign a nick) the nick field can be left blank, so that the user can see what is assigned in the result.

    - + thirdwitch @@ -1166,7 +1167,7 @@ from='coven@mix.shakespeare.example' to'hag66@shakespeare.example/UUID-a1j/7533' id='7nve413p'> - + thirdwitch @@ -1197,7 +1198,7 @@ ]]>

    - The MIX channel then adds information to the message using a <mix> element qualified by the 'urn:xmpp:mix:core:0' namespace. This enables are receiver of the MIX message to determine the message sender. This element contains two child elements: + The MIX channel then adds information to the message using a <mix> element qualified by the 'urn:xmpp:mix:core:1' namespace. This enables are receiver of the MIX message to determine the message sender. This element contains two child elements:

    1. A <nick> element that contains the Nick of the message sender, taken from the Participants Node. This MUST be present if a Nick is defined for the user.
      2. @@ -1215,7 +1216,7 @@ id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD' type='groupchat'> Harpier cries: 'tis time, 'tis time. - + thirdwitch hag66@shakespeare.example @@ -1228,7 +1229,7 @@ id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD' type='groupchat'> Harpier cries: 'tis time, 'tis time. - + thirdwitch hag66@shakespeare.example @@ -1274,7 +1275,7 @@

      - MIX does not standardize an access control model for creating and deleting MIX channels. The choice is left to the MIX implementer, and could be a very simple or complex approach. A client can determine if it has permission to create a channel on a MIX service, which MAY be used to control options presented to the user. This is achieved by a disco command on the MIX service. If the 'urn:xmpp:mix:core:0#create-channel' feature is returned, the user is able to create a channel. + MIX does not standardize an access control model for creating and deleting MIX channels. The choice is left to the MIX implementer, and could be a very simple or complex approach. A client can determine if it has permission to create a channel on a MIX service, which MAY be used to control options presented to the user. This is achieved by a disco command on the MIX service. If the 'urn:xmpp:mix:core:1#create-channel' feature is returned, the user is able to create a channel.

      - - + + ]]>

      - A client creates a channel by sending a simple request to the MIX service. A channel is always created with default parameters, as shown in the following example. The result MUST include the name of the channel which MUST match the channel name in the request (if present). The create is encoded as a <create/> child element of <iq/> element. The <create/> is qualified by the 'urn:xmpp:mix:core:0' namespace. The <create/> element MUST have a 'channel' attribute to specify the channel name. This attribute specifies the value that will be used in the LHS of the JID for the MIX channel. + A client creates a channel by sending a simple request to the MIX service. A channel is always created with default parameters, as shown in the following example. The result MUST include the name of the channel which MUST match the channel name in the request (if present). The create is encoded as a <create/> child element of <iq/> element. The <create/> is qualified by the 'urn:xmpp:mix:core:1' namespace. The <create/> element MUST have a 'channel' attribute to specify the channel name. This attribute specifies the value that will be used in the LHS of the JID for the MIX channel.

      - + - + ]]> @@ -1335,14 +1336,14 @@ id='lx09df27' to='mix.shakespeare.example' type='set'> - + - + ]]>       @@ -1353,7 +1354,7 @@ MIX channels are always explicitly destroyed by an owner of the channel or by a server operator. There is no concept of temporary channel, equivalent to &xep0045; temporary room which is automatically destroyed by the server when the users leave. However, channels MAY be configured with an explicit lifetime, after which the channel MUST be removed by the MIX service; This is specified in MIX-ADMIN. Where a channel is created for ad hoc use, it MAY be desirable to keep the channel for history reference or for re-use by the same set of users. Note that the owner of the channel does not need to have presence registered in the channel in order to destroy it.

      - The destroy operation is encoded as a <destroy/> child element of an <iq/> element. The <destroy/> element is qualified by the 'urn:xmpp:mix:core:0' namespace. The <destroy/> element MUST have a 'channel' attribute to specify the channel to be destroyed. + The destroy operation is encoded as a <destroy/> child element of an <iq/> element. The <destroy/> element is qualified by the 'urn:xmpp:mix:core:1' namespace. The <destroy/> element MUST have a 'channel' attribute to specify the channel to be destroyed. A client destroys a channel using a simple set operation, as shown in the following example.

      - + Date: Tue, 19 Mar 2019 22:03:49 +0000 Subject: [PATCH 27/35] delete space --- xep-0405.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xep-0405.xml b/xep-0405.xml index f0ee8861..7f59e9f8 100644 --- a/xep-0405.xml +++ b/xep-0405.xml @@ -209,7 +209,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa type='result'> - + ]]> From ef713ab52086f6e0934b16018433cabced16898f Mon Sep 17 00:00:00 2001 From: O01eg Date: Wed, 20 Mar 2019 21:12:48 +0300 Subject: [PATCH 28/35] Fix typo in XEP-0199 --- xep-0199.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xep-0199.xml b/xep-0199.xml index 82004e8c..4a784290 100644 --- a/xep-0199.xml +++ b/xep-0199.xml @@ -180,7 +180,7 @@ + type='error'> From 7a7a8e9b23b0dcbfdf1a08426c8b96d96396363c Mon Sep 17 00:00:00 2001 From: Melvin Keskin Date: Fri, 22 Mar 2019 19:45:16 +0100 Subject: [PATCH 29/35] improve glossary --- inbox/automatic-trust-transfer.xml | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/inbox/automatic-trust-transfer.xml b/inbox/automatic-trust-transfer.xml index b0ce34f3..c715faa5 100644 --- a/inbox/automatic-trust-transfer.xml +++ b/inbox/automatic-trust-transfer.xml @@ -120,8 +120,20 @@
      OMEMO message which indicates that specific keys can be trusted (authentication) or no longer trusted (revocation). A trust message for a device's key sent to another device is a trust message that contains the key identifer of the given key for authentication or revocation. - If a trust message only contains key identifiers for authentication, it is called authentication message. - If it only contains key identifiers for revocation, it is called revocation message. +
      + + +
      Authentication message
      +
      + Trust message which only contains key identifiers for authentication. + If a trust message contains authentication and revocation parts, the term authentication message is used for referring to the trust message without revocation parts. +
      +       + +
      Revocation message
      +
      + Trust message which only contains key identifiers for revocation. + If a trust message contains authentication and revocation parts, the term revocation message is used for referring to the trust message without authentication parts.
      From 29a7ea0640c2b183f842ba54ba45b244f3973036 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Maxime=20=E2=80=9Cpep=E2=80=9D=20Buquet?= Date: Sat, 23 Mar 2019 22:22:54 +0000 Subject: [PATCH 30/35] XEP-0277: Fix typos/wording MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Maxime “pep” Buquet --- xep-0277.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/xep-0277.xml b/xep-0277.xml index b15c50e4..d6ad04eb 100644 --- a/xep-0277.xml +++ b/xep-0277.xml @@ -104,7 +104,7 @@ -

      A person's microblog SHOULD be located at a personal eventing (PEP) node whose name is "urn:xmpp:microblog:0" but MAY be located at a generic publish-subscribe node that is not attached to a user's IM account. For instance, if the Shakespearean character Romeo has a JabberID of <romeo@montague.lit> then his microblog would be located at that JID with a node of "urn:xmpp:microblog:0". Outside of native XMPP systems, this node can be referred to as the following XMPP URI (see XEP-0060 § 12.21).

      +

      A person's microblog SHOULD be located at a personal eventing (PEP) node named "urn:xmpp:microblog:0" but MAY be located at a generic publish-subscribe node that is not attached to a user's IM account. For instance, if the Shakespearean character Romeo has a JabberID of <romeo@montague.lit> then his microblog would be located at that JID with a node of "urn:xmpp:microblog:0". Outside of native XMPP systems, this node can be referred to as the following XMPP URI (see XEP-0060 § 12.21).

      @@ -195,7 +195,7 @@ xmpp:romeo@montague.lit?;node=urn%3Axmpp%3Amicroblog%3A0 ]]> -

      Note: these alternate links were not posted by client because client can't compute them itself. These things SHOULD be inserted at server side though.

      +

      Note: these alternate links were not posted by the original client because clients can't compute them themselves. These things SHOULD be inserted at server side though.

      Anyone can publish a post in reply to Romeo's post. Here we assume that a reply comes from Benvolio.

      @@ -369,7 +369,7 @@ xmpp:romeo@montague.lit?;node=urn%3Axmpp%3Amicroblog%3A0       -

      In order to provide users with some metadata (i.e. blog title or author information) about the microblog, the client MUST to add an item with such information. The client MUST set the ID of the item to "0".

      +

      In order to provide users with some metadata (i.e. blog title or author information) about the microblog, the client MUST add an item with such information. The client MUST set the ID of the item to "0".

      Date: Sun, 24 Mar 2019 10:14:11 +0100 Subject: [PATCH 31/35] update date --- inbox/automatic-trust-transfer.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/inbox/automatic-trust-transfer.xml b/inbox/automatic-trust-transfer.xml index c715faa5..55479ca6 100644 --- a/inbox/automatic-trust-transfer.xml +++ b/inbox/automatic-trust-transfer.xml @@ -34,7 +34,7 @@ 0.0.1 - 2019-03-16 + 2019-03-22 mk

      First draft.

             From 72aa3035bff9c45b5471dcb7042f0301d522c6f4 Mon Sep 17 00:00:00 2001 From: Alexis Jeandeau Date: Mon, 25 Mar 2019 22:40:12 +0900 Subject: [PATCH 32/35] XEP-0050: Fix variable name in example 14 According to the previous example, the first variable is called "runlevel", not "mode". --- xep-0050.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xep-0050.xml b/xep-0050.xml index c724d98c..4d8b5028 100644 --- a/xep-0050.xml +++ b/xep-0050.xml @@ -418,7 +418,7 @@ sessionid='config:20020923T213616Z-700' node='config'> - + 3 From 21c6438a5dbbd2645bd0dc62008d3b123a31cff8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonas=20Sch=C3=A4fer?= Date: Tue, 26 Mar 2019 16:33:23 +0100 Subject: [PATCH 33/35] XEP-0050: add revision block --- xep-0050.xml | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/xep-0050.xml b/xep-0050.xml index 4d8b5028..1d553b22 100644 --- a/xep-0050.xml +++ b/xep-0050.xml @@ -25,6 +25,12 @@ http://www.xmpp.org/schemas/commands.xsd &linuxwolf; + + 1.2.3 + 2019-03-26 + XEP Editor (jsc) + Fix typo in example (mode => runlevel) + 1.2.2 2016-12-03 From d73e18faf081bc296d19de4ab3b749d26c556cf5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonas=20Sch=C3=A4fer?= Date: Tue, 26 Mar 2019 16:36:54 +0100 Subject: [PATCH 34/35] XEP-0199: add revision block --- xep-0199.xml | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/xep-0199.xml b/xep-0199.xml index 4a784290..8ec426ec 100644 --- a/xep-0199.xml +++ b/xep-0199.xml @@ -25,6 +25,12 @@ http://www.xmpp.org/schemas/ping.xsd &stpeter; + + 2.0.1 + 2019-03-26 + o01eg + Fix incorrect IQ type in example (result => error) + 2.0 2009-06-03 From feea155175e0c9f44632042b7351625e56bf0601 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonas=20Sch=C3=A4fer?= Date: Tue, 26 Mar 2019 16:35:25 +0100 Subject: [PATCH 35/35] XEP-0277: add revision block --- xep-0277.xml | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/xep-0277.xml b/xep-0277.xml index d6ad04eb..ebc6f912 100644 --- a/xep-0277.xml +++ b/xep-0277.xml @@ -34,6 +34,12 @@ valerian@jappix.com https://valeriansaliou.name/ + + 0.6.3 + 2019-03-26 + pep + Wording fixes + 0.6.2 2017-11-28