KMS Keyring should fail initialization if any keyId is malformed

[WesleyRosenblum]

Upon KMS initialization, if any key ID (either the generator or any of the input Key Ids,) is malformed, initialization should fail, so that the user is immediately aware they are handling malformed data.

[WesleyRosenblum]

The Java ESDK does this currently by using the AwsKmsCmkId type as input, which only allows well formed ARNs (if an ARN is being used, and not a raw Key ID or Alias)

[lavaleri]

Resolving this issue means clarifying exactly what our verification for key IDs should look like, for each type of key that the ESDK MUST or MAY support.

[acioc]

Upon discussion, we have decided that we MUST accept all key identifiers supported by AWS KMS. We will not perform validation on these, and will pass the strings directly to AWS KMS. The reason for this is because we need to support Key IDs. Key IDs are currently in UUID format, but (based on public documentation) there is no guarantee this will always be the case - public documentation states the only restriction is that a Key ID must be a string between length 1 and 2048 (I believe).

Therefore, it makes sense to treat key identifiers as strings as pass them as-is.

[WesleyRosenblum]

I think it's still useful to wrap the string in something to identify it as a AWS KMS CMK Identifier, in case we want to add some validation in the future.

Are we OK with the current validation the Java ESDK does? Basically the input is only validated if it starts with the prefix "arn:". The reason for validation is that the Java ESDK uses the AWS SDK's Arn.fromString method to convert a string to an Arn to extract the Region ID. This method requires a valid Arn. See https://github.com/aws/aws-encryption-sdk-java/blob/keyring/src/main/java/com/amazonaws/encryptionsdk/kms/AwsKmsCmkId.java#L35

[acioc]

We need to additionally support Key Ids and unqualified aliases, so we can't guarantee we exclusively have ARNs.

I created a PR replacing most of our current description of what we support with a link to AWS KMS docs: #123

We should support whatever AWS KMS supports and just pass through the string to AWS KMS, so they do the validation they need. This also means our ESDK is viable long-term (if their format ever changes, we don't need to specifically update the ESDK to support it, since it's just a pass through).

Quick edit: You can totally use Arn.fromString to determine region, for example. But we can't guarantee all strings we get are ARNs. Rather "if it's an ARN, we can extract the region, so we can do this" but if it's not an ARN, just pass it along since any string is valid (between a length of 1 and 2048).

[acioc]

PR merged. Tracking implementation in #129