[keyring] simplify raw AES keyring API

[mattsb42-aws]

As I was discussing the raw AES keyring API with @juneb, it occurred to both of us that requiring the caller to specify the wrapping algorithm does not really add value here, because the only thing that changes is the key size, which we can infer from the wrapping key material.

I think that requiring the wrapping algorithm is a hold-over from RawMasterKey, but one of the main reasons why the wrapping algorithm was needed to AES operations for that was to provide a consistent configuration experience for AES and RSA wrapping keys. Since we have split these out into separate keyrings, I do not think this really adds value anymore.

An argument could be made that specifying the wrapping algorithm adds value because it requires the caller to explicitly state what AES key size they intend to provide, which we can check against the key material that they actually provided. While technically correct, I'm not sure that this justifies the additional API complexity.

The other extant implementations vary on how they present this:

The specification only requires the key material:

https://github.com/awslabs/aws-encryption-sdk-specification/blob/master/framework/raw-aes-keyring.md#initialization

C requires a separate statement of the expected key length:

https://github.com/aws/aws-encryption-sdk-c/blob/749c84feddce147fb62e2ece7de34d733ef165c2/include/aws/cryptosdk/raw_aes_keyring.h#L57-L62

Java only requires the key material:

https://github.com/aws/aws-encryption-sdk-java/blob/5cf7e0c0638eaa6752e94b6b0da9c67a29001c9e/src/main/java/com/amazonaws/encryptionsdk/keyrings/RawAesKeyring.java#L30-L32

Javascript requires a wrapping algorithm suite:

https://github.com/aws/aws-encryption-sdk-javascript/blob/201c1022257a08c82035e5cde5097fad8321f64d/modules/raw-aes-keyring-node/src/raw_aes_keyring_node.ts#L51-L56

Option 1: Leave as-is

If we do this, we should change the validator for the wrapping algorithm suite to not allow RSA suites.

Option 2: Derive the wrapping algorithm suite from the wrapping key material

Given that the only thing that changes between the AES wrapping algorithm suites is the key size, we can enforce that the key material is a supported length and derive the wrapping suite from the key material length.

Option 3: Make the wrapping algorithm suite optional

We could make the wrapping algorithm suite optional, enforcing it if the caller provides it, but otherwise deriving it from the wrapping key material.

[WesleyRosenblum]

I prefer Option 2, keeping the API as simple as possible.

[juneb]

I like option 3. Make the right choice for the customer by default, but allow them to make a different choice for special use cases.

I'm assuming here that there is more than one workable choice for each instance of RSA key material.

[mattsb42-aws]

For the raw RSA keyring, we cannot derive the correct wrapping suite. The caller will still need to specify that.

This is only for the raw AES keyring, where the only thing that can differ is the wrapping key size and for any given wrapping key material there is at most one valid wrapping suite.

[WesleyRosenblum]

So Option 3 would mean the optional algorithm suite enables a kind of extra sanity/validation check? In my opinion that would be more confusing for the user

[mattsb42-aws]

So Option 3 would mean the optional algorithm suite enables a kind of extra sanity/validation check? In my opinion that would be more confusing for the user

Correct and agreed.

Personally, I also like option 2 the best.

[juneb]

If there's no use-case for option 3, then option 2 is fine. I prefer both to option 1.