1.7 KiB
title | type | weight |
---|---|---|
Room Version 5 | docs | 50 |
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
{{% boxes/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. {{% /boxes/warning %}}
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.