Simple key rotation procedure with web of trust.

This commit is contained in:
Vitor Pamplona 2024-02-16 10:06:52 -05:00
parent 36d2281587
commit 88178f09b0

51
22.md Normal file
View File

@ -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", "<pubkey>", "<relay_url>"],
],
"content": "<comment to followers>"
//...
}
```
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