-
Notifications
You must be signed in to change notification settings - Fork 85
Closed
Milestone
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:
-
DefaultCryptoMaterialsManagerMUST accept either a MKP or a keyring and require exactly one -
DefaultCryptoMaterialsManagerMUST fail if the keyring could not complete the cryptographic materials -
DefaultCryptoMaterialsManagerMUST fail if the keyring changes the algorithm, encryption context, or signing/verification key from the requested materials -
CachingCryptoMaterialsManagerMUST accept either a MKP or a keyring and require exactly one -
StreamEncryptorMUST accept either a MKP or a keyring and require exactly one -
StreamDecryptorMUST 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