A very simple idea to solve the "key revocation" problem

[simonhughxyz]

I'm only just starting to get interested in nostr, but one problem that I have identified, and others have too such as #45 and #119 is the issue of what to do when your PK has been compromised. The current proposed solutions seem to revolve around having a master and sub keys or something along that nature, with the objections being that it does not follow nostr's preferred KISS nature and being to complicated to implement. The current actual solution seems to be to just tell people that it has been compromised, which has some problems such as trying to convince people that it really has been compromised.

So here is my idea: A new NIP that signals a master identity The basic user case is as follows: A person would make a identity like they currently do, nothing would change, lets call this identity ID-A. However they could now make a second identity, lets call it ID-B. The PK for the second ID-B, they would protect with much more rigor, maybe even keep it air gaped etc.

On the ID-A they would send a message following the format of a new NIP, this message would basically inform relays that ID-B should be considered a master ID for ID-A, this allows ID-B to "control" ID-A. Now this would be up to relays to implement, they choose to listen to this message or to ignore it, but i expect most relays to listen.

ID-B could then "revoke" ID-A and relays could then choose to ignore future messages from ID-A or link a new ID-C.

The benefits of such a NIP are:

• Its really simple
• the way identities are currently handled does not change
• its optional, users can choose to have master identities or not
• it can be retroactively implemented on old identities by signaling a new master identity
• one master identity could control many sub identities
• and if you wanted to a sub identity could be controlled by many master identities (good for organizations, businesses, groups etc)
• you could have other forms of control from the master ID, not just revocation
• could have id chains, maybe there is some use here

I can't see a reason why this would not work, maybe I am misunderstanding the spec here, but this seems to me to be a half-decent solution to this problem.

[wsq003]

Security of private key is really a problem.

115 is trying to solve this same problem.

Some kind of 'account recovery' is necessary. I believe this problem can not be solved within encryption algorithm, it has to link to a human identity in some way.

[simonhughxyz]

Security of private key is really a problem. #115 is trying to solve this same problem. Some kind of 'account recovery' is necessary. I believe this problem can not be solved within encryption algorithm, it has to link to a human identity in some way.

There is no reason why this human identity can not be another nostr account. This would solve the problem of having to use your PK to authenticate which is high risk (the more you use it the more likely it is to be compromised). You effectively end up having two PK's, one you declare the master and you keep air gaped/in a safe/protected by Thor himself etc the other you use to casually authenticate with. And if its compromised you can revoke it using your master key. Plus it would also allow for multiple owners of the same identity.

[fiatjaf]

This does not work because if someone steals your key they can make their own identity the "master".

[simonhughxyz]

This does not work because if someone steals your key they can make their own identity the "master".

That can be solved through time priority, i.e. the first master wins. Or you have to sign with previous masters to create a new one.

[fiatjaf]

There is no global state, trusted timestamping or consensus on Nostr. People can just backdate an event. People can create multiple events and reveal them in succession from the latest to the oldest and screw everybody else's state.

[simonhughxyz]

There is no global state, trusted timestamping or consensus on Nostr. People can just backdate an event. People can create multiple events and reveal them in succession from the latest to the oldest and screw everybody else's state.

I don't think this requires a global state, but maybe I am just misunderstanding the nostr protocol.

Here is how I understand nostr to work, correct me if I am wrong: a client can send messages and events signed with its key to relays for other clients to retrieve, and it is up to clients and relays how they interpret these messages. Now although it is up to clients and relays to decide how to interpret messages, there are a series of standards that they may accept as proposed in NIP's such as NIP-09 Event Deletion.

My proposal is really no different then using other, outside of nostr (such as a website), methods to inform people that a identity has been compromised and should no longer be trusted, and instead to trust a new identity. But instead of such a informal way, you would use another nostr identity to do it.

You are basically pre-informing people that if ID-B ever says ID-A is compromised, then to trust what ID-B says, except on a protocol level. Now relays and clients could ignore this of course, but there is no incentive to do so.