moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 08:45:04 -05:00
Code Issues Releases Wiki Activity

Merge branch 'premerge' into 'main'

Browse Source 
Premerge

See merge request xsf/xeps!39
This commit is contained in:
Jonas Schäfer 2020-12-01 17:18:53 +00:00
commit 07b3993048
6 changed files with 863 additions and 187 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

496
inbox/automatic-trust-management.xml Normal file
View File

@ -0,0 +1,496 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
<!ENTITY ns "urn:xmpp:atm:0">
<!ENTITY ns-trust-messages "urn:xmpp:trust-messages:0">
<!ENTITY ns-omemo "urn:xmpp:omemo:1">
<!ENTITY ns-sce "urn:xmpp:sce:0">
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Automatic Trust Management (ATM)</title>
<abstract>
This document specifies a way to automatically manage the trust in public long-term keys used by end-to-end encryption protocols.
</abstract>
&LEGALNOTICE;
<number>xxxx</number>
<status>ProtoXEP</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>XEP-0001</spec>
<spec>XEP-0280</spec>
<spec>XEP-0334</spec>
<spec>XEP-0420</spec>
<spec>XEP-0434</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>ATM</shortname>
<author>
<firstname>Melvin</firstname>
<surname>Keskin</surname>
<email>melvo@olomono.de</email>
<jid>melvo@olomono.de</jid>
</author>
<revision>
<version>0.0.1</version>
<date>2020-11-05</date>
<initials>melvo</initials>
<remark><p>First draft.</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='introduction'>
<p>
End-to-end encryption can easily be used to protect most of the communication nowadays.
However, the management of trust in long-term keys used for encryption is still a manual task.
With ATM, many steps that can be automated for the trust management are no longer a manual task the users have to take care of.
</p>
<p>
ATM reduces the steps needed for authenticating or distrusting keys of endpoints between two identities (XMPP accounts / bare JIDs).
It uses &xep0434; for automatically establishing secure channels protected against active attacks between a new endpoint and existing ones after an initial mutual authentication between the new endpoint and one of the existing ones.
</p>
<p>
Trust messages are sent encrypted only to endpoints with authenticated keys.
ATM preserves the security level as if all endpoints of the two identities authenticated or distrusted their keys manually.
It can be used especially for end-to-end encryption protocols such as &xep0384; which use one key per endpoint of the same identity.
</p>
</section1>
<section1 topic='Glossary' anchor='glossary'>
<dl>
<di>
<dt>External glossary</dt>
<dd>
The terms of &xep0434;'s glossary are also relevant for this XEP.
</dd>
</di>
<di>
<dt>Manual key authentication</dt>
<dd>Key authentication with user interaction (e.g., QR code scanning, fingerprint verification)</dd>
</di>
<di>
<dt>Automatic key authentication</dt>
<dd>Key authentication without user interaction (e.g., via ATM)</dd>
</di>
<di>
<dt>Initial key authentication</dt>
<dd>Key authentication needed for all further automatic key authentications made by ATM</dd>
</di>
<di>
<dt>Mutual key authentication</dt>
<dd>Key authentication in which two endpoints authenticate each other's key</dd>
</di>
<di>
<dt>Key distrusting</dt>
<dd>Revoking the trust in a key</dd>
</di>
<di>
<dt>Manual key distrusting</dt>
<dd>Key distrusting with user interaction (e.g., clicking a "Distrust" button)</dd>
</di>
<di>
<dt>Automatic key distrusting</dt>
<dd>Key distrusting without user interaction (e.g., via ATM)</dd>
</di>
<di>
<dt>Authentication message</dt>
<dd>
Trust message which only contains key identifiers for authentication.
If a trust message contains authentication and distrusting parts, the term authentication message is used for referring to the trust message without the distrusting parts.
</dd>
</di>
<di>
<dt>Distrust message</dt>
<dd>
Trust message which only contains key identifiers for distrusting.
If a trust message contains authentication and distrusting parts, the term distrust message is used for referring to the trust message without the authentication parts.
</dd>
</di>
</dl>
</section1>
<section1 topic='Details' anchor='details'>
<p>
The goal of key authentication is to create an end-to-end encrypted communication network exclusively of endpoints with authenticated keys.
As a result, every communication channel between those endpoints is resistant against active attacks.
</p>
<p>
The network of endpoints which authenticated each other's keys can be seen as a complete graph where each endpoint is a node and each mutual authentication is an edge.
The number of edges grows for each new endpoint by the number of existing nodes.
This is due to the fact that in order to sustain secure channels between all endpoints, a new key has to be authenticated by all n existing endpoints and vice versa.
</p>
<p>
One of those n mutual authentications requires a third party or user interaction like scanning each other's QR code or comparing each other's key identifier by hand.
That is the initial mutual authentication.
A trusted third party MAY be used for the initial authentication but a manual authentication SHOULD be preferred since it does not depend on the trust in the third party.
The remaining authentications can be automated relying on the secure channel established by the initial mutual authentication and the secure channels already created by the same procedure between the rest of the endpoints.
</p>
<p>
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 ATM, only T(n) = n-1 ∊ O(n) of them have to be made as initial mutual authentications.
All remaining authentications can be performed automatically by ATM.
Thus, less user interaction is needed for authenticating all keys involved in the secure communication while preserving the same security level as the manual authentication.
</p>
</section1>
<section1 topic='Use Cases' anchor='use-cases'>
<p>
Everything which is RECOMMENDED by &xep0434; MUST be applied.
</p>
<p>
The examples contain &xep0384; as the encryption protocol because it uses one key per endpoint of the same identity.
Nevertheless, other encryption protocols MAY be used as stated in &xep0434;.
</p>
<p>
If the encryption protocol used with ATM involves only one key for all endpoints of the same identity, only the use cases for authenticating and distrusting keys of a contact's endpoint are relevant.
Those use cases are marked with OOK for <em>only one key</em>.
Additionally, the trust messages are always sent to own endpoints because they use the same key as the sending endpoint.
Therefore, the parts <em>..., to each (other) own endpoint with an already authenticated key.</em> and <em>... as soon as X authenticated Y's key</em> are not of interest.
</p>
<p>
Note that the examples in the following use cases are consecutive and therefore must be read chronologically to properly understand them.
Since ATM uses &xep0420;, only the SCE <![CDATA[<content/>]]> elements are shown.
</p>
<p>
Alice would like to use OMEMO when communicating with Bob.
Alice has the endpoints A1, A2 and A3.
Bob has the endpoint B1.
A1 has already authenticated A2's key.
The other endpoints have not authenticated each other's key.
</p>
<section2 topic='Authenticating the Key of a Contact&apos;s Endpoint' anchor='use-case-authentication-contact-endpoint'>
<section3 topic='Sending' anchor='use-case-authentication-contact-endpoint-sending'>
<p>
Example:
Remember that A1 has already authenticated A2's key.
A1 authenticates B1's key.
</p>
<p>
An endpoint which initially authenticates the key of a contact's endpoint MUST send an authentication message for ...
</p>
<section4 topic='To Own Endpoints (OOK)' anchor='use-case-authentication-contact-endpoint-sending-to-own-endpoints'>
<p>
... the key that has been authenticated, to each own endpoint with an already authenticated key.
</p>
<example caption='A1 sends an authentication message for B1&apos;s key to A2'><![CDATA[
<content xmlns=']]>&ns-sce;<![CDATA['>
<rpad>QHqW2arWFewoERL1a43wonBKpTmsrBWnc1d66HSDq85NgMLmjrDJV9lV</rpad>
<time stamp='2020-01-01T12:00:00'/>
<from jid='alice@example.org/A1'/>
<to jid='alice@example.org'/>
<payload>
<trust-message xmlns=']]>&ns-trust-messages;<![CDATA[' usage=']]>&ns;<![CDATA[' encryption=']]>&ns-omemo;<![CDATA['>
<key-owner jid='bob@example.com'>
<trust>623548d3835c6d33ef5cb680f7944ef381cf712bf23a0119dabe5c4f252cd02f</trust>
</key-owner>
</trust-message>
</payload>
</content>
]]></example>
</section4>
<section4 topic='To Contact&apos;s Endpoint' anchor='use-case-authentication-contact-endpoint-sending-to-contact-endpoint'>
<p>
... each already authenticated key of all own endpoints, to the endpoint whose key has been authenticated.
</p>
<example caption='A1 sends an authentication message for A2&apos;s key to B1'><![CDATA[
<content xmlns=']]>&ns-sce;<![CDATA['>
<rpad>Wvj25aDkNbAnSxMIDQo1pjIKRowIMGrF72hSJeXS</rpad>
<time stamp='2020-01-01T12:00:01'/>
<from jid='alice@example.org/A1'/>
<to jid='bob@example.org'/>
<payload>
<trust-message xmlns=']]>&ns-trust-messages;<![CDATA[' usage=']]>&ns;<![CDATA[' encryption=']]>&ns-omemo;<![CDATA['>
<key-owner jid='alice@example.org'>
<trust>6850019d7ed0feb6d3823072498ceb4f616c6025586f8f666dc6b9c81ef7e0a4</trust>
</key-owner>
</trust-message>
</payload>
</content>
]]></example>
</section4>
</section3>
<section3 topic='Receiving' anchor='use-case-authentication-contact-endpoint-receiving'>
<p>
An endpoint which receives an authentication message for a key of a contact's endpoint from ...
</p>
<section4 topic='From Own Endpoint (OOK)' anchor='use-case-authentication-contact-endpoint-receiving-from-own-endpoint'>
<p>
... an own endpoint ...
</p>
<p>
Example:
A2 authenticates B1's key by the authentication message from A1 (see <link url='#example-1'>Example 1</link> for the corresponding authentication message) as soon as A2 authenticated A1's key.
</p>
</section4>
<section4 topic='From Contact&apos;s Endpoint' anchor='use-case-authentication-contact-endpoint-receiving-from-contact-endpoint'>
<p>
... or another endpoint of that contact ...
</p>
<p>
Example:
B1 authenticates A2's key by the authentication message from A1 (see <link url='#example-2'>Example 2</link> for the corresponding authentication message) as soon as B1 authenticated A1's key.
</p>
</section4>
<p>
... MUST authenticate the key as soon as the receiving endpoint authenticated the key of the endpoint which sent the authentication message.
</p>
</section3>
</section2>
<section2 topic='Authenticating the Key of an Own Endpoint' anchor='use-case-authentication-own-endpoint'>
<section3 topic='Sending' anchor='use-case-authentication-own-endpoint-sending'>
<p>
Example:
Remember that A2 has already authenticated A1's and B1's key.
A2 authenticates A3's key.
</p>
<p>
An endpoint which initially authenticates the key of an own endpoint MUST send an authentication message for ...
</p>
<section4 topic='To All Other Endpoints' anchor='use-case-authentication-own-endpoint-sending-to-other-endpoints'>
<p>
... the key that has been authenticated to each other endpoint with an already authenticated key.
</p>
<example caption='A2 sends an authentication message for A3&apos;s key to B1 and by using Message Carbons also to A1'><![CDATA[
<content xmlns=']]>&ns-sce;<![CDATA['>
<rpad>O2vRKkmtsXsKSk2hPDkrpQQ4Og272qFGB1Srp64vaDrMTNhrV6</rpad>
<time stamp='2020-01-01T14:00:01'/>
<from jid='alice@example.org/A2'/>
<to jid='bob@example.org'/>
<payload>
<trust-message xmlns=']]>&ns-trust-messages;<![CDATA[' usage=']]>&ns;<![CDATA[' encryption=']]>&ns-omemo;<![CDATA['>
<key-owner jid='alice@example.org'>
<trust>221a4f8e228b72182b006e5ca527d3bddccf8d9e6feaf4ce96e1c451e8648020</trust>
</key-owner>
</trust-message>
</payload>
</content>
]]></example>
<example caption='A2 would send an authentication message for A3&apos;s key only to A1 if there were no contacts with authenticated keys'><![CDATA[
<content xmlns=']]>&ns-sce;<![CDATA['>
<rpad>s5jP95kvpRNg92XLLo8OkLCvUDT53S</rpad>
<time stamp='2020-01-01T14:00:00'/>
<from jid='alice@example.org/A2'/>
<to jid='alice@example.org'/>
<payload>
<trust-message xmlns=']]>&ns-trust-messages;<![CDATA[' usage=']]>&ns;<![CDATA[' encryption=']]>&ns-omemo;<![CDATA['>
<key-owner jid='alice@example.org'>
<trust>221a4f8e228b72182b006e5ca527d3bddccf8d9e6feaf4ce96e1c451e8648020</trust>
</key-owner>
</trust-message>
</payload>
</content>
]]></example>
</section4>
<section4 topic='To Endpoint Whose Key Has Been Authenticated' anchor='use-case-authentication-own-endpoint-sending-to-endpoint-key-authenticated'>
<p>
... each already authenticated key of all endpoints to the endpoint whose key has been authenticated.
</p>
<example caption='A2 sends an authentication message for A1&apos;s and B1&apos;s key to A3'><![CDATA[
<content xmlns=']]>&ns-sce;<![CDATA['>
<rpad>98WA6U92twcVkAXM44UU</rpad>
<time stamp='2020-01-01T14:00:02'/>
<from jid='alice@example.org/A2'/>
<to jid='bob@example.org'/>
<payload>
<trust-message xmlns=']]>&ns-trust-messages;<![CDATA[' usage=']]>&ns;<![CDATA[' encryption=']]>&ns-omemo;<![CDATA['>
<key-owner jid='alice@example.org'>
<trust>f3cddd91f25502652483be2fd5faaaa00f80868ac0d51d7eebb1b08a3892e33d</trust>
</key-owner>
<key-owner jid='bob@example.com'>
<trust>623548d3835c6d33ef5cb680f7944ef381cf712bf23a0119dabe5c4f252cd02f</trust>
</key-owner>
</trust-message>
</payload>
</content>
]]></example>
</section4>
</section3>
<section3 topic='Receiving' anchor='use-case-authentication-own-endpoint-receiving'>
<p>
An endpoint which receives an authentication message for a key of an own endpoint from another own endpoint MUST authenticate the key as soon as the receiving endpoint authenticated the key of the endpoint which sent the authentication message.
</p>
<p>
Example:
A1 authenticates A3's key by the authentication message from A2 (see <link url='#example-3'>Example 3</link> or <link url='#example-4'>Example 4</link> for the corresponding authentication message) as soon as A1 authenticated A2's key.
</p>
</section3>
</section2>
<section2 topic='Distrusting the Key of an Own Endpoint' anchor='use-case-distrusting-own-endpoint'>
<section3 topic='Sending' anchor='use-case-distrusting-own-endpoint-sending'>
<p>
Example:
Remember that A1 has already authenticated A2's, A3's and B1's key.
A1 distrusts A3's key.
</p>
<p>
An endpoint which initially distrusts the key of an own endpoint MUST send a distrust message for that key to each other endpoint with an already authenticated key.
</p>
<example caption='A1 sends a distrust message for A3&apos;s key to B1 and by using Message Carbons also to A2'><![CDATA[
<content xmlns=']]>&ns-sce;<![CDATA['>
<rpad>NF5MOJdt8TBbItt4AHXOUKWncRmw5B</rpad>
<time stamp='2020-01-01T16:00:01'/>
<from jid='alice@example.org/A1'/>
<to jid='bob@example.org'/>
<payload>
<trust-message xmlns=']]>&ns-trust-messages;<![CDATA[' usage=']]>&ns;<![CDATA[' encryption=']]>&ns-omemo;<![CDATA['>
<key-owner jid='alice@example.org'>
<distrust>221a4f8e228b72182b006e5ca527d3bddccf8d9e6feaf4ce96e1c451e8648020</distrust>
</key-owner>
</trust-message>
</payload>
</content>
]]></example>
<example caption='A1 would send a distrust message for A3&apos;s key only to A2 if there were no contacts with authenticated keys'><![CDATA[
<content xmlns=']]>&ns-sce;<![CDATA['>
<rpad>798BFSTQqPjVtiLok3EGtQ7VgB3GGP7eT9P4FhO5</rpad>
<time stamp='2020-01-01T16:00:00'/>
<from jid='alice@example.org/A1'/>
<to jid='alice@example.org'/>
<payload>
<trust-message xmlns=']]>&ns-trust-messages;<![CDATA[' usage=']]>&ns;<![CDATA[' encryption=']]>&ns-omemo;<![CDATA['>
<key-owner jid='alice@example.org'>
<distrust>221a4f8e228b72182b006e5ca527d3bddccf8d9e6feaf4ce96e1c451e8648020</distrust>
</key-owner>
</trust-message>
</payload>
</content>
]]></example>
</section3>
<section3 topic='Receiving' anchor='use-case-distrusting-own-endpoint-receiving'>
<p>
An endpoint which receives a distrust message for a key of an own endpoint from another own endpoint MUST distrust the key as soon as the receiving endpoint authenticated the key of the endpoint which sent the distrust message.
</p>
<p>
Example:
A2 distrusts A3's key by the distrust message from A1 (see <link url='#example-6'>Example 6</link> or <link url='#example-7'>Example 7</link> for the corresponding distrust message) as soon as A2 authenticated A1's key.
</p>
</section3>
</section2>
<section2 topic='Distrusting the Key of a Contact&apos;s Endpoint' anchor='use-case-distrusting-contact-endpoint'>
<section3 topic='Sending (OOK)' anchor='use-case-distrusting-contact-endpoint-sending'>
<p>
Example:
Remember that A1 has already authenticated A2's and B1's key but distrusted A3's key.
A1 distrusts B1's key.
</p>
<p>
An endpoint which distrusts the key of a contact's endpoint MUST send a distrust message for that key to each other own endpoint with an authenticated key.
</p>
<example caption='A1 sends a distrust message for B1&apos;s key to A2'><![CDATA[
<content xmlns=']]>&ns-sce;<![CDATA['>
<rpad>x4LJDawLHgnTJRC7T1mndKEQLPR658NQmXAPQRVnhM1QQ861ve</rpad>
<time stamp='2020-01-01T18:00:00'/>
<from jid='alice@example.org/A1'/>
<to jid='alice@example.org'/>
<payload>
<trust-message xmlns=']]>&ns-trust-messages;<![CDATA[' usage=']]>&ns;<![CDATA[' encryption=']]>&ns-omemo;<![CDATA['>
<key-owner jid='bob@example.com'>
<distrust>623548d3835c6d33ef5cb680f7944ef381cf712bf23a0119dabe5c4f252cd02f</distrust>
</key-owner>
</trust-message>
</payload>
</content>
]]></example>
</section3>
<section3 topic='Receiving' anchor='use-case-distrusting-contact-endpoint-receiving'>
<p>
An endpoint which receives a distrust message for a key of a contact's endpoint from ...
</p>
<section4 topic='From Contact&apos;s Endpoint' anchor='use-case-distrusting-contact-endpoint-receiving-from-contact-endpoint'>
<p>
... another endpoint of that contact ...
</p>
<p>
Example:
B1 distrusts A3's key by the distrust message from A1 (see <link url='#example-6'>Example 6</link> for the corresponding distrust message) as soon as B1 authenticated A1's key.
</p>
</section4>
<section4 topic='From Own Endpoint (OOK)' anchor='use-case-distrusting-contact-endpoint-receiving-from-own-endpoint'>
<p>
... or an own endpoint ...
</p>
<p>
Example:
A2 distrusts B1's key by the distrust message from A1 (see <link url='#example-8'>Example 8</link>) as soon as A2 authenticated A1's key.
</p>
</section4>
<p>
... MUST distrust the key as soon as the receiving endpoint authenticated the key of the endpoint which sent the distrust message.
</p>
</section3>
</section2>
</section1>
<section1 topic='Implementation Notes' anchor='implementation-notes'>
<section2 topic='Storing Trust Message Information from Endpoints with Unauthenticated Keys' anchor='implementation-notes-storing-trust-message-information-unauthenticated-keys'>
<p>
A client MUST save the information of a trust message until the key of the endpoint which sent the trust message is authenticated, so that the key can then be authenticated or revoked.
Storing data of a trust message from an endpoint with an unauthenticated key is necessary because the receiving endpoint can only use that data after authenticating the sending endpoint's key and that data might not be received again.
Afterwards the information of the trust message MAY be deleted.
</p>
<p>
Example:
When Alice's endpoint A1 authenticates the key of Bob's endpoint B1, A1 sends a trust message containing the keys of Alice's other endpoint 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.
</p>
</section2>
<section2 topic='Storing Trust Message Information for Unknown Keys' anchor='implementation-notes-storing-trust-message-information-unknown-keys'>
<p>
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.
</p>
<p>
Example:
Alice's endpoint A1 receives an authentication message from Bob's endpoint B1.
That authentication message contains the key for Bob's other endpoint 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.
</p>
</section2>
<section2 topic='GUI Considerations' anchor='implementation-notes-gui-considerations'>
<p>
A client that receives a trust message SHOULD NOT display its bare content to the user.
Instead, the trust message SHOULD be hidden and the automatic authentication or distrusting SHOULD take place in the background.
</p>
</section2>
</section1>
<section1 topic='Security Considerations' anchor='security-considerations'>
<section2 topic='Notification and Confirmation' anchor='security-considerations-notification-and-confirmation'>
<p>
After a successful authentication or distrusting, 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 distrusting is performed.
</p>
</section2>
<section2 topic='Recommended Security Policy - Trust Only Authenticated Keys After First Authentication (TOAKAFA)' anchor='security-considerations-recommended-security-policy-trust-only-authenticated-keys-after-first-authentication-toakafa'>
<p>
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 endpoint, it is RECOMMENDED to automatically trust new keys until the first authentication has been made.
</p>
<p>
Even ATM cannot protect the user against an attacker with an automatically trusted and undetected malicious key.
For this reason it is important to take special care of the following security aspects.
</p>
<p>
If keys are automatically trusted until the first authentication, keys which are not authenticated by then SHOULD NOT be used any longer for encryption until they have been authenticated too.
New keys SHOULD 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.
</p>
</section2>
</section1>
<section1 topic='IANA Considerations' anchor='iana-considerations'>
<p>This document requires no interaction with the Internet Assigned Numbers Authority (IANA).</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='xmpp-registrar-considerations'>
<section2 topic='Protocol Namespaces' anchor='xmpp-registrar-considerations-protocol-namespaces'>
<p>This specification defines the following XMPP namespaces:</p>
<ul>
<li>&ns;</li>
</ul>
</section2>
<section2 topic='Protocol Versioning' anchor='xmpp-registrar-considerations-protocol-versioning'>
&NSVER;
</section2>
</section1>
</xep>

8
xep-0369.xml
View File

@ -35,6 +35,12 @@
<shortname>MIX-CORE</shortname>
&ksmithisode;
&skille;
<revision>
<version>0.14.6</version>
<date>2020-12-01</date>
<initials>gh/@mathieui</initials>
<remark><p>Fix minor typo</p></remark>
</revision>
<revision>
<version>0.14.5</version>
<date>2020-11-03</date>
@ -537,7 +543,7 @@
</section1>
<section1 topic='Concepts' anchor='concepts'>
<section2 topic="Comparsion to MUC" anchor="concepts-muc-comparison">
<section2 topic="Comparison to MUC" anchor="concepts-muc-comparison">
<p>
This section is written as an introduction to MIX for those with detailed knowledge of &xep0045;, to summarize key differences and some rationale for the differences. For those unfamiliar with MUC, this section should be ignored.
</p>

14
xep-0403.xml
View File

@ -38,6 +38,12 @@
<shortname>MIX-PRESENCE</shortname>
&ksmithisode;
&skille;
<revision>
<version>0.3.2</version>
<date>2020-12-01</date>
<initials>gh/@mathieui</initials>
<remark>Fix incorrect namespaces</remark>
</revision>
<revision>
<version>0.3.1</version>
<date>2018-11-03</date>
@ -200,7 +206,7 @@
<items node='urn:xmpp:mix:nodes:presence'>
<item id='123456#coven@mix.shakespeare.example/UUID-x4r/2491'>
<presence xmlns='jabber:client'>
<mix xmlns='urn:xmpp:presence:0'>
<mix xmlns='urn:xmpp:mix:presence:0'>
<jid>hecate@shakespeare.example/UUID-x4r/2491</jid>
<nick>thirdwitch</jid>
</mix>
@ -265,7 +271,7 @@ A user MAY share presence information with the channel, for one or more online c
<![CDATA[<presence from='123435#coven@mix.shakespeare.example/UUID-a1j/7533'
to='hag99@shakespeare.example'
id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'>
<mix xmlns='urn:xmpp:presence:0'>
<mix xmlns='urn:xmpp:mix:presence:0'>
<jid>hecate@shakespeare.example/UUID-x4r/2491</jid>
<nick>thirdwitch</jid>
</mix>
@ -313,7 +319,7 @@ A user MAY share presence information with the channel, for one or more online c
to='hecate@shakespeare.example'
id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'
type='unavailable'>
<mix xmlns='urn:xmpp:presence:0'>
<mix xmlns='urn:xmpp:mix:presence:0'>
<jid>hecate@shakespeare.example/UUID-x4r/2491</jid>
<nick>thirdwitch</jid>
</mix>
@ -337,7 +343,7 @@ A user MAY share presence information with the channel, for one or more online c
to='hecate@shakespeare.example'
id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'
type='unavailable'>
<mix xmlns='urn:xmpp:presence:0'>
<mix xmlns='urn:xmpp:mix:presence:0'>
<jid>hecate@shakespeare.example/UUID-x4r/2491</jid>
<nick>thirdwitch</jid>
</mix>

85
xep-0404.xml
View File

@ -37,6 +37,12 @@
<shortname>MIX-ANON</shortname>
&ksmithisode;
&skille;
<revision>
<version>0.3.1</version>
<date>2020-12-01</date>
<initials>gh/@mathieui</initials>
<remark>Various XML example cleanup and fixes</remark>
</revision>
<revision>
<version>0.3.0</version>
<date>2018-06-06</date>
@ -278,21 +284,23 @@ This change means that the client will not be able to determine real JID of the
from='coven@mix.shakespeare.example'
to='hag66@shakespeare.example/UUID-a1j/7533'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<user-preference xmlns='urn:xmpp:mix:anon:0'>
<user-preference xmlns='urn:xmpp:mix:anon:0'>
<x xmlns='jabber:x:data' type='form'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:mix:anon:0</value>
</field>
<field type='list-single' label='Preference for JID Visibility
var='JID Visibility'>
</field>
<field type='list-single' label='Preference for JID Visibility
var='JID Visibility'>
<option label='JID Never Shown'><value>Never</value></option>
<option label='Default Behaviour'
<value>default</value></option>
<option label='Try not to show JID'>
<value>prefer not</value></option>
</field>
<field type='list-single' label='Example Custom Preference'
var='Custom Preference'>
<option label='Default Behaviour'>
<value>default</value>
</option>
<option label='Try not to show JID'>
<value>prefer not</value>
</option>
</field>
<field type='list-single' label='Example Custom Preference'
var='Custom Preference'>
<option label='One Option'><value>a</value></option>
<option label='Another Option'><value>b</value></option>
</field>
@ -308,41 +316,42 @@ This change means that the client will not be able to determine real JID of the
from='hag66@shakespeare.example/UUID-a1j/7533'
to='coven@mix.shakespeare.example'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<user-preference xmlns='urn:xmpp:mix:anon:0'/>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:mix:anon:0</value>
</field>
<field var='JID Visibility'>
<value>never</value>
</field>
<field var='Private Messages'>
<value>allow</value>
</field>
<field var='vCard'>
<value>block</value>
</field>
<user-preference xmlns='urn:xmpp:mix:anon:0'>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:mix:anon:0</value>
</field>
<field var='JID Visibility'>
<value>never</value>
</field>
<field var='Private Messages'>
<value>allow</value>
</field>
<field var='vCard'>
<value>block</value>
</field>
</x>
</user-preference>
</iq>
<iq type='result'
from='coven@mix.shakespeare.example'
to='hag66@shakespeare.example/UUID-a1j/7533'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<user-preference xmlns='urn:xmpp:mix:anon:0'>
<user-preference xmlns='urn:xmpp:mix:anon:0'>
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:mix:anon:0</value>
</field>
<field var='JID Visibility'>
<value>never</value>
</field>
<field var='Private Messages'>
<value>allow</value>
</field>
<field var='vCard'>
<value>block</value>
</field>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:mix:anon:0</value>
</field>
<field var='JID Visibility'>
<value>never</value>
</field>
<field var='Private Messages'>
<value>allow</value>
</field>
<field var='vCard'>
<value>block</value>
</field>
</x>
</user-preference>
</iq>

10
xep-0408.xml
View File

@ -35,6 +35,12 @@
<shortname>MIX-MUC</shortname>
&ksmithisode;
&skille;
<revision>
<version>0.1.1</version>
<date>2020-12-01</date>
<initials>gh/@mathieui</initials>
<remark>Fix minor XML formatting issues</remark>
</revision>
<revision>
<version>0.1.0</version>
<date>2018-05-21</date>
@ -87,7 +93,7 @@
type='text'/>
<feature var='urn:xmpp:mix:core:0'/>
<feature var='http://jabber.org/protocol/muc'/>
<feature var='urn:xmpp:mix:core:0#searchable'>
<feature var='urn:xmpp:mix:core:0#searchable'/>
</query>
</iq>
]]></example>
@ -103,7 +109,7 @@
id='lx09df27'
to='mix.shakespeare.example'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
<iq from='mix.shakespeare.example'

437
xep-0434.xml
View File

@ -1,13 +1,16 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
<!ENTITY encryption-protocols "<span class='ref'><link url='https://xmpp.org/extensions/xep-0380.html#table-1'>encryption protocols</link></span><note>Explicit Message Encryption - Encryption Protocols &lt;<link url='https://xmpp.org/extensions/xep-0380.html#table-1'>https://xmpp.org/extensions/xep-0380.html#table-1</link>&gt;.</note>">
<!ENTITY ns "urn:xmpp:trust-messages:0">
<!ENTITY ns-example-usage "urn:xmpp:example-usage:0">
<!ENTITY ns-omemo "urn:xmpp:omemo:1">
<!ENTITY ns-sce "urn:xmpp:sce:0">
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Trust Messages</title>
<title>Trust Messages (TM)</title>
<abstract>
This document specifies a way to communicate the trust in public long-term keys used by end-to-end encryption protocols from one endpoint to another.
</abstract>
@ -26,48 +29,58 @@
</dependencies>
<supersedes/>
<supersededby/>
<shortname>NOT_YET_ASSIGNED</shortname>
<shortname>TM</shortname>
<author>
<firstname>Melvin</firstname>
<surname>Keskin</surname>
<email>melvo@olomono.de</email>
<jid>melvo@olomono.de</jid>
</author>
<revision>
<version>0.1.0</version>
<date>2020-02-27</date>
<initials>XEP Editor (jsc)</initials>
<remark>Accepted by vote of Council on 2020-02-19.</remark>
</revision>
<revision>
<revision>
<version>0.2.0</version>
<date>2020-11-05</date>
<initials>melvo</initials>
<remark>
<p>Improve explanations, descriptions and examples, introduce new attribute and complete all sections:</p>
<ul>
<li>Remove link to encryption protocol namespaces.</li>
<li>Add short name</li>
<li>Shorten and improve introduction.</li>
<li>Use emphasizing text formatting instead of quotation marks.</li>
<li>Add new section for explaining the core properties of trust messages.</li>
<li>Add examples comparing trust messages to public key certificates.</li>
<li>Improve description of trust message structure.</li>
<li>Introduce 'usage' attribute for 'trust-message' element.</li>
<li>Focus on &xep0420; and adjust examples accordingly.</li>
<li>Complete sections 'IANA Considerations', 'XMPP Registrar Considerations' and 'XML Schema'.</li>
</ul>
</remark>
</revision>
<revision>
<version>0.1.0</version>
<date>2020-02-27</date>
<initials>XEP Editor (jsc)</initials>
<remark>Accepted by vote of Council on 2020-02-19.</remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2020-02-15</date>
<initials>mk</initials>
<initials>melvo</initials>
<remark><p>First draft.</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<section1 topic='Introduction' anchor='introduction'>
<p>
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.
However, without any other precautions, active attacks are still possible.
If an attacker replaces the exchanged keys with malicious ones or introduces an additional malicious endpoint, the end-to-end encrypted messages can be read and manipulated by the attacker.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
Such a key has to be authenticated by the receiving endpoint over another channel which is already protected against active attacks to maintain the confidentiality of sent messages and ensure the authenticity and integrity of received messages.
Trust messages can be used to transfer the needed data via XMPP for performing such an authentication.
Furthermore, they can transmit the data used for distrusting a key.
</p>
</section1>
<section1 topic='Glossary' anchor='glossary'>
@ -77,142 +90,247 @@
<dd>
Communication endpoint owning exactly one public long-term key.
In most cases that is an XMPP client instance.
In the terminology of &xep0384;, that is a "device".
To cover also the possibility for using multiple endpoints on the same physical device and via the same client instance, the general term "endpoint" is used.
In the terminology of &xep0384;, that is a <em>device</em>.
To cover also the possibility for using multiple endpoints on the same physical device and via the same client instance, the general term <em>endpoint</em> is used.
</dd>
</di>
<di>
<dt>Key authentication</dt>
<dd>Verification that a key received over an insecure channel is actually the one of the assumed endpoint</dd>
<dd>
Verification that a key received over an insecure channel is actually the one of the assumed endpoint
</dd>
</di>
<di>
<dt>Key identifier</dt>
<dd>Identifier of a key (e.g., a fingerprint or the key itself)</dd>
<dd>
Identifier of a key (e.g., a fingerprint or the key itself)
</dd>
</di>
<di>
<dt>Public key certificate</dt>
<dd>
Electronic document used to prove the authenticity of a public key
</dd>
</di>
<di>
<dt>Trust message</dt>
<dd>
XMPP message which indicates that specific keys are trusted or not trusted by the sender.
XMPP message which indicates that specific keys are trusted or untrusted by the sending endpoint.
A trust message for an endpoint's key contains the key identifier of the given key.
</dd>
</di>
</dl>
</section1>
<section1 topic='Why Trust Messages?' anchor='why-trust-messages'>
<p>
Trust messages can be used in conjunction with an end-to-end encryption protocol such as &xep0373; or &xep0384; to automatically or semi-automatically establish secure channels protected against active attacks.
</p>
<section2 topic='General Advantages' anchor='why-trust-messages-general-advantages'>
<p>
Trust messages have the following advantages:
</p>
<section3 topic='No Permanent Storage' anchor='why-trust-messages-general-advantages-no-permanent-storage'>
<p>
A permanent storage is not needed.
Cached data can be be removed as soon as the recipient made use of them.
E.g., a server-side storage holding available data because it does not know when a client needs to access them, as for certificate-based approaches, is unnecessary.
</p>
</section3>
<section3 topic='No Additional Infrastructure' anchor='why-trust-messages-general-advantages-no-additional-infrastructure'>
<p>
An infrastructure in additional to the one used for messages is not needed because trust messages are ordinary messages.
E.g., a server-side storage and a mechanism for accessing it other than those used for messages is unnecessary.
</p>
</section3>
</section2>
<section2 topic='Advantages with Encryption' anchor='why-trust-messages-advantages-with-encryption'>
<p>
The authenticity and integrity of trust messages are ensured by a signing mechanism.
If trust messages are additionally encrypted, they have the following advantages:
</p>
<section3 topic='Same Cryptographic Properties' anchor='why-trust-messages-advantages-with-encryption-same-cryptographic-properties'>
<p>
The cryptographic properties of the encryption protocol are applied to the trust messages.
Properties such as confidentiality, forward secrecy and deniability can have a positive impact on the authentication of keys.
Hence, trust messages, in contrast to certificates, can e.g. be deniable toward a third party if the encryption protocol provides that kind of deniability.
</p>
</section3>
<section3 topic='Confidential Communication of Trust' anchor='why-trust-messages-advantages-with-encryption-confidential-communication-of-trust'>
<p>
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.
This means that an attacker cannot detect by the content of a trust message whether a specific key is trusted by the sender.
If the trust message is sent for an authentication of a key, the involved parties of that authentication will therefore stay anonymous toward an attacker.
</p>
<p>
The encryption protects against passive attacks on the transmission of the trust messages.
That way, an attacker cannot read the content of the trust messages.
</p>
<p>
The restriction to send trust messages only to endpoints with authenticated keys in addition to the encryption protects against active attacks on the transmission of the trust messages.
An attacker will even after introducing a malicious key not receive a trust message encrypted with that key.
</p>
</section3>
<section3 topic='No Selective Blocking' anchor='why-trust-messages-advantages-with-encryption-no-selective-blocking'>
<p>
Blocking data used to trust or distrust keys in transit is made more difficult.
In particular, an attacker is not able to selectively block transmitted data used to distrust the attacker's key.
</p>
<p>
If an attacker cannot distinguish whether the data sent from a client is used for trusting or distrusting a key, the attacker can only randomly block some messages or the whole communication.
If the communication is already compromised by an active attack, the attacker does not want to stop the whole communication.
During that state, the attacker has the possibility to keep on e.g. eavesdropping or altering messages.
Therefore, the attacker wants to block data which can lead to excluding the attacker.
But the attacker does not want to block the communication itself.
</p>
<p>
Data which is used by the recipient to distrust the attacker's key would make it impossible for the attacker to continue to encroach on the communication.
Thus, it is important to prevent an attacker from blocking data used for making trust decisions.
E.g., an approach using certificates permanently stored on a server cannot prevent an attacker from specifically blocking such data because certificates have to be discoverable and identifiable as such.
</p>
<p>
It might be possible to distinguish an encrypted trust message from other encrypted messages by analyzing the network traffic over a period of time.
However, the mitigation of that issue is out of scope.
</p>
</section3>
</section2>
</section1>
<section1 topic='Trust Message Structure' anchor='trust-message-structure'>
<p>
A trust message MUST be signed in a way to ensure its authenticity and integrity.
A trust message (i.e., the root <![CDATA[<message/>]]> element)
</p>
<ul>
<li>
MUST contain exactly one <![CDATA[<trust-message/>]]> direct child element which
<ul>
<li>
MUST be signed in a way to ensure its authenticity and integrity.
</li>
<li>
SHOULD be encrypted to ensure its confidentiality.
</li>
<li>
MUST have an <em>xmlns</em> attribute specifying its namespace <em>&ns;</em>.
</li>
<li>
MUST have a <em>usage</em> attribute specifying the namespace of the protocol which uses the trust message for a specific purpose.
</li>
<li>
MUST have an <em>encryption</em> attribute specifying the namespace of the encryption protocol for which the keys are used.
</li>
<li>
MUST contain at least one <![CDATA[<key-owner/>]]> direct child element which
<ul>
<li>
MUST have a <em>JID</em> attribute specifying the owner of the keys.
</li>
<li>
MUST contain at least one <![CDATA[<trust/>]]> or <![CDATA[<distrust/>]]> direct child element which indicates the trust respectively distrust in a key.
Each <![CDATA[<trust/>]]> and <![CDATA[<distrust/>]]> element MUST contain exactly one key identifier.
</li>
</ul>
</li>
</ul>
</li>
<li>
SHOULD have a <![CDATA[type='chat']]> attribute which is needed to deliver the trust message to all endpoints (see <link url='https://xmpp.org/extensions/xep-0280.html#recommended-rules'>XEP-0280: Message Carbons</link>).
</li>
<li>
SHOULD contain a <![CDATA[<store xmlns='urn:xmpp:hints'/>]]> direct child element which is needed to deliver the trust message to each offline endpoint after it went online (see <link url='https://xmpp.org/extensions/xep-0313.html#business-storeret-user-archives'>XEP-0313: Message Archive Management</link> and <link url='https://xmpp.org/extensions/xep-0334.html#sect-idm45856619663120'>XEP-0334: Message Processing Hints</link>).
</li>
</ul>
<p>
The last two points are needed to achieve their mentioned goals because a trust message does not contain a <![CDATA[<body>]]> element which would automatically lead to the desired result.
</p>
<p>
The part specific for a trust message begins with the <![CDATA[<trust-message>]]> 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 <![CDATA[encryption='urn:xmpp:openpgp:0']]> or for keys of &xep0384; the attribute <![CDATA[encryption='eu.siacs.conversations.axolotl']]> MUST be used.
For other values there is an overview of possible &encryption-protocols;.
A trust message MUST contain at least one <![CDATA[<key-owner>]]> element and each element MUST contain at least one <![CDATA[<trust>]]> or <![CDATA[<distrust>]]> element.
Inside of each <![CDATA[<trust>]]> or <![CDATA[<distrust>]]> element there MUST be exactly one key identifier.
Those elements are used for the following purposes:
In the following example, two &xep0384; keys of Alice are indicated as trusted, one key of Bob is indicated as trusted and two other ones of Bob are indicated as untrusted.
</p>
<p>
In the following example the keys of the later given identifiers are used by the encryption protocol &xep0384; specified by eu.siacs.conversations.axolotl.
</p>
<example caption='Specifying the Encryption Protocol of the Keys'><![CDATA[<trust-message xmlns='urn:xmpp:trust-messages:0' encryption='eu.siacs.conversations.axolotl'>]]></example>
<p>
In the following example the keys of the later given identifiers belong to alice@example.org.
</p>
<example caption='Specifying the JID Owning the Keys'><![CDATA[<key-owner jid='alice@example.org'>]]></example>
<p>
In the following example the key corresponding to the identifier inside <![CDATA[<trust>]]> and <![CDATA[</trust>]]> is trusted by the sending endpoint.
</p>
<example caption='Indicating the Trust in a Specific Key'><![CDATA[<trust>6850019d7ed0feb6d3823072498ceb4f616c6025586f8f666dc6b9c81ef7e0a4</trust>]]></example>
<p>
In the following example the key corresponding to the identifier inside the <![CDATA[<distrust>]]> and <![CDATA[</distrust>]]> is not trusted by the sending endpoint.
</p>
<example caption='Indicating the Distrust in a Specific Key'><![CDATA[<distrust>b423f5088de9a924d51b31581723d850c7cc67d0a4fe6b267c3d301ff56d2413</distrust>]]></example>
<example caption='Trust Message Element for Alice&apos;s and Bob&apos;s OMEMO Keys'><![CDATA[
<trust-message xmlns=']]>&ns;<![CDATA[' usage=']]>&ns-example-usage;<![CDATA[' encryption=']]>&ns-omemo;<![CDATA['>
<key-owner jid='alice@example.org'>
<trust>6850019d7ed0feb6d3823072498ceb4f616c6025586f8f666dc6b9c81ef7e0a4</trust>
<trust>221a4f8e228b72182b006e5ca527d3bddccf8d9e6feaf4ce96e1c451e8648020</trust>
</key-owner>
<key-owner jid='bob@example.com'>
<trust>623548d3835c6d33ef5cb680f7944ef381cf712bf23a0119dabe5c4f252cd02f</trust>
<distrust>b423f5088de9a924d51b31581723d850c7cc67d0a4fe6b267c3d301ff56d2413</distrust>
<distrust>d9f849b6b828309c5f2c8df4f38fd891887da5aaa24a22c50d52f69b4a80817e</distrust>
</key-owner>
</trust-message>
]]></example>
</section1>
<section1 topic='Use Cases' anchor='usecases'>
<section1 topic='Use Cases' anchor='use-cases'>
<p>
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.
Trust messages MAY be sent unencrypted to solely communicate the trust in specific keys without any other protection.
But as described before, the strength of trust messages is the possibility to encrypt their content and choose to which endpoints they are sent according to the trust in the endpoints' keys.
</p>
<section2 topic='Unencrypted Trust Message' anchor='use-cases-unencrypted-trust-message'>
<p>
The <![CDATA[<trust-message/>]]> element MUST be signed before sending for ensuring the authenticity and integrity.
</p>
</section2>
<section2 topic='Encrypted Trust Message' anchor='use-cases-encrypted-trust-message'>
<p>
The <![CDATA[<trust-message/>]]> element SHOULD be signed and encrypted before sending for applying all advantages the encryption provides.
That protects against passive attacks on the transmission of the trust message.
The trust message SHOULD only be sent to endpoints whose keys have already been authenticated for also preventing active attacks on the transmission of the trust message.
</p>
<p>
Describing how the <![CDATA[<trust-message/>]]> element has to be used by each existing encryption protocol is out of scope.
&xep0420; specifies a common method for encrypting arbitrary elements which can be used by different encryption protocols.
When using an encryption protocol such as &xep0384; which uses &xep0420; (SCE), the SCE <![CDATA[<payload/>]]> element MUST contain the <![CDATA[<trust-message/>]]> element as a direct child.
</p>
<section3 topic='SCE Profile' anchor='use-cases-encrypted-trust-message-sce-profile'>
<p>
A trust message SCE <![CDATA[<content/>]]> element
</p>
<ul>
<li>
MUST contain an <![CDATA[<rpad/>]]> affix element.
This prevents an attacker from finding out the trust message's content by its length and distinguishing a trust message from another kind of SCE message.
</li>
<li>
MUST contain a <![CDATA[<time/>]]> affix element.
This prevents an attacker from delivering trust messages in the wrong order or delivering a former trust message again.
If the trust messages are used by the recipient for making trust decisions, it protects the recipient from setting the opposite of the intended trust state by applying trust changes in the wrong order or reapplying a former change.
</li>
<li>
SHOULD contain a <![CDATA[<from/>]]> affix element.
This prevents an attacker from spoofing the sender.
</li>
<li>
SHOULD contain a <![CDATA[<to/>]]> affix element.
This prevents an attacker from spoofing the recipient.
</li>
</ul>
</section3>
<example caption='SCE Content Element Used for a Trust Message from Alice&apos;s Endpoint to Carol'><![CDATA[
<content xmlns=']]>&ns-sce;<![CDATA['>
<rpad>QHqW2arWFewoERL1a43wonBKpTmsrBWnc1d66HSDq85NgMLmjrDJV9lV</rpad>
<time stamp='2020-01-01T00:00:00'/>
<from jid='alice@example.org/notebook'/>
<to jid='carol@example.com'/>
<payload>
<trust-message xmlns=']]>&ns;<![CDATA[' usage=']]>&ns-example-usage;<![CDATA[' encryption=']]>&ns-omemo;<![CDATA['>
<key-owner jid='alice@example.org'>
<trust>6850019d7ed0feb6d3823072498ceb4f616c6025586f8f666dc6b9c81ef7e0a4</trust>
<trust>221a4f8e228b72182b006e5ca527d3bddccf8d9e6feaf4ce96e1c451e8648020</trust>
</key-owner>
<key-owner jid='bob@example.com'>
<trust>623548d3835c6d33ef5cb680f7944ef381cf712bf23a0119dabe5c4f252cd02f</trust>
<distrust>b423f5088de9a924d51b31581723d850c7cc67d0a4fe6b267c3d301ff56d2413</distrust>
<distrust>d9f849b6b828309c5f2c8df4f38fd891887da5aaa24a22c50d52f69b4a80817e</distrust>
</key-owner>
</trust-message>
</payload>
</content>
]]></example>
</section2>
</section1>
<section1 topic='Implementation Notes' anchor='implementation-notes'>
<p>
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.
&xep0280; 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.
</p>
<p> TODO: Move this paragraph to &xep0420;.
The following message attribute and element are RECOMMENDED because without having <![CDATA[<body>]]>, the goals of them would not be achieved.
<![CDATA[type='chat']]> is needed to deliver the trust message to all endpoints (see <link url='https://xmpp.org/extensions/xep-0280.html#recommended-rules'>XEP-0280: Message Carbons</link>).
<![CDATA[<store xmlns='urn:xmpp:hints'/>]]> is needed to deliver the trust message to each offline endpoint after it went online (see <link url='https://xmpp.org/extensions/xep-0313.html#business-storeret-user-archives'>XEP-0313: Message Archive Management</link> and <link url='https://xmpp.org/extensions/xep-0334.html#sect-idm45856619663120'>XEP-0334: Message Processing Hints</link>).
</p>
<p>
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".
</p>
<section2 topic='Unencrypted Trust Message' anchor='usecase-unencrypted-trust-message'>
<p>
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.
</p>
<example caption='Alice&apos;s endpoint sends an unencrypted trust message to Carol'><![CDATA[
<message from='alice@example.org/laptop' to='carol@example.org' type='chat'>
<store xmlns='urn:xmpp:hints'/>
<trust-message xmlns='urn:xmpp:trust-messages:0' encryption='eu.siacs.conversations.axolotl'>
<key-owner jid='alice@example.org'>
<trust>6850019d7ed0feb6d3823072498ceb4f616c6025586f8f666dc6b9c81ef7e0a4</trust>
<trust>221a4f8e228b72182b006e5ca527d3bddccf8d9e6feaf4ce96e1c451e8648020</trust>
</key-owner>
<key-owner jid='bob@example.com'>
<trust>623548d3835c6d33ef5cb680f7944ef381cf712bf23a0119dabe5c4f252cd02f</trust>
<distrust>b423f5088de9a924d51b31581723d850c7cc67d0a4fe6b267c3d301ff56d2413</distrust>
<distrust>d9f849b6b828309c5f2c8df4f38fd891887da5aaa24a22c50d52f69b4a80817e</distrust>
</key-owner>
</trust-message>
</message>
]]></example>
</section2>
<section2 topic='Encrypted Trust Message' anchor='usecase-encrypted-trust-message'>
<p>
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 <![CDATA[<encrypted xmlns='eu.siacs.conversations.axolotl'>]]> MUST be replaced by <![CDATA[<openpgp xmlns='urn:xmpp:openpgp:0'>]]>, the element <![CDATA[<envelope xmlns='urn:xmpp:sce:0'>]]> by <![CDATA[<signcrypt xmlns='urn:xmpp:openpgp:0'>]]> and <![CDATA[<header sid='27183'>...</header>]]> MUST be removed.
</p>
<example caption='Alice&apos;s endpoint sends an encrypted trust message to Carol'><![CDATA[
<message from='alice@example.org/laptop' to='carol@example.org' type='chat'>
<store xmlns='urn:xmpp:hints'/>
<encrypted xmlns='eu.siacs.conversations.axolotl'>
<header sid='17183'>
...
</header>
<envelope xmlns='urn:xmpp:sce:0'>
<rpad>QHqW2arWFewoERL1a43wonBKpTmsrBWnc1d66HSDq85NgMLmjrDJV9lV</rpad>
<time stamp='2020-01-01T00:00:00'/>
<from jid='alice@example.org/laptop'/>
<to jid='carol@example.org'/>
<payload>
<trust-message xmlns='urn:xmpp:trust-messages:0' encryption='eu.siacs.conversations.axolotl'>
<key-owner jid='alice@example.org'>
<trust>6850019d7ed0feb6d3823072498ceb4f616c6025586f8f666dc6b9c81ef7e0a4</trust>
<trust>221a4f8e228b72182b006e5ca527d3bddccf8d9e6feaf4ce96e1c451e8648020</trust>
</key-owner>
<key-owner jid='bob@example.com'>
<trust>623548d3835c6d33ef5cb680f7944ef381cf712bf23a0119dabe5c4f252cd02f</trust>
<distrust>b423f5088de9a924d51b31581723d850c7cc67d0a4fe6b267c3d301ff56d2413</distrust>
<distrust>d9f849b6b828309c5f2c8df4f38fd891887da5aaa24a22c50d52f69b4a80817e</distrust>
</key-owner>
</trust-message>
</payload>
</envelope>
</encrypted>
</message>
]]></example>
</section2>
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
<p>
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.
@ -235,13 +353,48 @@
Keep in mind that a trust message SHOULD only be encrypted for endpoints with authenticated keys.
</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>REQUIRED.</p>
<section1 topic='IANA Considerations' anchor='iana-considerations'>
<p>This document requires no interaction with the Internet Assigned Numbers Authority (IANA).</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>REQUIRED.</p>
<section1 topic='XMPP Registrar Considerations' anchor='xmpp-registrar-considerations'>
<section2 topic='Protocol Namespaces' anchor='xmpp-registrar-considerations-protocol-namespaces'>
<p>This specification defines the following XMPP namespaces:</p>
<ul>
<li>&ns;</li>
</ul>
</section2>
<section2 topic='Protocol Versioning' anchor='xmpp-registrar-considerations-protocol-versioning'>
&NSVER;
</section2>
</section1>
<section1 topic='XML Schema' anchor='schema'>
<p>REQUIRED for protocol specifications.</p>
<section1 topic='XML Schema' anchor='xml-schema'>
<code><![CDATA[
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace=']]>&ns;<![CDATA['
xmlns=']]>&ns;<![CDATA['
elementFormDefault='qualified'>
<xs:element name='trust-message'>
<xs:complexType>
<xs:attribute name='usage' type='xs:string' use='required'/>
<xs:attribute name='encryption' type='xs:string' use='required'/>
<xs:sequence>
<xs:element ref='key-owner' minOccurs='1' maxOccurs='unbounded'/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name='key-owner'>
<xs:complexType>
<xs:attribute name='jid' type='xs:string' use='required'/>
<xs:sequence>
<xs:element name='trust' type='xs:string' minOccurs='0' maxOccurs='unbounded'/>
<xs:element name='distrust' type='xs:string' minOccurs='0' maxOccurs='unbounded'/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
]]></code>
</section1>
</xep>