Room Version 5
This room version builds on version 4 while enforcing signing key validity periods for events.
Table of Contents
1 Client considerations
There are no specific requirements for clients in this room version. Clients should be aware of event ID changes in room version 4, however.
2 Server implementation components
Warning
The information contained in this section is strictly for server implementors. Applications which use the Client-Server API are generally unaffected by the intricacies contained here. The section above regarding client considerations is the resource that Client-Server API use cases should reference.
Room version 5 uses the same algorithms defined in room version 4, ensuring that signing key validity is respected.
2.1 Signing key validity period
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.