[5.27.1] - 2026-09-08
๐ Bug Fixes
AWS XKS Authorization (#1107)
- Key usage no longer restricted to the creator principal (#1093): the XKS proxy previously authorized each
Encrypt/Decrypt/GetKeyMetadatarequest using the caller'sawsPrincipalArn, andCreateKeygranted usage only to the ARN that first created the key, breaking AWS's IAM-as-source-of-truth model for dynamic/numerous roles (CI/CD, Lambda, EC2, SSO/Control Tower). XKS operations now run under a stable, reserved KMS service identity (any correctly SigV4-signed request may use the key);awsPrincipalArnis retained for audit logging only. Keys stay owned bydefault_username, the reserved identity is granted onlyEncrypt/Decrypt/GetAttributes(least privilege), and legacy XKS keys are migrated to the reserved identity idempotently at server startup - Close 5 reserved-identity and scope-containment gaps found in threat-model review:
CreateKey's idempotent-collision path now also requires theaws-xkstag before granting the reserved identity; externally-derived identities (OIDC, Auth Verifier JWT, mTLS CN, SPIRE SVID, UI session) are rejected if they collide with the reserved identity string;crypto_officer.usersanddefault_usernameare rejected at startup if they collide with it; the legacy-key migration now grants on behalf of each key's actual persisted owner (not just the currentdefault_username), queries direct (non-inherited) permissions so a wildcard*grant no longer masks a missing reserved-identity grant, propagatesretrieve_objectfailures instead of silently skipping a key, and runs on a dedicated background thread so it no longer blocks HTTP server startup - Reject
ReKey(manual or via the auto-rotation scheduler) onaws-xks-tagged keys: rotating one in place would assign a new internal unique identifier that AWS KMS has no way to learn about, silently breaking the key. To rotate material behind an external key, create a new external key (CMK) in AWS KMS and destroy the old one viackms/the Web UI once traffic has moved - Warn at startup when AWS XKS is enabled and
crypto_officer.usersis empty, since AWS never calls back to list/rotate/revoke/destroy key material and a Crypto Officer must be configured for XKS keys to remain manageable throughckms/the Web UI
OCSP
GET /ocsp/{base64url-DER}now accepts both padded and unpadded base64url input (RFC 6960 Appendix A does not mandate padding); previously well-formed requests from clients such asopenssl ocspwere rejected with a spurious 422
๐งช Testing
- Add an AWS XKS CI test running against a remote server (#1114), covering that the real-credentialed key owner can monitor/administer XKS keys end to end, that the reserved service identity stays unreachable for that purpose, and that
ReKeyon anaws-xks-tagged key is rejected - Enable Proteccio and Crypt2Pay HSM backends in CI (#1175)
โ๏ธ Build
- Fix the
build/wasmMISE task failing when theui/src/wasmdirectory doesn't already exist before copying the package into it (#1174) - Bump
pnpm/action-setupfrom 6.0.10 to 6.1.0 (#1176)
๐ Documentation
- Document that lifecycle management of XKS keys (monitoring, revocation, destruction) is entirely an operator responsibility exercised by a designated Crypto Officer, and warn against ever granting the reserved AWS XKS service identity a real credential