Raw RSA keyring public/private key inputs and validation

[mattsb42-aws]

There are a few points that we need to clarify regarding the raw RSA keyring inputs:

• It MUST accept a public key without a private key.
  • In this case the keyring MUST do nothing on decrypt.
• It MUST accept a private key without a public key.
  • In this case the keyring MUST cause encryption to stop.
• It MUST accept both a private key and a public key.
  • Now captured in #167 ~In this case the keyring SHOULD check to make sure that they are part of the same pair.~
  • ~If the keyring does this check and finds that they are not, it MUST cause initialization to stop.~

[juneb]

Same meaning. Slightly different words:

• It MUST accept both a private key and a public key.
  • In this case, the keyring SHOULD verify that the keys are in same key pair.
  • If the keyring determines that the keys are not in the same key pair, it MUST throw an error that stops execution.

[robin-aws]

Either "halting error" or "stops execution" sounds too severe for me. That seems to imply stopping the whole executing process (e.g. a Java System.exit()) which would be an overreaction.

It should be more than enough to just fail to construct the keyring. That will be easy to specify in the documentation for a particular language, but I'm not sure how to word it in the specification. To date we just state requirements directly, such as "If the list of children keyrings is empty, a generator keyring MUST be defined for the keyring" for a multi-keyring. Maybe we should state this in a similar way.

[seebees]

The JS ESDK does not do nothing. If it does not have a public key, it will throw on encrypt.

[mattsb42-aws]

Agreed; failing on encrypt if the public key is not available is the correct thing to do. I've updated the description to correct that.

[seebees]

Hum, even on decrypt it should throw. If it does not, then the customer could get a strange error, because the material will not have a plaintext data key, but it will not know why.

This is similar to #40 i.e. if wrapped in a multi keyring (or even on its own) this error is not helpful and far from the source :(

[MatthewBennington]

	Encrypt	Decrypt
No Private Key	attempt	~no-op?~ fail
No Public Key	fail	attempt

Need to determine exactly what the behavior in the "no private key - decrypt" case should be. We should aim for consistency among the keyrings, so this should depend on the outcome of #40.

[mattsb42-aws]

IMO the behavior should be symmetrical. If we do not want to decrypt if we do not have an explicit public key, we should fail, not no-op.

[MatthewBennington]

I assume you mean private key?

I think I agree with that statement. However, it is in conflict with the current Keyring Interface specification.

If the keyring did not attempt [to decrypt a datakey], the keyring MUST output the decryption materials unmodified.

[MatthewBennington]

Synced offline: that element of the keyring-interface is going to be changed soon. Failure makes the most sense.