Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2025-12-24 01:58:36 +01:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

fill in more details, including federation bits

Browse source
This commit is contained in:
Hubert Chathi 2019-02-12 20:12:17 -05:00
parent ca0baa54df
commit ca7aa8b0ba
1 changed files with 33 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

37
proposals/1756-cross-signing.md
View file

@ -69,6 +69,8 @@ use cases.
### API description
#### Uploading signing keys
Public keys for the self-signing and user-signing keys are uploaded to the
servers using `/keys/device_signing/upload`. This endpoint requires [UI
Auth](https://matrix.org/docs/spec/client_server/r0.4.0.html#user-interactive-authentication-api).
@ -99,6 +101,18 @@ Auth](https://matrix.org/docs/spec/client_server/r0.4.0.html#user-interactive-au
}
```
Self-signing and user-signing keys are JSON objects with the following
properties:
* `user_id` (string): The user who owns the key
* `usage` ([string]): Allowed uses for the key. Must be `["self_signing"]` for
self-signing keys, and `["user_signing"]` for user-signing keys.
* `keys` ({string: string}): an object that must have one entry, whose name is
"`ed25519:`" followed by the unpadded base64 encoding of the public key, and
whose value is the unpadded base64 encoding of the public key.
* `signatures` ({string: {stringg: string}}): signatures of the key. A
user-signing key must be signed by the self-signing key.
In order to ensure that there will be no collisions in the `signatures`
property, the server must respond with an error (FIXME: what error?) if any of
the uploaded public keys match an existing device ID for the user. Similarly,
@ -113,8 +127,6 @@ a `replaces` property whose value is the previous public self-signing key.
Otherwise the server must respond with an error (FIXME: what error?). The new
self-signing key may also be signed with the old self-signing key.
FIXME: document `usage` property
After uploading self-signing and user-signing keys, they will be included under
the `/keys/query` endpoint under the `self_signing_key` and `user_signing_key`
properties, respectively. The `user_signing_key` will only be included when a
@ -153,10 +165,22 @@ response:
}
```
Similarly, the federation endpoints `GET /user/keys/query` and
`POST /user/devices/{userId}` will include the self-signing key.
In addition, Alice's homeserver will send a `m.signing_key_update` EDU to
servers that have users who share encrypted rooms with Alice. The `content` of
that EDU has the following properties:
* `user_id` (string): Required. The user ID who owns the signing key
* `self_signing_key` (object): Required. The self-signing key, as above.
After uploading self-signing and user-signing keys, the user will show up in
the `changed` property of the `device_lists` field of the sync result of any
others users who share an encrypted room with that user.
#### Uploading signatures
Signatures of keys can be uploaded using `/keys/signatures/upload`.
For example, Alice signs one of her devices (HIJKLMN), and Bob's self-signing key.
@ -258,6 +282,13 @@ response:
}
```
Similarly, the federation endpoints `GET /user/keys/query` and
`POST /user/devices/{userId}` will include the new signature.
In addition, Alice's server will send an `m.device_list_update` EDU to servers
that have users who share encrypted rooms with Alice, updating her device to
include her new signature.
After Alice uploads a signature for Bob's user-signing key, her signature will
be included in the results of the `/keys/query` request when Alice requests
Bob's key:
@ -289,8 +320,6 @@ Bob's key:
}
```
FIXME: s2s stuff
## Comparison with MSC1680
MSC1680 suffers from the fact that the attestation graph may be arbitrarily