commit
e0dd138d40
@ -0,0 +1,62 @@
|
||||
# MSC2874: Single SSSS
|
||||
|
||||
[Secure Secret Storage and
|
||||
Sharing](https://github.com/matrix-org/matrix-doc/pull/1946) (SSSS) was
|
||||
designed to allow the user to create multiple keys that would be able to
|
||||
decrypt different subsets of the secrets. However, the vast majority of users
|
||||
do not need this feature.
|
||||
|
||||
This proposal defines how clients should behave if they only wish to support a
|
||||
single key, by defining which key clients should use if multiple keys are
|
||||
present. It also makes the `name` field in the `m.secret_storage.key.*` events
|
||||
optional, as this field was mainly added to allow a user to select between
|
||||
different keys.
|
||||
|
||||
## Proposal
|
||||
|
||||
If a client wants to present a simplified interface to users by not supporting
|
||||
multiple SSSS keys, then the client should use the default key (the key listed
|
||||
in the `m.secret_storage.default_key` account data event.) If there is no
|
||||
default key the client may behave as if there is no SSSS key at all. When such
|
||||
a client creates an SSSS key, it must mark that key as being the default key.
|
||||
|
||||
The `name` field in the `m.secret_storage.key.*` account data events is
|
||||
optional, rather than required. If a client wishes to display multiple keys to
|
||||
a user and a given key does not have a `name` field, the client may use a
|
||||
default name as the key's name, such as "Unnamed key", or "Default key" if the
|
||||
key is marked as default.
|
||||
|
||||
For example, when a client creates a key with ID `abcdefg`, it will create an
|
||||
`m.secret_storage.key.abcdefg` account data event to store information about
|
||||
the key. It will then mark it as the default key by setting the
|
||||
`m.secret_storage.default_key` account data to `{"key": "abcdefg"}`. When
|
||||
another client logs in after this, it will see that the default key has been
|
||||
set, and will know to use that key as the SSSS key.
|
||||
|
||||
## Potential issues
|
||||
|
||||
If secrets are encrypted using a key that is not marked as default, a client
|
||||
might not decrypt the secrets, even if it would otherwise be able to.
|
||||
|
||||
## Alternatives
|
||||
|
||||
Rather than solely relying on the key marked as default, a client could guess
|
||||
at what key to use. For example, it could look at the secrets that it needs,
|
||||
see what keys they are encrypted with, and if there is only one common key,
|
||||
then it could use that. (This is what Element currently does.) Or if there
|
||||
are multiple keys, it could use some sort of heuristic to pick a key. However,
|
||||
this approach can be error-prone, and it is better to rely on an explicit
|
||||
marking.
|
||||
|
||||
## Security considerations
|
||||
|
||||
None
|
||||
|
||||
## Unstable prefix
|
||||
|
||||
An unstable prefix is not needed for a behaviour change in choosing the key to
|
||||
use as there are no event/endpoint changes.
|
||||
|
||||
Some clients already omit the `name` field (notably, matrix-js-sdk
|
||||
unintentionally does this -- mea culpa), and this does not seem to be causing
|
||||
issues, so an unstable prefix seems unnecessary for this.
|
Loading…
Reference in New Issue