matrix-spec-proposals/content/rooms/v5.md

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