feat: http server based key package registry#124
Conversation
kaichaosun
force-pushed
the
http-key-registry
branch
from
33f228f to
bb1beff
Compare
kaichaosun
force-pushed
the
http-key-registry
branch
from
bb1beff to
9a01fac
Compare
kaichaosun
force-pushed
the
http-key-registry
branch
from
53c45c7 to
e0f6054
Compare
kaichaosun
force-pushed
the
http-key-registry
branch
from
3705d27 to
3683ba5
Compare
|
|
||
| ```json | ||
| { | ||
| "account_id": "user-chosen label", |
There was a problem hiding this comment.
[Pebble] Account Id cannot be a user-chosen label. It must be a static, string derived from the account
|
|
||
| **Server is dumb storage.** Submissions are stored without verification. Bundles carry a self-signature by the device key over `(account_id || device_pubkey || key_package || ts_le)`; consumers verify it on retrieve. This catches a replay attack where someone copies a victim's bundle and re-posts it under a different `account_id` — the signature commits to the original `account_id` and won't verify against the new one. | ||
|
|
||
| The self-signature does **not** prove that `device_pubkey` is actually authorized for `account_id` (an attacker can mint their own keys and sign anything). That impersonation gap closes once λLEZ provides the on-chain authorization mapping in v0.3. |
There was a problem hiding this comment.
The problem here is that this registry is attempting to solve two problems at once.
Account registration (The association of Installations/DeviceKeys into a single account) and the caching of KeyPackages from a single DeviceKey.
Solving both at the same time adds more complication. I'd focus only on the KeyPackage caching for now, then address Accounts in a later PR.
| ``` | ||
|
|
||
| `signature` MUST be Ed25519 by `device_pubkey` over the byte concatenation | ||
| `account_id || device_pubkey || key_package || timestamp_ms.to_le_bytes()`. |
There was a problem hiding this comment.
[Dust] Having the signature being defined over byte concat, and the "Package" being transported to the server being defined as base64 encoded JSON, makes validating the payload more difficult.
Conside symmetry, by using a well defined binary payload, with an associated signature.
| ```json | ||
| { | ||
| "account_id": "user-chosen label", | ||
| "device_pubkey": "base64(32-byte ed25519 verifying key)", |
There was a problem hiding this comment.
[?] What key does this correspond to?
| The server validates only basic shapes (`device_pubkey` 32 bytes, `signature` | ||
| 64 bytes, valid base64). It does **not** verify the signature — verification | ||
| happens client-side on retrieve. Returns `204 No Content` on success, `400` | ||
| on shape errors. |
There was a problem hiding this comment.
[?] Is there a reason why the serve couldn't validate signatures in this test case?
| ### `GET /v0/keypackage/{account_id}` | ||
|
|
||
| Returns the most recently submitted bundle for that id, across all devices. | ||
|
|
There was a problem hiding this comment.
[?] What is considered a bundle in this case?
There was a problem hiding this comment.
The issue with querying by account_id is that key-packages are single use, per group. If one of the keypackages have already been used, its harder to request another another one.
| [package] | ||
| name = "keypackage-registry" | ||
| version = "0.1.0" | ||
| edition = "2024" |
There was a problem hiding this comment.
This will need need to be deployed and managed in its own repository.
2 participants
Changes:
--registry-urlflag on chat-cli. Without the flag, behavior is unchanged.Fix #110.