amzn / nimbus-jose-jwt_aws-kms-extension Goto Github PK

Current this lib only supports symmetric KMS encryption keys (for JWE encryption and decryption operations). Under this issue we'll add support for asymmetric KMS encryption keys (for JWE encryption and decryption operations).

Great work introducing this package, thanks for making it available, looking forward to contributing to it!

We're running into an issue where third-party receivers are unable to verify the JWTs produced through the use of this extension due to it requiring the use of KMS algorithm name strings in https://github.com/amzn/nimbus-jose-jwt_aws-kms-extension/blob/main/nimbus-jose-jwt_aws-kms-extension/src/main/java/com/nimbusds/jose/aws/kms/crypto/impl/KmsAsymmetricSigningCryptoProvider.java#L89-L95

This results in a JWT header that looks like:

{
  "kid": "arn:aws:kms:us-west-2:975050201494:key/42487782-1f85-46fb-83a4-0a89c38df041",
  "typ": "JWT",
  "alg": "ECDSA_SHA_384"
}

Downstream verifiers fail because they don't recognize the alg value; they're expecting the JWS algorithm names defined in the JWS RFC spec (https://datatracker.ietf.org/doc/html/rfc7518#section-3.1).

Is there any requirement blocking an update that would enable the implementation from accepting a spec-compliant algorithm and translating that internally to KMS?

Currently KmsSymmetricEncrypter class generates a new CEK (Content Encryption Key, as know as data-key in KMS's context) for every ecnryption operation. Similarly the KmsSymmetricDecrypter class always calls KMS to decrypt a CEK for decryption operation. We can cache the CEKs in both operation (for a small amount of time, like few minutes or few hours) to reduce the number of API calls to KMS for these operations.