From bf8fa44e8ab74c9d0ee71fc7008566d66e3fcaa0 Mon Sep 17 00:00:00 2001 From: Melvin Keskin Date: Tue, 13 Apr 2021 19:46:40 +0200 Subject: [PATCH] XEP-0434: Release version 0.4.0 Add new section, use more precise sentences, apply consistent formatting: * Add new section for Trust Message URIs * Use 'that' instead of 'which' for restrictive clauses * Apply consistent formatting for paragraphs and revision history --- xep-0434.xml | 94 +++++++++++++++++++++++++++++++++++++--------------- 1 file changed, 68 insertions(+), 26 deletions(-) diff --git a/xep-0434.xml b/xep-0434.xml index fe6063f2..0c19265c 100644 --- a/xep-0434.xml +++ b/xep-0434.xml @@ -35,7 +35,20 @@ Keskin melvo@olomono.de melvo@olomono.de - + + + 0.4.0 + 2021-04-13 + melvo + +

Add new section, use more precise sentences, apply consistent formatting:

+
    +
  • Add new section for Trust Message URIs
  • +
  • Use 'that' instead of 'which' for restrictive clauses
  • +
  • Apply consistent formatting for paragraphs and revision history
  • +
+
+
0.3.0 2020-12-19 @@ -44,7 +57,7 @@

Clarify usage, use real namespace for examples and add missing section:

@@ -56,16 +69,16 @@

Improve explanations, descriptions and examples, introduce new attribute and complete all sections:

    -
  • Remove link to encryption protocol namespaces.
  • +
  • Remove link to encryption protocol namespaces
  • Add short name
  • -
  • Shorten and improve introduction.
  • -
  • Use emphasizing text formatting instead of quotation marks.
  • -
  • Add new section for explaining the core properties of trust messages.
  • -
  • Add examples comparing trust messages to public key certificates.
  • -
  • Improve description of trust message structure.
  • -
  • Introduce 'usage' attribute for 'trust-message' element.
  • -
  • Focus on &xep0420; and adjust examples accordingly.
  • -
  • Complete sections 'IANA Considerations', 'XMPP Registrar Considerations' and 'XML Schema'.
  • +
  • Shorten and improve introduction
  • +
  • Use emphasizing text formatting instead of quotation marks
  • +
  • Add new section for explaining the core properties of trust messages
  • +
  • Add examples comparing trust messages to public key certificates
  • +
  • Improve description of trust message structure
  • +
  • Introduce 'usage' attribute for 'trust-message' element
  • +
  • Focus on &xep0420; and adjust examples accordingly
  • +
  • Complete sections 'IANA Considerations', 'XMPP Registrar Considerations' and 'XML Schema'
@@ -73,13 +86,13 @@ 0.1.0 2020-02-27 XEP Editor (jsc) - Accepted by vote of Council on 2020-02-19. + Accepted by vote of Council on 2020-02-19 0.0.1 2020-02-15 melvo -

First draft.

+

First draft

@@ -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.

- 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.

@@ -128,7 +141,7 @@
Trust message
- 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.
@@ -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.

- 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.

@@ -214,7 +227,7 @@