Key migration

D8.md

@@ -0,0 +1,79 @@
+NIP-D8
+======
+
+Nostr Key Migration
+-------------------
+
+`draft` `optional`
+
+This NIP defines a simple mechanism which allows users to migrate to a new key and invalidate their current account. It combines signatures, social key recovery, Open Timestamp Attestations, and some trust assumptions to prevent hijacking by an attacker or loss of control through over-reliance on the social graph.
+
+## Creating a Migration Key
+
+A user can create a `kind 360` `precommit` event which includes a single public key that is authorized in advanced as a `migration` key. This key MUST be stored securely.
+
+```typescript
+{
+  "kind": 360,
+  "pubkey": "<identity pubkey>"
+  "tags": [
+    ["p", "<migration pubkey>"]
+  ],
+  // Other fields
+}
+```
+
+## Migrating to a New Key
+
+In order to migrate to a new key, a new `successor` key SHOULD be generated **at the time of migration**. Any `migration` key designated by a valid `kind 360` event may then be used to sign a `kind 361` `migration` event.
+
+Migration keys MUST NOT be used for anything other than signing a single `kind 361` event.
+
+```typescript
+{
+  "kind": 361,
+  "pubkey": "<migration pubkey>",
+  "tags": [
+    ["p", "<successor pubkey>"],
+    ["e", "<id of the precommit event>", "<relay hint>"]
+  ],
+}
+```
+
+Clients SHOULD NOT rely on `migration` events existing long-term, but should make an effort to help users move away from a user's old key as soon as possible. However, clients SHOULD NOT follow `successor` keys without explicit user consent.
+
+When migrating to a new key, users MAY re-publish any content or metadata they want to be preserved on their account. Implementations SHOULD NOT attempt to establish a live link between the old and new identities.
+
+## Opting Out
+
+Users SHOULD publish a `kind 360` event as soon as their account becomes valuable to them. If a key is leaked before a `migration` event is published, the attacker will be able to migrate to their own key, locking the original user permanently out of their account. This is the key trade-off of this NIP.
+
+If a user prefers not to enable key migration on their account, they SHOULD publish a `kind 360` event with no designated `successor` keys, making it impossible to migrate.
+
+## Appendix A: Event Storage and Validation
+
+This NIP is highly dependent on the existence of a complete and ordered record of `kind 360` and `kind 361` events.
+
+`kind 360` MUST be readily available non-interactively (i.e., it can't be revealed at the same time a `kind 361` event is created), because an attacker with posession of the user's current key would otherwise be able to hijack the migration process by creating their own `kind 360` `precommit` and `kind 361` `migration` events.
+
+Nostr relays offer no consistency guarantees, which means commodity relays cannot support this use case. Outbox relays can't be trusted because an attacker with access to a user's private key can update them. Trusted relays of any kind can become attack vectors, since they can selectively omit entries, facilitating a migration attack.
+
+These risks can be mitigated (but not solved) in classically nostr fashion by spreading trust across a large number of `migration` relays. These relays MUST be independently run, and their owners MUST have an incentive to prevent account theft, which can only be assessed manually. All of these relays would have to collude in order to prevent a correct migration from occurring.
+
+However these relays are chosen, the entire network MUST use the same set. Network partitioning is unacceptable in this case. Selection of actual relays is left to the nostr community.
+
+All `kind 360` and `kind 361` events MUST be published to all `migration` relays along with an accompanying `kind 1040` [Open Timestamp Attestation](03.md) event. If multiple conflicting events exist, the first one published MUST be used.
+
+In both cases, only the first event of each kind published by a given key is valid. `migration` relays MUST validate Open Timestamp attestations, and ensure that only `kind 361` events that match a valid `kind 360` event are stored. Clients SHOULD also perform this validation. `migration` relays MUST NOT delete `kind 360` or `kind 361` events for any reason.
+
+## Appendix B: In-Band Social Key Recovery
+
+The recommended approach to `migration` key storage uses social key recovery in order to combine the strengths of cryptographic signatures with trusted counter parties. In this system, neither key compromise nor social engineering is a sufficient condition for an attacker to hijack the key migration process. This approach is not required, but SHOULD be considered the default.
+
+For each `migration` key committed to in a `kind 360` event, use the [codex32 standard](https://secretcodex32.com/) for Shamir secret sharing to split the key into `n` shards.
+
+For each shard, create a `kind 362` event with a `p` tag indicating the original user's pubkey, and a `shard` tag containing the shard. This event MUST NOT be signed, but MUST be wrapped following [NIP 59](59.md).
+
+Each `kind 1059` wrapper event MUST be addressed to a user who the original user trusts not to leak the key material, and who will likely be available reconstitute the key. Holders of key shards SHOULD remain anonymous in order to prevent shard holder collusion, as well as additional attacks against shard holders.
+
+In order to migrate a key, the original user SHOULD contact each shard holder out of band to recover the key material and use it to sign and publish a `kind 361` `migration` event.