Specification
The root certificate of nodes and by extension their root key pair and NodeID is allowed to change. There are 3 methods in the KeyManager that does this;
renewRootKeyPair, Generates a new root keyPair, adds it to the cert chain and is signed by the previous certificate. This creates a new NodeId ensures that the old NodeId is still valid.
resetRootKeyPair, Throws out the old cert chain and generates a new on from scratch. The new cert is self signed. This is a new NodeId and the old one is now Invalid.
resetRootCert. This keeps the old root keypair but generates the cert chain from scratch. This means the NodeId remains the same but the cert chain is a new one from scratch.
What we want to handle is if a nodes starts using a new NodeId but it's old NodeId remains valid within it's cert chain. When dealing with these nodes we need to treat it as the valid old NodeId while updating any information we have about it to use it's new NodeId.
This means we will have to check the full cert chain when connecting to a node. Determine if the NodeId we're expecting is an older node in the cert chain. If it is older we need to obtain the new NodeId of the node and start using that.
The following domains need to be updated to handle the NodeId of a remote node changing.
sigchain This stores any claims between nodes. I think a new claim would need to be generated and reference the old one. but this wlll need to be looked into.
GestaltGraph This keeps track of nodes within their gestalts. If a node's ID changes then it needs to be updated here.
ACL stores permissions allowed for each node. If a node's ID changes then it needs to be updated here.
NodeGraph, I think that the new node will be added to the NodeGraph automatically through the usual operation. We may need to remove the old NodeId from the graph. Since the node can be contacted via all it's NodeIds in the cert chain it's possible for a node to exist in the graph as multiple NodeIds. So we only want to keep the newest NodeId for the node.
It's also possible that when a node's ID changes it's old NodeId and information will slowly exit the network as it is replaced with the new NodeId. As a result the node will become un-discoverable with the old ID though it may be unlikely. We may need a way to discover a node ID via it's old nodeId by having nodes keep information about the ID change when we update our information on it. That way we can inform other nodes about the change when they come looking for it.
Additional context
Tasks
- Add a way to detect when a nodes root certificate, key and ID has changed when we connect to it.
- Update any information about the node when we detect the change. These changes will need to be applied to the following domains.
SigChain
GestaltGraph
ACL
NodeGraph
- Add ability to make note of the change to inform other nodes of the change.
Specification
The root certificate of nodes and by extension their root key pair and
NodeIDis allowed to change. There are 3 methods in theKeyManagerthat does this;renewRootKeyPair, Generates a new root keyPair, adds it to the cert chain and is signed by the previous certificate. This creates a newNodeIdensures that the oldNodeIdis still valid.resetRootKeyPair, Throws out the old cert chain and generates a new on from scratch. The new cert is self signed. This is a newNodeIdand the old one is now Invalid.resetRootCert. This keeps the old root keypair but generates the cert chain from scratch. This means theNodeIdremains the same but the cert chain is a new one from scratch.What we want to handle is if a nodes starts using a new
NodeIdbut it's oldNodeIdremains valid within it's cert chain. When dealing with these nodes we need to treat it as the valid oldNodeIdwhile updating any information we have about it to use it's newNodeId.This means we will have to check the full cert chain when connecting to a node. Determine if the
NodeIdwe're expecting is an older node in the cert chain. If it is older we need to obtain the newNodeIdof the node and start using that.The following domains need to be updated to handle the
NodeIdof a remote node changing.sigchainThis stores any claims between nodes. I think a new claim would need to be generated and reference the old one. but this wlll need to be looked into.GestaltGraphThis keeps track of nodes within their gestalts. If a node's ID changes then it needs to be updated here.ACLstores permissions allowed for each node. If a node's ID changes then it needs to be updated here.NodeGraph, I think that the new node will be added to the NodeGraph automatically through the usual operation. We may need to remove the old NodeId from the graph. Since the node can be contacted via all it's NodeIds in the cert chain it's possible for a node to exist in the graph as multipleNodeIds. So we only want to keep the newestNodeIdfor the node.It's also possible that when a node's ID changes it's old
NodeIdand information will slowly exit the network as it is replaced with the newNodeId. As a result the node will become un-discoverable with the old ID though it may be unlikely. We may need a way to discover a node ID via it's old nodeId by having nodes keep information about the ID change when we update our information on it. That way we can inform other nodes about the change when they come looking for it.Additional context
NodeIdchangestests/bin/keys/reset.test.tsandtests/bin/keys/renew.test.tsstopping the PolykeyAgent #347 - never figured out the core problem for test failures during key renewalTasks
SigChainGestaltGraphACLNodeGraph