Consider not requiring the cross-signing keys after verification
Issue
Currently the verification fails if we don't get the cross-signing keys we want from the other device. Previously, the verification step would succeed but we would ask the user to verify the session again every time the application is launched, so the result was similar.
There are no simple solutions for the user to fix this. We provide ways that could fix it (verify against another device, that might have the keys), or that will definitely fix it but have unwanted side effects (resetting the cross-signing identity, which means all previous verifications are invalid and need to be done again).
These solutions shouldn't be required of the users because it doesn't prevent them from using the main feature or Fractal, which is chatting with other users, and the problem is due to limitations in the SDK (see below) rather than a real issue with the account configuration.
Context
There are 3 signing keys:
- The master key, it is used to sign the other signing keys, so is only required when we want to change the other keys without resetting the whole cross-signing identity (which would mean any previous verification needs to be done again).
- The self-signing key, it is used to sign the sessions of our Matrix user, so it is required to verify one of our devices.
- The user-signing key, it is used to sign other identities, so other Matrix users, and as such is required to verify another user.
We currently require the self-signing key and user-signing key, to be able to verify our own sessions and other users.
There are two ways to obtain these keys in the Matrix spec, if they already exist:
- Ask our other sessions to share the keys with us
- Retrieve them from the online secret storage on the homeserver.
We currently only use n°1, due to lack of implementation of n°2 in the SDK.
Now, let's assume the client we ask the keys to is Element Web (the behavior is probably the same for all Element clients, and maybe others). It implements n°2, and requests the keys lazily because it knows it can have access to them, which means:
- If we ask it for all the keys, it only sends the ones it has locally and doesn't try to download the others.
- It usually only has all 3 keys locally if it is the session that created the cross-signing identity.
- If it is a new session that hasn't verified another session since it was logged in, it usually has 0 keys locally. During the verification process it needs to sign our session, so it will download the self-signing key. At the end of the verification it should be able to send us only this 1 key.
Solutions
- Given the context above, the best solution would be of course to have support for n°2, but we don't have an ETA so we can't rely on it for the time being. If we did support this, requiring a way to have access to the cross-signing keys and failing verification otherwise would make sense since we should have a way to access them.
- I believe the most sensible solution currently is to not require the cross-signing keys at the end of the verification, and disable in the interface the actions that are not possible according to the keys that are available.