Room Version 5

This room version builds on version 4 while enforcing signing key validity periods for events.

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


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.