From 19e29e36af9f32d09ad182e9d7956f3cfb718358 Mon Sep 17 00:00:00 2001 From: Hubert Chathi Date: Tue, 15 Nov 2022 19:17:49 -0500 Subject: [PATCH] more clarifications --- .../client-server-api/modules/end_to_end_encryption.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/content/client-server-api/modules/end_to_end_encryption.md b/content/client-server-api/modules/end_to_end_encryption.md index 199a6662..e4d8137d 100644 --- a/content/client-server-api/modules/end_to_end_encryption.md +++ b/content/client-server-api/modules/end_to_end_encryption.md @@ -1013,6 +1013,10 @@ against this. 3. Clients SHOULD also display a warning and MAY refuse to verify a user when it detects that the user has a device with the same ID as a cross-signing key. +4. If a client does not detect when a device has the same ID as a cross-signing + key, it MUST check key IDs being verified in a consistent order: it must + check if the key ID matches a cross-signing key first, and if not, treat it + as a device ID. A user's user-signing and self-signing keys are intended to be easily replaceable if they are compromised by re-issuing a new key signed by @@ -1615,8 +1619,8 @@ that they can decrypt future messages encrypted using this session. An messages. When a client receives a Megolm session, the client MUST ensure that the -session was received via a channel that ensures authenticity of the messages. -Practically speaking, this means that Megolm sessions must be received via Olm. +session was received via an Olm channel, in order to ensure the authenticity of +the messages. When a client is updating a Megolm session in its store, the client MUST ensure: