The DID PLC method facilitates lifecycles for rotation keys and verification keys, but it doesn't dictate or advise how the owner of a DID should manage those keys, how they can use its key rotation when they're needed (eg. during disaster recovery), or how to handle re-signing.
This makes sense, it's not the responsibility of a protocol to dictate how a user manages their keys, but there appears to be practically no existing material on this topic beyond a couple of "web5" fluff pieces, and due to the lack of existing DID PLC tooling there also isn't prior art. Certainly nothing from Bluesky or FAIR.
This presents an opportunity to document best practices for managing the lifecycle of PLC DID keys, including steps needed to rotate a verification key, recover from verification key compromise, re-sign packages, remove trust from a signed package, or deal with the worst case scenario of rotation key compromise.
Example Scenario
A verification private key gets compromised and is used to sign a malicious release which makes its way into the official DID metadata. This could happen via a CI/CD compromise, for example a GitHub Actions workflow run where the workflow has access to the key and permission to commit back to the associated repo, create a tag, publish a release, trigger a deployment, or whatever is needed to deploy a release.
The owner (who has access to a rotation key) needs to be able to effectively deal with this compromised verification key and any associated malicious release(s).
fair-tools should provide:
TUF
Among other things, The Update Framework documents its security design principles including mitigating key risk via compromise resilience. Other aspects such as trust and integrity remain the responsibility of DID PLC and the FAIR protocol. We're primarily interested in key management, related processes, and its effects.
Notes
Differences between signing a new package and re-signing existing packages:
- Signing a new package requires that the user locally provides the package file so fair-tools can safely determine its sha256 hash without having to otherwise verify a package retrieved over HTTP from the corresponding package URL.
- Re-signing existing packages has no such constraint. The expected sha256 for each is known, and each package can be fetched over HTTP and its sha256 hash verified prior to re-signing.
The DID PLC method facilitates lifecycles for rotation keys and verification keys, but it doesn't dictate or advise how the owner of a DID should manage those keys, how they can use its key rotation when they're needed (eg. during disaster recovery), or how to handle re-signing.
This makes sense, it's not the responsibility of a protocol to dictate how a user manages their keys, but there appears to be practically no existing material on this topic beyond a couple of "web5" fluff pieces, and due to the lack of existing DID PLC tooling there also isn't prior art. Certainly nothing from Bluesky or FAIR.
This presents an opportunity to document best practices for managing the lifecycle of PLC DID keys, including steps needed to rotate a verification key, recover from verification key compromise, re-sign packages, remove trust from a signed package, or deal with the worst case scenario of rotation key compromise.
Example Scenario
A verification private key gets compromised and is used to sign a malicious release which makes its way into the official DID metadata. This could happen via a CI/CD compromise, for example a GitHub Actions workflow run where the workflow has access to the key and permission to commit back to the associated repo, create a tag, publish a release, trigger a deployment, or whatever is needed to deploy a release.
The owner (who has access to a rotation key) needs to be able to effectively deal with this compromised verification key and any associated malicious release(s).
fair-tools should provide:
- Not actually very useful on its own, because revoking a verification key invalidates all packages that have been signed with it.
- Useful prior to a verification key being rotated out as a cautionary measure
- Useful in order to invalidate a maliciously signed package and re-sign legitimate packages in one go. Prevents invalidation of prior legitimate packages.
TUF
Among other things, The Update Framework documents its security design principles including mitigating key risk via compromise resilience. Other aspects such as trust and integrity remain the responsibility of DID PLC and the FAIR protocol. We're primarily interested in key management, related processes, and its effects.
Notes
Differences between signing a new package and re-signing existing packages: