HD keys have been discussed many times. I'd personally rather see a solution to key rotation, because HD keys only improve key security for people who keep their root key safe, which is not going to be most users. Key rotation on the other hand is only slightly more complex in terms of client implementation (although the rotation protocol would be tricky), and would allow users to generate any number of keys on an ad-hoc basis.

Reply to this note

Please Login to reply.

Discussion

I think it can be key rotation along with hierarchical keys. With key rotation you still need ‘witnesses’, so then you are relying on someone else’s private key.

Yes, or open timestamp attestations

Yup. I am also going to look into nostr:npub1cn670f663n3ks02jnnlsvd5y88zjnefy8343ykaxs7y3nzzketrsrjwt8a's attestation NIP to see if it will do the job as well.

Would help with social recovery I think.

We need a key rotation event published by the key looser with the new npub that can be attested too by others after out-of-band verification.

Yeah, we could do that for the root key and social recovery for the exceptional circumstance of losing that. The key rotation I am proposing is more for mundane operational stuff.

I am trying to cherry-pick the best of this spec which underpins the legal entity identifier.

https://trustoverip.github.io/kswg-keri-specification/versions/v1/

At least it would give me a nsec I can plug into all those insecure nostr apps, which then could figure out that it was actually me, without me giving away my Crown Jewels.

Alternatively, if I forget the nsec for some random app, I can derive the private key to get back in.