You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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:
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 oneDefaultCryptoMaterialsManager
MUST fail if the keyring could not complete the cryptographic materialsDefaultCryptoMaterialsManager
MUST fail if the keyring changes the algorithm, encryption context, or signing/verification key from the requested materialsCachingCryptoMaterialsManager
MUST accept either a MKP or a keyring and require exactly oneStreamEncryptor
MUST accept either a MKP or a keyring and require exactly oneStreamDecryptor
MUST accept either a MKP or a keyring and require exactly oneThe text was updated successfully, but these errors were encountered: