Closed
Description
We have some keyrings defined, but we can't actually use them yet.
Following on from #209, I think that trying to build an abstraction layer that lets master key providers (MKPs) pretend to be keyrings is not viable. There are just too many subtle differences in the APIs, including:
- MKPs accept the plaintext length and plaintext body as input on encrypt. Keyrings do not. We've been trying to discourage this usage for a while, but we can't just cut it off without potentially breaking custom MKPs that might use these values.
- MKPs implicitly assume that they are generating the data key. This could work out ok if you never combine the MKP keyring wrapper with any other keyrings, but if you ever do then the potential issues expand significantly.
Instead, we're just going to expand the default CMM to accept either an MKP or a keyring, and contain the complexity there.
Testing this will require:
-
DefaultCryptoMaterialsManager
MUST accept either a MKP or a keyring and require exactly one -
DefaultCryptoMaterialsManager
MUST fail if the keyring could not complete the cryptographic materials -
DefaultCryptoMaterialsManager
MUST fail if the keyring changes the algorithm, encryption context, or signing/verification key from the requested materials -
CachingCryptoMaterialsManager
MUST accept either a MKP or a keyring and require exactly one -
StreamEncryptor
MUST accept either a MKP or a keyring and require exactly one -
StreamDecryptor
MUST accept either a MKP or a keyring and require exactly one - All functional and integration tests must test with both MKPs and keyrings
- raw MKPs and keyrings MUST inter-operate end-to-end
- AWS KMS MKPs and keyrings MUST interoperate end-to-end
Metadata
Metadata
Assignees
Labels
No labels