Repository navigation
Implement cryptolink revocations in the sigchain #189
Description
Activity
Backchannel system has a section on linking and unlinking: https://www.inkandswitch.com/backchannel/#linking-multiple-devices
Their linking makes use of a shared secret. Not really relevant to us, except for when we generate QR codes, or other ways to allow users to establish a secure connection.
But the unlinking idea is interesting and should be considered for this feature.
Should also investigate how CRLs work, and how to ensure this is efficient and scalable (consider algorithmic/network complexity).
Recall our current node to node claim signing process, where we perform a cooperative signing process between both nodes, passing two claims back and forth between the nodes such that they both end up with their own node to node claim on their corresponding sigchains.
I imagine we'll also need a similar process to revoke these node claims.
However, just throwing this out there too, we'll also need to consider the case where a node is potentially compromised. In this case, they're unlikely to cooperate in the revocation process.
When we start to look into this, it would also be worthwhile to consider improving the field names on our claims. Currently, we have the data in a node claim set according to the following type:
type ClaimData = ClaimLinkNode | ClaimLinkIdentity; type ClaimLinkNode = { type: 'node'; node1: NodeIdEncoded; node2: NodeIdEncoded; }; // where it appears in the claim as ClaimData: type Claim = { payload: { hPrev: string | null; // Hash of the previous claim (null if first claim) seq: number; // Sequence number of the claim data: ClaimData; // Our custom payload data iat: number; // Timestamp (initialised at JWS field) }; signatures: Record<NodeIdEncoded, SignatureData>; // Signee node ID -> claim signature };
Specifically, the fields
node1andnode2should be improved to be less ambiguous (i.e. doesnode1refer to the node on which this claim appears?).This was initially brought up here in the review of #320 (comment)
@amydevs PKE private orgs are going the need to boot of nodes and revoking gestalt links.
@tegefaulkes since this network segregation is now assigned to you, i'll assign this to u too
Currently, all cryptolinks in the sigchain are considered as additions to the sigchain. That is, there's no notion of revocation. As such,
getAllCryptolinks()simply retrieves all claims from the sigchain that have aclaimTypeof 'cryptolink'.To introduce revocations, we'll need to restructure the
CryptolinkClaimDatatype a bit to include a flag or different type that signals the cryptolink is being revoked, instead of being added. Once this is introduced, we'll need to altergetAllCryptolinks()to only include the cryptolinks that have not been revoked (i.e. start from the most recent link in the chain).A better solution would be to persist a map of
LinkId(or whatever the unique identifier of a cryptolink is) to the sequence number of theClaimin the sigchain. If a cryptolink is revoked, we would simply remove its entry in this map. Thus, togetAllCryptolinks(), we would simply get all the sequence numbers from this map, and return an array ofClaimsfrom these sequence numbers.