suggestion: name revocation and name reset about stacks-blockchain

[shea256]

To clarify, in the case of a name revocation, the following things would happen:

1. the name would remain in the list of registered names and would keep it's prior expiration date
2. the data associated with the name would be zeroed out and the name would not be resolved by resolvers - it would essentially be a name in limbo
3. the name would be able to be re-registered by anyone at the end of the registration period
4. identity protocols built on top of these names could have rules in place for ignoring the identity of a revoked name (e.g. a web of trust system could have software that auto-unfollows identities with names that have been revoked)

(these rules can be played with - this is just what I came up with that should work reasonably well)

[taoeffect]

It's awesome that you're thinking about this.

recommend the following: if a private key owner is compromised but the name hasn't yet been stolen, transfer the name to a new private key owner

Could you elaborate on that?

What happens if someone steals a name (i.e. gets the private key, updates the entry with bad data) and the revocation transaction is then broadcasted? Will it be respected still? (Seems like it should?)

[shea256]

In this case, the name's data would be zeroed out and the resolution of the name would be blocked until the expiration date. That's the idea behind the revokation.

[taoeffect]

Ah I see. Just gave this idea a mention in this blog post. Great idea! 👍

[taoeffect]

@shea256 Thinking about this some more, it may not be necessary for name owners to lose their name if they are able to successfully revoke the key pair. Is Blockstore capable of separating the names from the keys? In other words, would it be possible for them to use the revocation message to re-associate a new key pair?

[shea256]

Traditionally with cryptographic identity systems, revocation messages signed by the master key would have one purpose and one purpose only - to revoke the master key.

This allows you to do really interesting things to maintain security without trusting anyone. For example, you can store a copy of your revocation message under your bed, but you can also give a revocation message to a third party that you (a) trust enough not to publicly make a nuisance of revoking your keys but (b) don't fully trust enough to not impersonate you.

If you allow the revocation message to re-associate the keypair, or pull the name away from the master, it is now effectively as powerful the master key (and hence in essence a master key). This is very bad.

I've been trying to think about whether it's possible to pre-define an "escape" or "destination" backup address, so that instead of a revocation message, one could sign a transfer message. However, I don't think this is possible. The reason is, if there is in fact a backup key that you could transfer the message to in case of a breach, then the assumption is that the backup key wasn't compromised but the original master was. But why? If it's the case that it is more securely stored, perhaps in long-term storage, then why wasn't the backup key the master in the first place? And if it's stored with a third party, then it isn't secure since the third party can now execute the transfer and impersonate the user.

The idea behind a revocation message is it's a last resort. Ideally, you'd have your username owned by a master key in a multisig address or an address with a private key that has been sharded with shamir's secret sharing or even threshold signatures. But... if that somehow fails miserably, then it's imperative that you have an escape route to prevent someone from using your key, and a bit of a luxury at this point to get your name back.

And with the case of key loss, a transfer message doesn't make sense because if you can backup a transfer message somewhere, then you could have just backed up the key itself.

I think we should stick with the traditional model, which is a master that can create any number of child keys, and a revocation message that is signed by the master and that can only revoke the master. Quite simple and battle-tested.

[shea256]

Also think about this - in the revocation message system, if someone steals your key, they can sign any number of revocation messages and it won't impact your revocation message. You care about broadcasting the revocation. The thief doesn't. Thus this is a case where you have ultimate power over the thief.

In the transfer message system, if someone steals your key, they can sign a transfer message and broadcast it instead of your pre-signed transfer message. This would screw with your ability to recover the name. And since the thief has advanced knowledge of the theft, in this case the thief has ultimate power over you.

[taoeffect]

OK, fair enough. I was thinking that losing a key and having it compromised are two different situations and therefore perhaps different precautions could be taken.

But, I am realized that if you had your key stolen and then someone used it to transfer ownership of your name to some other key, then the ability to override that would actually allow others to con people (i.e. you pay me $ for a name, I transfer it to you, but then have the ability to undo that transfer).

So, I guess you're right, mutually assured destruction seems to be the best option in this situation. :P

[jcnelson]

Closing this as stale. I think this issue belongs in blockstack.js or some other tool library, since it can be implemented by cleverly-constructed Bitcoin scripts without affecting Blockstack Core.