NIP D8 Key Rotation

[staab]

This removes the time delay required by #829 by introducing a new single-purpose "migration" key. Users can set this up in advance, store it securely, and sign a single event with it if needed.

This NIP has one important trade-off, which is that in the worst case scenario an attacker gets access to a user's key and publishes their own migration event before the real user does (or gets access to the user's real migration key), locking them permanently out of their own account. This has the effect of making every current nostr user's security worse in the short term. Two things about this:

• This is an unavoidable implication of adding key rotation to a system in which a single key is a user's base identity. We could use DIDs or something instead, but that has its own problems. It seems like the nostr community is all-in on making keys work.
• The worst case scenario above is really not that much worse than the current worst case scenario today, in which the user retains access to their key, but so does the attacker.

Another significant flaw with this NIP is that it introduces a hard dependency on OTS, not only for key rotation events, but also for events signed by keys that have been rotated. I don't love the idea of coupling nostr's identity system to OTS, so I have proposed a few alternatives to OTS below. However, I think they're pretty sloppy and ad-hoc (if more lightweight). I'd like to see something more reliable and less trusted if possible. I'm open to suggestions on that.

• Expand NIP 03 to include relay and user notaries #1737
• Add META commands #2113

One further thing worth mentioning: in the past, a number of Hierarchical Deterministic key delegation schemes have been proposed, for example #450 and #1450. One revision of this NIP included the ability to create multiple simultaneously authorized keys for a single identity, which could be used as "device keys". However, the cost of validating keys is quite high (at least, if they can be invalidated), and so I think it's better to push people toward using bunkers instead of delegated keys. Supporting multiple authorized keys also made the protocol more complex, by separating key authorization and invalidation.

[fiatjaf]

Looks like a mix between Pablo's catastrophic key switching option with NIP-26? I think it's a nice try, has some advantages over both.

But also inherits the worst part of NIP-26: the decoupling between identities that makes it an absolute requirement (even if you say it doesn't in the backwards-compatibility section) for every client and relay to do a bunch of complicated queries every time they spot a new pubkey, then either keep that state stored (which is always a problem) or redo the queries over and over. This to me is way too much complexity.

Another issue is that I don't think relays should be necessary reliable. It's one assumption of Nostr that relays may stop working anytime, data may be lost or a client might miss some events from someone else without that affecting the general experience too much. But in the case of this NIP it becomes a requirement that relays are available at all times to respond with these events that position a public key with regards to their related keys, and that these events must not be missed by anyone.

[fiatjaf]

I prefer to keep assuming that an event is signed by a key and that key is that key, it doesn't point to anything else.

To the extent that we can associate a key with some individual at all that must be based on a link that exists outside the protocol, although information published on Nostr can and should be used to help create these links.

I think we would be better off spending time building more infrastructure around these link generation processes (for example, some metaprotocol that semi-automatically detects that some user A has transitioned from key M to key N based on stuff people are saying perhaps using some special event kind) rather than trying to solve the same issue using cryptography and complexity.

After all, even if by a miracle or by some centralization shortcut we got a very complete key rotation mechanism (like Bluesky's PLC) ultimately there will always be someone losing access to their keys and these off-protocol methods will have to be used to reestablish their identity.

[vitorpamplona]

Too many edge cases. The implementation is too complex.

I still prefer simpler revocation and not rotation schemes, like #1056

[staab]

@fiatjaf I have to agree with your critiques. Writing this NIP has taught me that any key rotation scheme on nostr is going to come with some hefty assumptions and trade-offs. Another problem I just noticed is that the attacker can change the user's outbox relay selections, causing events to be lost and enabling them to create their own migration key. It's just way too fragile without a strongly consistent source of truth.