First draft.
+ End-to-end encryption without verifying the authenticity of the exchanged public long-term keys only enables the endpoints 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 or introduces a new malicious endpoint with an own key, the end-to-end encrypted messages can be read and manipulated by the attacker. +
++ When using end-to-end encryption where public long-term keys are transmitted over a channel which is not protected against active attacks, the authenticity of those keys is not guaranteed. + Such a key has to be authenticated by the receiving endpoint over a channel which is protected against active attacks to maintain the confidentiality of sent messages and ensure the authenticity and integrity of received messages. +
++ A trust message is an XMPP message that contains the information of whether the sending endpoint trusts a specific public long-term key. + The authenticity and integrity of the message is ensured by a signing mechanism. + Trust messages can be used in conjunction with an end-to-end encryption protocol like &xep0373; or &xep0384; e.g. to automatically or semi-automatically establish secure channels protected against active attacks. +
++ Furthermore, the fact that an endpoint trusts a key or not can be kept confidential toward an attacker by encrypting those messages and sending them only to endpoints with authenticated keys. + That means particularly that an attacker cannot detect by the content of a trust message whether an authentication of a key took place. + An authentication will therefore stay anonymous toward an attacker. + The encryption protects against passive attacks since an attacker cannot read the content of the trust message. + The restriction to send trust messages only to endpoints with authenticated keys in addition to the encryption protects against active attacks since the attacker will not, after introducing a malicious key, receive a trust message encrypted with that key. +
++ A trust message MUST be signed in a way to ensure its authenticity and integrity. +
++ The part specific for a trust message begins with the ]]> element. + Its encryption attribute MUST specify the encryption protocol that uses the keys denoted by their identifiers. + To send a trust message for keys of &xep0373; the attribute or for keys of &xep0384; the attribute MUST be used. + For other values there is an overview of possible &encryption-protocols;. + A trust message MUST contain at least one ]]> element and each element MUST contain at least one ]]> or ]]> element. + Inside of each ]]> or ]]> element there MUST be exactly one key identifier. + Those elements are used for the following purposes: +
++ In the following example the keys of the later given identifiers are used by the encryption protocol &xep0384; specified by eu.siacs.conversations.axolotl. +
++ In the following example the keys of the later given identifiers belong to alice@example.org. +
++ In the following example the key corresponding to the identifier inside ]]> and ]]> is trusted by the sending endpoint. +
++ In the following example the key corresponding to the identifier inside the ]]> and ]]> is not trusted by the sending endpoint. +
++ An endpoint of alice@example.org MAY send a trust message to other endpoints of alice@example.org, to contacts like bob@example.com or to a specific resource like carol@example.net/phone. +
++ The usage of &xep0280; for trust messages is RECOMMENDED. + It minimizes the number of trust messages to be sent while having the same payload because trust messages with the same payload do not have to be sent for each endpoint. + In combination with the usage of &xep0313;, the delivery of trust messages to temporarily offline endpoints is ensured even if they are available under a different resource after going online than the last known one before going offline. + Additionally, using &xep0280; for every encrypted trust message will lead to send trust messages which are less distinguishable by analyzing their content from other encrypted messages using &xep0420;. + However, it may be possible to distinguish an encrypted trust message from other encrypted messages and therefore detect the fact that a specific authentication took place by analyzing the network traffic over a period of time but that is out of scope for this specification. +
+TODO: Move this paragraph to &xep0420;. + The following message attribute and element are RECOMMENDED because without having ]]>, the goals of them would not be achieved. + is needed to deliver the trust message to all endpoints (see XEP-0280: Message Carbons). + ]]> is needed to deliver the trust message to each offline endpoint after it went online (see XEP-0313: Message Archive Management and XEP-0334: Message Processing Hints). +
++ In the following examples Alice's endpoint sends a trust message for &xep0384; (eu.siacs.conversations.axolotl) keys of own endpoints and Bob's endpoints to Carol's resource "phone". + Alice's keys corresponding to the identifiers starting with "68" and "22" are trusted by Alice's endpoint connected via resource "laptop". + Bob's key corresponding to the identifiers starting with "68" and "22" are trusted by Alice's endpoint connected via resource "laptop". + Bob's key corresponding to the identifier starting with "62" is trusted by Alice's endpoint connected via resource "laptop" but not Bob's keys corresponding to the identifiers starting with "b4" and "d9". +
++ A trust message before encryption or without any encryption could look like the following example. + Keep in mind, like said before, that the authenticity and integrity of the message MUST be ensured by a signing mechanism even if the message is not encrypted. + However, the strength of trust messages is the possibility to encrypt them and to choose its recipients. +
++ Like described in the introduction, it is possible to encrypt a trust message and send it only to endpoints whose keys have already been authenticated. + Both actions are RECOMMENDED, especially for concealing the fact that an endpoint authenticated another endpoint's key. + When using an end-to-end encryption like &xep0384; which cannot encrypt arbitrary elements, &xep0420; is needed to encrypt a trust message. + The following example shows how such a message could look like. + For encrypting with &xep0373;, the element ]]> MUST be replaced by ]]>, the element ]]> by ]]> and ...]]> MUST be removed. +
++ This specification uses &xep0280; for sending a trust message to all endpoints of a contact or to all own endpoints at once. + By sending a trust message to the contact, each endpoint of the contact and each own endpoint receives the same trust message by the server. + Thus, a client needs to send the same trust message only once. +
++ If not all endpoints of the contact should receive the trust message, the trust message MAY be sent to specific endpoints of the contact but for all own endpoints &xep0280; MAY be used and vice versa. + Even when a client does not yet have a contact, the client MAY use &xep0280; for delivering a trust message to all own endpoints by sending it to the own bare JID. + If then a client receives a trust message with its own full JID as the sender, it MAY discard that message directly without parsing the content. +
++ Example: + Alice's endpoint A1 authenticates the key of her endpoint A2. + A1 sends the trust message for A2's key only once to all of Alice's and Bob's endpoints by using &xep0280;. +
++ Attention: + In that context, sending an encrypted trust message to all endpoints of a contact or to all own endpoints does not mean to encrypt it with the keys of all those endpoints. + Instead, it only means that all of those endpoints should receive the trust message even if it is not encrypted for some of them and thereby not decryptable by those endpoints. + Keep in mind that a trust message SHOULD only be encrypted for endpoints with authenticated keys. +
+REQUIRED.
+REQUIRED.
+REQUIRED for protocol specifications.
+