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.