You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug] An asymmetric key_id has no defined binding to an identity, no publication, and no revocation #460
For the ACS-Crypto algorithms, §10 of the Instrument specification says key_id "identifies the public key or hybrid key descriptor". Nothing says how a verifier resolves a key_id to a public key, which party (Guardian or Observed Agent) owns that key, or how a key is retired after a leak. §10 leaves key distribution out of band, and issue #11 covers the same question for the HMAC baseline only.
Without those three things, a third party holding a signed decision cannot tell whether it came from the Guardian, from the agent, or from a key that was revoked before the signature was made. That is the property ACS-Crypto exists to add over HMAC (§8.6).
Expected: the spec names how an asymmetric key_id resolves (for example a key set the deployment publishes at a declared location), binds each key to the Guardian or Observed Agent identity, and says how a verifier learns that a key was revoked and from when.
Found by the premortem on the ACS mapping against AARM (issue #213). AARM R5 requires receipt signatures verifiable offline with the public keys available.
Merge note: this adds to the v0.1.0 wire, so the PR waits on the 0.x version rule (issue #32, item 5) to settle whether it ships in a 0.1.x release or under a v0.2.0 spec $id.
Activity
rocklambros commentedon Nov 1, 2026
Merge note: this adds to the v0.1.0 wire, so the PR waits on the 0.x version rule (issue #32, item 5) to settle whether it ships in a 0.1.x release or under a v0.2.0 spec
$id.