Clarify how multiple signatures should be handled during verification (#2341)

Signed-off-by: timedout <git@nexy7574.co.uk>

changelogs/server_server/newsfragments/2341.clarification

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

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