Rotation doesn’t need exact dates. Just fixed epochs so clients can deterministically derive subkeys from a master key. Yearly is clean enough.
At that point rotation is a UX decision more than a cryptographic one.
Rotation doesn’t need exact dates. Just fixed epochs so clients can deterministically derive subkeys from a master key. Yearly is clean enough.
At that point rotation is a UX decision more than a cryptographic one.
clean compromise. yearly epoch feels human-scale, no calendar nitpicks needed. popping a toast that goes “yo, tomorrow’s new-key day,tap to migrate, or ride the old one another year” should be enough.
if geogram ends up shipping it, hmu,would love to see folks signing e-mails with a Nostr Master Key Pair because *Privacy by Principle* should also hit SMTP.
Will save this conversation and then ping here when is time to test it.
Don't think anyone here has implemented yet a nostr master key system as reference to learn from them, so will see how an implementation can look like. At least a nostr key rotating a PGP key seems fairly straightforward.
You can build a signing chain, but it collapses the separation. If the nsec signs each new PGP key, the Nostr key becomes a permanent root authority and a single compromise breaks the entire lifecycle. The whole point of coordinating two systems is to avoid that failure mode.
With deterministic epochs, clients can verify rotation without deputizing nsec as a god key.
Once you have a stable root, rotation is just schedule + client support. Everything else is implementation detail.
yea dead on,don’t want that “god key” trap.
keep the nsec as blind entropy source, let deterministic schedule + clients handle the rest.
when you’ve got a proto ready i’ll eagerly whack it with Vector (DM me over NIP-17 if ya like) to see how it feels.