Skip to content

[keyring] Enable use of keyrings #211

Closed
@mattsb42-aws

Description

@mattsb42-aws

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
No labels

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions