revocation race conditions?

[zippy]

We need to make sure that there are no DHT "race coniditions" during the revocation process:

i.e. after a node issues a put of the new key, how does it handle verification of that put, i.e. which nodeID does all that come to. And, we need to make sure that any transactions in progress in queues or other threads can be completed (or not) as the revocation happens

[christopherreay]

how is the authority to revoke the key fundamentally implemented? is it with some other, never used revocation key? or by hash address of the current key holder?

what's the worst case, if the keypair is compromised, And the source chain is stolen, what is there to prevent another agent presenting as Dopey over here?

[artbrock]

If you have not registered a different revocation method, then you only have the out-of-box method (which is use the current key to sign a new key to your source chain), so you're just out of luck. Like if someone has stolen your bitcoin keys. They can spend them -- period.

However, if you have registered a DPKI linked identity, then your key revocation method check changes to the default method of that DPKI key, and you have to call the DPKI methods to approve the revocation payload. This means you have access to any methods provided by DPKI (like a rev key, rev authority, multi-sig rev, etc.). So if Grumpy steals Dopey's key and source chain, Dopey can revoke the key Grumpy is using via his DPKI methods, and place a new key on his source chain (assuming Dopey still has a copy of his own stuff as well).

[artbrock]

Regarding race conditions... Old keys remain valid for the local/sourcechain timestamp time-window from the time that key was made till the time it was revoked. We have to have our signature verification logic know which key to use for verifying sigs that are syncing up later.

And in answer to a different question, I heard Eric ask. You have to sign the NEW ID entry to your chain using the OLD key, because the NEW key doesn't take effect until it has been signed into the source chain.

[christopherreay]

So why dont we create a separate, one use only keyPair to be used for updating the IDEntry with new "working" keyPairs. And the IDEntry then becomes a hashSequence of keyPairs?

[artbrock]

I don't understand what you're suggesting. That we manage another set of single-use keys how?

Also, every header for an entry points not only to the previous header, but also the previous entry of that same type. That means we have sub-chains within the source chain if we follow the previous-entry-type links. So we already have a hashSequence of all the ID entries by following that. Those entries contain the keys. If you grab that thread of entries and read it starting from the ID genesis entry (#2) forward in time to the present, it is easy to validate that each new key entry is signed by the old key AND uses whatever revocation method the linked DPKI account uses (ideally linked sooner rather than later, like in ID genesis entry).

What do we get by introducing more key pairs than the ones already managed on this source chain and the ones which control DPKI?

[christopherreay]

We dont get anything from adding stuff if the DPKI is included, there is no issue, since there is "another" set of keys on the DPKI

If we are talking about implementing keyPair revocation solely on a single Holochain, without any external service, then issuing a one use only keyPair for revocation at the point of adding any particular "working" keyPair seems doable.

The reason to have an IDEntry out on the DHT, which has links to the sequence of "working" keyPairs, is exactly because whatever workingKeyPair has been compromised indicates the utility of having an immutable point of reference, i.e. the hash of the IDEntry, to serve as a point from which to get the new address of the Agent, as well as to determine if the keyPair we are using to address them is currently "working"

[christopherreay]

Again there are loads of reasons when addressing this stuff to allow for the hash of an Entry to be a hash of a subset of the fields of that entry, instead of arbitrarily forcing it to be the has of all the fields.