moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-23 17:52:15 -05:00
Code Issues Releases Wiki Activity

XEP-0450: Release version 0.2.0

Browse Source 
Add usage of Trust Message URIs, use more precise sentences, apply consistent formatting:

* Add usage of Trust Message URIs for initial authentications
* Use 'that' instead of 'which' for restrictive clauses
* Apply consistent formatting for paragraphs and revision history
This commit is contained in:
Melvin Keskin 2021-04-13 19:51:36 +02:00
parent ae0bdfb2fc
commit 1f285c65be
No known key found for this signature in database
GPG Key ID: 04EFAD0F7A4D9724
1 changed files with 45 additions and 27 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

60
xep-0450.xml
View File

@ -37,17 +37,30 @@
<email>melvo@olomono.de</email>
<jid>melvo@olomono.de</jid>
</author>
<revision>
<version>0.2.0</version>
<date>2021-04-13</date>
<initials>melvo</initials>
<remark>
<p>Add usage of Trust Message URIs, use more precise sentences, apply consistent formatting:</p>
<ul>
<li>Add usage of Trust Message URIs for initial authentications</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.1.0</version>
<date>2020-12-15</date>
<initials>XEP Editor (jsc)</initials>
<remark>Accepted by vote of Council on 2020-12-02.</remark>
<remark>Accepted by vote of Council on 2020-12-02</remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2020-11-05</date>
<initials>melvo</initials>
<remark><p>First draft.</p></remark>
<remark><p>First draft</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='introduction'>
@ -63,7 +76,7 @@
<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.
It can be used especially for end-to-end encryption protocols such as &xep0384; that use one key per endpoint of the same identity.
</p>
</section1>
<section1 topic='Glossary' anchor='glossary'>
@ -105,14 +118,14 @@
<di>
<dt>Authentication message</dt>
<dd>
Trust message which only contains key identifiers for authentication.
Trust message that 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.
Trust message that 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>
@ -124,7 +137,7 @@
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 network of endpoints that 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>
@ -143,7 +156,8 @@
</section1>
<section1 topic='Use Cases' anchor='use-cases'>
<p>
Everything which is RECOMMENDED by &xep0434; MUST be applied.
Everything that is RECOMMENDED by &xep0434; MUST be applied.
Trust Message URIs as specified by &xep0434; SHOULD be used for the initial authentications.
</p>
<p>
The examples contain &xep0384; as the encryption protocol because it uses one key per endpoint of the same identity.
@ -174,7 +188,7 @@
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 ...
An endpoint that 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>
@ -219,7 +233,7 @@
</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 ...
An endpoint that 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>
@ -240,7 +254,7 @@
</p>
</section4>
<p>
... MUST authenticate the key as soon as the receiving endpoint authenticated the key of the endpoint which sent the authentication message.
... MUST authenticate the key as soon as the receiving endpoint authenticated the key of the endpoint that sent the authentication message.
</p>
</section3>
</section2>
@ -252,7 +266,7 @@
A2 authenticates A3's key.
</p>
<p>
An endpoint which initially authenticates the key of an own endpoint MUST send an authentication message for ...
An endpoint that 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>
@ -315,7 +329,7 @@
</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.
An endpoint that 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 that sent the authentication message.
</p>
<p>
Example:
@ -331,7 +345,7 @@
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.
An endpoint that 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['>
@ -366,7 +380,7 @@
</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.
An endpoint that 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 that sent the distrust message.
</p>
<p>
Example:
@ -382,7 +396,7 @@
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.
An endpoint that 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['>
@ -402,7 +416,7 @@
</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 ...
An endpoint that 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>
@ -423,7 +437,7 @@
</p>
</section4>
<p>
... MUST distrust the key as soon as the receiving endpoint authenticated the key of the endpoint which sent the distrust message.
... MUST distrust the key as soon as the receiving endpoint authenticated the key of the endpoint that sent the distrust message.
</p>
</section3>
</section2>
@ -431,7 +445,7 @@
<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.
A client MUST save the information of a trust message until the key of the endpoint that 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>
@ -479,18 +493,22 @@
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.
If keys are automatically trusted until the first authentication, keys that 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>
<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>
<p>
This specification defines the following XMPP namespaces:
</p>
<ul>
<li>&ns;</li>
</ul>