Repository navigation
fix(kas): accept spec-compliant policy bindings - #4223
Conversation
The spec defines the policy binding as Base64(HMAC), but no released KAS can decode that form. #2095 added a dual-accept branch and it has never worked: base64.DecodedLen over-allocates, so a 44-character binding decodes 32 bytes into a 33-byte buffer. Only the hex branch replaced that buffer with a right-sized slice; the raw branch passed the untrimmed 33 bytes to VerifyBinding, which compares with hmac.Equal -- length sensitive, so it always failed. Extract decodePolicyBinding, trimmed to the bytes actually decoded, and use it on the rewrap path. Legacy hex stays accepted indefinitely; TDFs are archival. This only widens what KAS accepts and changes no output, so it is safe to deploy on its own. It is a prerequisite for fixing the SDK writer, which is deliberately left for a follow-up: nothing may emit raw bindings until a KAS that can read them is deployed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Paul Flynn <pflynn-virtru@users.noreply.github.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Merge Risk: ⚪ Minimal · up to
|
d73c7fa to
cae7caa
Compare
Benchmark results, click to expandBulk Benchmark Results
TDF3 Benchmark Results
|
Benchmark results, click to expandBulk Benchmark Results
TDF3 Benchmark Results
|
|
The point is to show that a real KAS -- the current release and main -- rejects an on-spec policy binding. A force-only gate skipped exactly those cells, so drop it. The test fails until a platform carrying opentdf/platform#4223 is under test. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Signed-off-by: Paul Flynn <pflynn-virtru@users.noreply.github.com>
KAS must accept a policy binding in the spec's Base64(HMAC) form as well as the legacy Base64(hex(HMAC)) every SDK writes. No released KAS did (opentdf/platform#2095 compared an untrimmed buffer); fixed in opentdf/platform#4223. test_tdf_with_spec_policy_binding re-encodes the binding to the spec form, which needs no key, and expects decrypt to succeed. It is gated on the new platform-only feature spec_policy_binding, force-only until a release carries the fix. test_tdf_with_altered_spec_policy_binding expects a well-formed spec binding with a wrong HMAC to be rejected, so the new path cannot fail open. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Signed-off-by: Paul Flynn <pflynn-virtru@users.noreply.github.com>
The point is to show that a real KAS -- the current release and main -- rejects an on-spec policy binding. A force-only gate skipped exactly those cells, so drop it. The test fails until a platform carrying opentdf/platform#4223 is under test. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Signed-off-by: Paul Flynn <pflynn-virtru@users.noreply.github.com>
KAS now accepts both
Base64(HMAC)(spec) and legacyBase64(hex(HMAC)). Service-only; no output changes.Fixes the raw-binding path broken since #2095, which compared an untrimmed 33-byte buffer against the 32-byte HMAC, so no released KAS accepted the spec form.
🤖 Generated with Claude Code
Summary by CodeRabbit