You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
matrix-spec/content/rooms/v5.md

46 lines
1.7 KiB
Markdown

---
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.