You're looking at an unstable version of this specification. Unstable specifications may change at any time without notice.

Room Version 5

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

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.

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.

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.