From fafd11f8095b8379c2dbc5bb0ddd11e557f22d6e Mon Sep 17 00:00:00 2001 From: timedout Date: Tue, 21 Apr 2026 21:24:28 +0100 Subject: [PATCH] Clarify how multiple signatures should be handled during verification (#2341) Signed-off-by: timedout --- .../newsfragments/2341.clarification | 1 + content/server-server-api.md | 48 +++++++++++-------- 2 files changed, 28 insertions(+), 21 deletions(-) create mode 100644 changelogs/server_server/newsfragments/2341.clarification diff --git a/changelogs/server_server/newsfragments/2341.clarification b/changelogs/server_server/newsfragments/2341.clarification new file mode 100644 index 00000000..868c353e --- /dev/null +++ b/changelogs/server_server/newsfragments/2341.clarification @@ -0,0 +1 @@ +Clarify how multiple signatures should be handled during signature verification. Contributed by @nexy7574. diff --git a/content/server-server-api.md b/content/server-server-api.md index 8bc0d28b..9dda3396 100644 --- a/content/server-server-api.md +++ b/content/server-server-api.md @@ -1484,34 +1484,30 @@ the Policy Server for a signature too. When a server receives an event over federation from another server, the receiving server should check the hashes and signatures on that event. -First the signature is checked. The event is redacted following the -[redaction -algorithm](/client-server-api#redactions), and -the resultant object is checked for a signature from the originating +First the signatures are checked. The event is redacted following the +[redaction algorithm](/client-server-api#redactions), and +the resultant object is checked for signatures from the originating server, following the algorithm described in [Checking for a signature](/appendices#checking-for-a-signature). Note that this step should succeed whether we have been sent the full event or a redacted copy. -The signatures expected on an event are: +For room versions 3 and later, unless the event is a 3rd party invite, only the +signature(s) from the originating server (the server the `sender` belongs to) +are required for verification. Room versions 1 and 2 also require that a +signature is present from the domain in the `event_id`, if it differs from the +originating server. If a signature is from an unknown or expired key, it is +skipped. -- The `sender`'s server, unless the invite was created as a result of - 3rd party invite. The sender must already match the 3rd party - invite, and the server which actually sends the event may be a - different server. -- For room versions 1 and 2, the server which created the `event_id`. - Other room versions do not track the `event_id` over federation and - therefore do not need a signature from those servers. +If the event is a 3rd party invite, the sender must already match the 3rd party +invite, and the server which actually sends the event may be a different +server. -If the signature is found to be valid, the expected content hash is -calculated as described below. The content hash in the `hashes` property -of the received event is base64-decoded, and the two are compared for -equality. - -If the hash check fails, then it is assumed that this is because we have -only been given a redacted version of the event. To enforce this, the -receiving server should use the redacted copy it calculated rather than -the full copy it received. +Only signatures from known server keys are validated here. Any unknown keys are ignored. +In particular, the [policy server key](#validating-policy-server-signatures) is not +expected to be published and therefore should be skipped at this stage. +Additionally, any keys that are known to have expired prior to the event's +`origin_server_ts` are ignored. {{% boxes/note %}} {{% added-in v="1.18" %}} @@ -1519,6 +1515,16 @@ Events sent in rooms with [Policy Servers](#policy-servers) have [additional](#v signature validation requirements. {{% /boxes/note %}} +If all signatures from known unexpired keys from the originating server(s) are +found to be valid, the expected content hash is calculated as described below. +The content hash in the `hashes` property of the received event is base64-decoded, +and the two are compared for equality. + +If the hash check fails, then it is assumed that this is because we have +only been given a redacted version of the event. To enforce this, the +receiving server should use the redacted copy it calculated rather than +the full copy it received. + ### Calculating the reference hash for an event The *reference hash* of an event covers the essential fields of an