From 88178f09b0fa8084dda5fd00268c86144d17918b Mon Sep 17 00:00:00 2001 From: Vitor Pamplona Date: Fri, 16 Feb 2024 10:06:52 -0500 Subject: [PATCH] Simple key rotation procedure with web of trust. --- 22.md | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+) create mode 100644 22.md diff --git a/22.md b/22.md new file mode 100644 index 00000000..9d832e93 --- /dev/null +++ b/22.md @@ -0,0 +1,51 @@ +NIP-22 +====== + +Key Rotation +------------ + +`draft` `optional` + +Kind 18 informs the network that the owner of the pubkey is migrating to a new key. The event MUST contain a single `p` tag with the new pubkey to be used to communicate with the owner. + +```js +{ + "kind": 18, + "tags": [ + ["p", "", ""], + ], + "content": "" + //... +} +``` + +Close acquaintances to the owner should verify the intention off-nostr and signal their assessment of the request's accuracy by following the new key. + +## Interpretation + +The presence of one or more `kind:18`s, no matter who writes it, declares the key to be out of use, unreliable, unsafe and potentially stolen: No event, past and future, from this key can be trusted anymore. + +Users that have a `kind:18` published by their keys MUST migrate to a new key. + +There can be multiple `kind:18`s pointing to separate keys. Finding which event is the right one requires observing contact lists of trusted keys. + +## Information retention + +Supporting Relays and Clients MUST NOT accept Event Deletion ([NIP-09](09.md)) requests of `kind:18`s. + +Clients SHOULD use Generic Repost (`kind:16`) with a stringified version of the `kind:18` to guarantee its retention in as many relays as possible. + +## Client Behavior + +Upon receiving a new `kind:18`, Clients MUST warn their user the pubkey is unsafe. + +Clients SHOULD offer ways to investigate and verify if: +1. the transition to a new key was intended by the owner OR +2. if this is an attack and the new key is controlled by an attacker. + +It's ok to delay verification until trusted keys start informing their assessments. + +Upon verification, Clients SHOULD offer transition to the new key by: +1. Changing the contact list accordingly +2. Changing any NIP-51 list accordingly +3. Adding the key to the Mute List