Merge 8947eaf0b2 into 486a8f8764

changelogs/server_server/newsfragments/2341.clarification

@@ -1 +0,0 @@
-Clarify how multiple signatures should be handled during signature verification. Contributed by @nexy7574.

content/server-server-api.md

@@ -1484,30 +1484,34 @@ 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 signatures are checked. The event is redacted following the
+First the signature is checked. The event is redacted following the
-[redaction algorithm](/client-server-api#redactions), and
+[redaction
-the resultant object is checked for signatures from the originating
+algorithm](/client-server-api#redactions), and
+the resultant object is checked for a signature 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.
 
-For room versions 3 and later, unless the event is a 3rd party invite, only the
+The signatures expected on an event are:
-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.
 
-If the event is a 3rd party invite, the sender must already match the 3rd party
+-   The `sender`'s server, unless the invite was created as a result of
-invite, and the server which actually sends the event may be a different
+    3rd party invite. The sender must already match the 3rd party
-server.
+    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.
 
-Only signatures from known server keys are validated here. Any unknown keys are ignored.
+If the signature is found to be valid, the expected content hash is
-In particular, the [policy server key](#validating-policy-server-signatures) is not
+calculated as described below. The content hash in the `hashes` property
-expected to be published and therefore should be skipped at this stage.
+of the received event is base64-decoded, and the two are compared for
-Additionally, any keys that are known to have expired prior to the event's
+equality.
-`origin_server_ts` are ignored.
+
+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.
 
 {{% boxes/note %}}
 {{% added-in v="1.18" %}}
@@ -1515,16 +1519,6 @@ 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