Feature |
---|
Caching Cryptographic Materials Manager |
Specification |
---|
Caching Cryptographic Materials Manager |
Language | Repository |
---|---|
C | aws-encryption-sdk-c |
Java | aws-encryption-sdk-java |
JavaScript | aws-encryption-sdk-javascript |
Python | aws-encryption-sdk-python |
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
Upon initialization, the caching Cryptographic Materials Manager (caching CMM) MUST define an underlying CMM, an underlying Cryptographic Materials Cache (CMC), and a time-to-live (TTL) for cache entries. This change clarifies that the caller MUST provide these parameters.
- Changing the shape of any CMC APIs is out of scope.
- Changing the shape of the CMM interface is out of scope.
Before this change, the caching CMM specification lists several properties that the caching CMM MUST define upon initialization. Among these, we intend for the caller to provide the underlying CMC, the underlying CMM, and the TTL; but the specification does not state that intent. This change adds this missing intent.
This change SHOULD NOT have any security implications.
This change can potentially break any customer using an AWS Encryption SDK implementation that does not require the user to provide the TTL value upon caching CMM initialization. However, all existing implementations require the user to provide the TTL value, so in practice this is not an issue.
When initializing a caching CMM, the caller MUST provide an underlying CMC and a TTL.
The caller MUST either provide an underlying CMM or a keyring. If the caller provides a keyring, then the caching CMM MUST set its underlying CMM to a default CMM initialized with the keyring.