mirror of
https://github.com/matrix-org/matrix-spec
synced 2026-04-25 03:54:10 +02:00
241e01c332
* Fully specify room versions * Misc typo clarifications * Try to clarify redactions a bit * Update content/client-server-api/_index.md Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> * Update content/rooms/v6.md Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> * Update content/rooms/v6.md Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> * Better describe client considerations * Doc template params * Move redaction "new stuff" to v3 * Remove unhelpful sentences about "here follows unchanged stuff" * Simplify event signing text * Clean up handling redactions sections * Move v4's event schema to unchanged section * Update content/rooms/v4.md Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
852 B
852 B
When validating event signatures, servers MUST enforce the
valid_until_ts property from a key request is at least as large as the
origin_server_ts for the event being validated. Servers missing a copy
of the signing key MUST try to obtain one via the GET
/_matrix/key/v2/server
or POST
/_matrix/key/v2/query
APIs. When using the /query endpoint, servers MUST set the
minimum_valid_until_ts property to prompt the notary server to attempt
to refresh the key if appropriate.
Servers MUST use the lesser of valid_until_ts and 7 days into the
future when determining if a key is valid. This is to avoid a situation
where an attacker publishes a key which is valid for a significant
amount of time without a way for the homeserver owner to revoke it.