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 'feature/xep-0434' into premerge

Browse Source
This commit is contained in:
Jonas Schäfer 2021-04-13 19:58:19 +02:00
commit fdcca96a66
1 changed files with 68 additions and 26 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

94
xep-0434.xml
View File

@ -35,7 +35,20 @@
<surname>Keskin</surname>
<email>melvo@olomono.de</email>
<jid>melvo@olomono.de</jid>
</author>
</author>
<revision>
<version>0.4.0</version>
<date>2021-04-13</date>
<initials>melvo</initials>
<remark>
<p>Add new section, use more precise sentences, apply consistent formatting:</p>
<ul>
<li>Add new section for Trust Message URIs</li>
<li>Use 'that' instead of 'which' for restrictive clauses</li>
<li>Apply consistent formatting for paragraphs and revision history</li>
</ul>
</remark>
</revision>
<revision>
<version>0.3.0</version>
<date>2020-12-19</date>
@ -44,7 +57,7 @@
<p>Clarify usage, use real namespace for examples and add missing section:</p>
<ul>
<li>Clarify usage of trust messages by protocols such as &xep0450;</li>
<li>Use namespace 'urn:xmpp:atm:0' of &xep0450; as example for 'usage' attribute.</li>
<li>Use namespace 'urn:xmpp:atm:0' of &xep0450; as example for 'usage' attribute</li>
<li>Add section 'Security Considerations'</li>
</ul>
</remark>
@ -56,16 +69,16 @@
<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>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>
<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>
@ -73,13 +86,13 @@
<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>
<remark>Accepted by vote of Council on 2020-02-19</remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2020-02-15</date>
<initials>melvo</initials>
<remark><p>First draft.</p></remark>
<remark><p>First draft</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='introduction'>
@ -90,8 +103,8 @@
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 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.
When using end-to-end encryption where public long-term keys are transmitted over a channel that 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 another channel that 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>
@ -128,7 +141,7 @@
<di>
<dt>Trust message</dt>
<dd>
XMPP message which indicates that specific keys are trusted or untrusted by the sending endpoint.
XMPP message that indicates whether 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>
@ -193,11 +206,11 @@
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.
Therefore, the attacker wants to block data that 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.
Data that 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>
@ -214,7 +227,7 @@
</p>
<ul>
<li>
MUST contain exactly one <![CDATA[<trust-message/>]]> direct child element which
MUST contain exactly one <![CDATA[<trust-message/>]]> direct child element that
<ul>
<li>
MUST be signed in a way to ensure its authenticity and integrity.
@ -226,19 +239,19 @@
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.
MUST have a <em>usage</em> attribute specifying the namespace of the protocol that 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
MUST contain at least one <![CDATA[<key-owner/>]]> direct child element that
<ul>
<li>
MUST have a <em>JID</em> attribute specifying the owner of the keys.
MUST have a <em>JID</em> attribute specifying the bare JID of the key owner.
</li>
<li>
MUST contain at least one <![CDATA[<trust/>]]> or <![CDATA[<distrust/>]]> direct child element which indicates the trust respectively distrust in a key.
MUST contain at least one <![CDATA[<trust/>]]> or <![CDATA[<distrust/>]]> direct child element indicating the trust respectively distrust in a key.
Each <![CDATA[<trust/>]]> and <![CDATA[<distrust/>]]> element MUST contain exactly one key identifier.
</li>
</ul>
@ -291,7 +304,7 @@
<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.
When using an encryption protocol such as &xep0384; that 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>
@ -374,11 +387,40 @@
</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana-considerations'>
<p>This document requires no interaction with the Internet Assigned Numbers Authority (IANA).</p>
<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='URI Query Types' anchor='xmpp-registrar-considerations-uri-query-types'>
<p>
As authorized by &xep0147;, the XMPP Registrar maintains a registry of queries and key-value pairs for use in XMPP URIs (see &QUERYTYPES;).
</p>
<section3 topic='trust-message' anchor='xmpp-registrar-considerations-uri-query-types-trust-message'>
<p>
An XMPP URI with the <em>trust-message</em> query type (defined as <em>Trust Message URI</em>) MAY be used to provide a trust message for various purposes and a single key owner out-of-band.
Such a URI MAY be encoded as a QR code and used if only a QR code scan is available as a trusted channel.
E.g., the <em>initial authentication</em> needed by &xep0450; can be performed by scanning a QR code that encodes a Trust Message URI.
</p>
<p>
Only a Trust Message URI from a trusted source SHOULD be processed because of its impact on the communication's security.
Therefore, users SHOULD be asked for confirmation if a Trust Message URI is used to make a trust decision.
</p>
<p>
The <em>JID</em> attribute of the <![CDATA[<key-owner/>]]> element MUST be used as the Trust Message URI's path.
The first key-value pair of the URI's query MUST represent the <em>encryption</em> attribute of the <![CDATA[<trust-message/>]]> element.
All remaining key-value pairs of the URI's query MUST represent the <![CDATA[<trust/>]]> respectively <![CDATA[<distrust/>]]> elements of the <![CDATA[<key-owner/>]]> element.
The key of a key-value pair MUST be the element's respectively attribute's name and the value their content.
</p>
<example caption='Trust Message URI for Bob&apos;s OMEMO keys'><![CDATA[
xmpp:bob@example.com?trust-message;encryption=]]>&ns-omemo;<![CDATA[;trust=623548d3835c6d33ef5cb680f7944ef381cf712bf23a0119dabe5c4f252cd02f;distrust=b423f5088de9a924d51b31581723d850c7cc67d0a4fe6b267c3d301ff56d2413;distrust=d9f849b6b828309c5f2c8df4f38fd891887da5aaa24a22c50d52f69b4a80817e
]]></example>
</section3>
</section2>
<section2 topic='Protocol Namespaces' anchor='xmpp-registrar-considerations-protocol-namespaces'>
<p>This specification defines the following XMPP namespaces:</p>
<p>
This specification defines the following XMPP namespaces:
</p>
<ul>
<li>&ns;</li>
</ul>