wholetrans/docs-matrix-spec
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Apply suggestions from code review

Browse source 
Co-authored-by: Denis Kasak <dkasak@termina.org.uk>
This commit is contained in:
Hubert Chathi 2022-11-15 18:17:20 -05:00 • committed by GitHub
parent dd0f867fad
commit d0cbd4c8dd
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
3 changed files with 20 additions and 13 deletions
Download patch file Download diff file Expand all files Collapse all files

27
content/client-server-api/modules/end_to_end_encryption.md
View file

@ -996,16 +996,23 @@ If a user's client sees that any other user has changed their master
key, that client must notify the user about the change before allowing
communication between the users to continue.
Since device IDs and cross-signing keys occupy the same namespace, clients must
ensure that they use the correct keys when verifying. While servers must not
allow devices to have the same IDs as cross-signing keys, a malicious server
could construct such a situation, so clients must not rely on the server being
well-behaved and should take precautions against this. For example, clients
should refer to keys using the public keys rather than only by the device
ID. Clients should also fix the keys that are being verified, and ensure that
they do not change in the course of verification. Clients may also display a
warning and refuse to verify a user when it detects that the user has a device
with the same ID as a cross-signing key.
Since device key IDs (`ed25519:DEVICE_ID`) and cross-signing key IDs
(`ed25519:PUBLIC_KEY`) occupy the same namespace, clients must ensure that they
use the correct keys when verifying.
While servers MUST not allow devices to have the same IDs as cross-signing
keys, a malicious server could construct such a situation, so clients must not
rely on the server being well-behaved and should take the following precautions
against this.
1. Clients MUST refer to keys by their public keys during the verification
process, rather than only by the key ID.
2. Clients MUST fix the keys that are being verified at the beginning of the
verification process, and ensure that they do not change in the course of
verification.
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.
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

2
data/event-schemas/schema/m.secret.request.yaml
View file

@ -26,7 +26,7 @@ properties:
description: |-
A random string uniquely identifying (with respect to the requester
and the target) the target for a secret. If the secret is requested
from multiple devices at the same time, the same ID may be used for
from multiple devices at the same time, the same ID MAY be used for
every target. The same ID is also used in order to cancel a previous
request.
required:

4
data/event-schemas/schema/m.secret.send.yaml
View file

@ -9,8 +9,8 @@ description: |-
The `request_id` must match the ID previously given in an `m.secret.request`
event. The recipient must ensure that this event comes from a device that the
`m.secret.request` event was originally sent to, and that the device is
trusted. This should be done by checking the sender key of the Olm session that
the event was sent over.
a trusted device owned by the recipient. This should be done by checking the
sender key of the Olm session that the event was sent over.
properties:
content:
properties: