DRAFT - NIP-XX Revocation of compromised identity

[ronaldstoner]

Note: This is a draft, it would need further development and review before being considered for implementation. I'm not set on if the word "REVOKED" or "COMPROMISED" or something else is best, but I'm open to suggestions.

NIP-XX Revocation of compromised identity This NIP proposes a method for domain owners to list compromised keys and identities, allowing clients to display a "REVOKED" identifier for the NIP-05 identifier.

Motivation: While NIP-05 allows for mapping Nostr keys to DNS-based internet identifiers, there is currently no way to indicate a key has been lost or compromised. This NIP aims to provide a solution for this issue, allowing domain owners to take action when a key has been compromised providing a positive verification that users should no longer trust that key.

Design & Implementation: This NIP introduces a new file, similar to .well-known, called .revoked. Domain owners will be able to create a .revoked file on their server, which will list compromised keys and identities in JSON format. The file will include a "revoked" key, with a value of an object containing a mapping of revoked identities to their corresponding pubkeys.

{
  "revoked": {
    "bob": "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9"
  }
}

When a client receives an event with an NIP-05 identifier, it will first check the .revoked file of the associated domain for that identifier. If the identifier is listed in the file, the client will display the identifier as "REVOKED" instead of the NIP-05 identifier.

Allowing access from JavaScript apps Same as NIP-05

Security Considerations Same as NIP-05

---End of NIP---

Side Thoughts

• An attacker could ultimately with a compromised key could remove the NIP-05 identifier from a user profile but compromised users still have no way to signal abandoned accounts, new accounts, or lost keys without a note from a new key and organic migration of followers. I think something like this is needed where the identity still has control over something (a domain & server).
• Would this be better as separate NIP, or an enhancement to NIP-05 since clients are already referencing the .well-known/nostr.json file?

[mikedilger]

First, I don't really want to trust DNS. But if the revoked entry was signed by the key that is being revoked, I could have confidence that either the owner of the key actually wants the revocation to happen, or someone stole his key and signed it, in which case I also want to consider the key revoked. I realize this cannot work if someone loses their private key, but in cases where it can be done it should be done.

Second, if this stays as a file on the domain (I'm not sure it should), I would just add this key to the current nostr.json file rather than making another file.

Third, I think there are other draft NIPs that might have other ideas on how to do this, or at least overlap a little bit. So go look for those PRs.

[fiatjaf]

I don't think this is a good idea because if you lose your domain the new owner can "revoke" your public key.

https://github.com/nostr-protocol/nips/pull/158 is a better solution since it provides an undeniable way to assert the revoked state of a key and immediately points to the next key your current followers should migrate to.

[Semisol]

nope, attacker could remove the NIP-05 ID preventing revocation from showing up, and domain owner could abuse this.

[ronaldstoner]

These are all great and fair points. I appreciate the brain cycles and feedback. I'm closing the issue for now as better solutions have been identified.