|
|
|
|
---
|
|
|
|
|
title: Room Version 5
|
|
|
|
|
type: docs
|
|
|
|
|
weight: 50
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
This room version builds on [version 4](/rooms/v4) 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](/rooms/v4), 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](/rooms/v4), 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](/server-server-api#get_matrixkeyv2serverkeyid)
|
|
|
|
|
or [POST
|
|
|
|
|
/\_matrix/key/v2/query](/server-server-api#post_matrixkeyv2query)
|
|
|
|
|
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.
|
