Support JWE generation and validation

[gilgameshoo]

Problem:

Currently the aws-lc-rs only supports JWS generation and validation, not JWE. While the openssl supports both, it would be nice to have that implementation for the aws-lc as well.

Solution:

I found that the aes-gcm algorithm is already exposed in aws-lc-rs source code, so I'm working on implementing the JWE encrypt/decrypt function based on that.

• Does this change any public APIs? If yes, explain.
• Which algorithm(s) will this impact?

Requirements / Acceptance Criteria:

What must a solution address in order to solve the problem? How do we know the solution is complete?

• RFC links: Links to relevant RFC(s)
• Related Issues: Link any relevant issues
• Will the Usage Guide or other documentation need to be updated?
• Testing: How will this change be tested? Call out new integration tests, functional tests, or particularly
  interesting/important unit tests.

Out of scope:

Is there anything the solution will intentionally NOT address?

[justsmth]

Hello!

I am curious about JWS, JWE, etc. (i.e., the JOSE framework). While support for JOSE's high-level operations may be out of scope for our library, I see value in ensuring that our library provides whatever cryptographic operations are required for its implementation.

You mentioned that openssl supports JWE -- can you point me to example code where it's used for this purpose? Or, if you know of specific cryptographic operations that we would need to support, please let us know! ☺️ (I'm sure there are many others who'd also like this.) Thanks!

[gilgameshoo]

Hi Justin, thank you for the response. I'm using the jsonwebtoken-aws-lc crate and comparing it against another crate based on openssl called josekit. Here is the encryption algorithm that openssl supports:

Supported encryption algorithms

Name	Description	Key Type
dir	Direct use of a shared symmetric key as the CEK	oct (size: the CEK depended. See below) A128CBC-HS256: 32 bytes A192CBC-HS384: 48 bytes A256CBC-HS512: 64 bytes A128GCM: 16 bytes A192GCM: 24 bytes A256GCM: 32 bytes
ECDH-ES	Elliptic Curve Diffie-Hellman Ephemeral Static key agreement using Concat KDF	EC (curve: P-256, P-384, P-521 or secp256k1) OKP (curve: X25519 or X448)
ECDH-ES+A128KW	ECDH-ES using Concat KDF and CEK wrapped with "A128KW"
ECDH-ES+A192KW	ECDH-ES using Concat KDF and CEK wrapped with "A192KW"
ECDH-ES+A256KW	ECDH-ES using Concat KDF and CEK wrapped with "A256KW"
A128KW	AES Key Wrap with default initial value using 128-bit key	oct (size: 16 bytes)
A192KW	AES Key Wrap with default initial value using 192-bit key	oct (size: 24 bytes)
A256KW	AES Key Wrap with default initial value using 256-bit key	oct (size: 32 bytes)
A128GCMKW	Key wrapping with AES GCM using 128-bit key	oct (size: 16 bytes)
A192GCMKW	Key wrapping with AES GCM using 192-bit key	oct (size: 24 bytes)
A256GCMKW	Key wrapping with AES GCM using 256-bit key	oct (size: 32 bytes)
PBES2-HS256+A128KW	PBES2 with HMAC SHA-256 and "A128KW" wrapping	oct (size: 1 bytes or more)
PBES2-HS384+A192KW	PBES2 with HMAC SHA-384 and "A192KW" wrapping
PBES2-HS512+A256KW	PBES2 with HMAC SHA-512 and "A256KW" wrapping
RSA1_5	RSAES-PKCS1-v1_5	RSA (size: 1024 bits or more)
RSA-OAEP	RSAES OAEP using default parameters
RSA-OAEP-256	RSAES OAEP using SHA-256 and MGF1 with SHA-256
RSA-OAEP-384	RSAES OAEP using SHA-384 and MGF1 with SHA-384
RSA-OAEP-512	RSAES OAEP using SHA-512 and MGF1 with SHA-512

I'm implementing the AES-GCM right now and looking into the aws-lc-rs source code, it only has 128 and 256 right now, where the 192 is missing. I haven't gone through all these algorithms but will do it after finishing the AES-GCM code. Please let me know if you have any thoughts on this since you are more familiar with the aws-lc source code.