diff --git a/inbox/automatic-trust-transfer.xml b/inbox/automatic-trust-transfer.xml
new file mode 100644
index 00000000..55479ca6
--- /dev/null
+++ b/inbox/automatic-trust-transfer.xml
@@ -0,0 +1,431 @@
+
+
+ OMEMO glossary First draft.
+ 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 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 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 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 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.
+
+ 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 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.
+ 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 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.
+
+ 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.
+
+ 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 ATT.
+
+ 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 another authentication message for the keys of those devices to device 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 another authentication message for the keys of those devices to device 1.
+
+ 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.
+
+ 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.
+
+ 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:
+
+ 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 A2's key.
+ 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.
+
+ Example:
+ A1 authenticates B1's key.
+
+ A device that manually authenticates the key of a contact's device MUST send an authentication message for
+
+ 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.
+
+ 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.
+
+ A device that receives an authentication message for a key of a contact's device from
+
+ an own device
+
+ Example:
+ A2 authenticates B1's key by the authentication message from A1 as soon as A2 authenticated A1's key.
+
+ 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.
+
+ MUST authenticate the key as soon as the receiving device authenticated the key of the device which sent the authentication message.
+
+ Example:
+ 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
+
+ the key that has been authenticated to each other device with an already authenticated key.
+
+ Example:
+ A2 sends an authentication message for A3's key to A1 and B1.
+
+ each already authenticated key of all devices to the device whose key has been authenticated.
+
+ Example:
+ 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 receiving device authenticated the key of the device which sent the authentication message.
+
+ Example:
+ A1 authenticates A3's key by the authentication message from A2 as soon as A1 authenticated A2'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 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.
+
+ 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.
+
+ 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. 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). 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. 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".
+ 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;
+ Bump namespace to core:1;
+
- Remove MIX xmlns from pubsub channel info <item/> example
+ Remove MIX xmlns from pubsub channel info <item/> example;
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).
@@ -633,7 +645,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.
@@ -649,7 +661,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:
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.
+
+
+
+
+
+
+
+
+
+
@@ -195,7 +201,7 @@ xmpp:romeo@montague.lit?;node=urn%3Axmpp%3Amicroblog%3A0
]]>
-
-
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.
@@ -986,7 +998,7 @@ from='hag66@shakespeare.example' to='coven@mix.shakespeare.example' id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'> -- 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.
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.
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. @@ -1134,14 +1146,14 @@
- 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.
- 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:
- 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;. +
-- 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.
@@ -1254,10 +1255,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.
- 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.
- 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.
- 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: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.
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/>.
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.
@@ -317,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'> -- 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: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.
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:
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,
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:
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: