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>
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