Key rotation verified through root key attestation

The purpose here is to provide users with a mechanism to use revocable "hot" keys in less secure application-level contexts while keeping the root key that defines their identity in cold storage, only used for signing the attestation event described below. This NIP would not replace or attempt to improve upon NIP-26. That's an entirely different use case.

I can imagine a simple key management scheme where a root key just broadcasts a replaceable, NIP-03 timestamped event that declares "these are the pubkeys I use for routine event broadcasting along with all the old ones and when they were revoked, consider messages signed by them as if they were signed by me".

These listed keys have the same privilege and authority as the root key with the sole exception that only root keys can sign the attestation event. If a listed key is also the root of another attestation event with its own listed keys, clients must ignore the attestation. The top of the hierarchy prevails.

Each listed pubkey must include:

• pubkey
• signature proving the root key holder controls the corresponding private key
• revoked timestamp, if applicable

When these keys broadcast any event, the root's pubkey should be in the pubkey field of the event, the signer's pubkey should be included in a new field, and clients should use the attestation event above to validate accordingly. This NIP would not impose any requirements on relays.

For DMs, it may make sense to be able to declare a single one of the current listed keys suitable for DMs. Clients can choose to store old DMs to maintain history.

It would require clients to build in support, otherwise any user adopting this scheme would be broadcasting events that couldn't be verified. But it doesn't require changing the ID format. Doesn't require generating a new root key pair and thus cause people to lose their "identity". The existing network protocol continues to work.

Originally posted as a comment under https://github.com/nostr-protocol/nostr/issues/45, moved over here to focus comments on this particular draft proposal.

Start by reading the linked NIP-03 and NIP-26 specifications and the prior issue discussion. Define the attestation event, listed-key fields, signing fields, revocation handling, and client verification behavior; done requires an agreed protocol proposal that clients can implement.