BRK: Rename StandardCommonAnnotatedKeySize to StandardEncodedCommonAnnotatedKeySize and LongFormCommonAnnotatedKeySize to LongFormEncodedCommonAnnotatedKeySize to distinguish these from const values for key lengths in bytes.
BUG: Correct CommonAnnotatedKeyRegexPattern to detect keys (as denoted by H in the platform signature) derived from hashing data with CASK keys or arbitrary secrets.
BUG: Fix issue in low-level GenerateCommonAnnotatedTestKey helper in which key kind signature was hard-coded for D (derived) for both derived and hashed keys (which should be denoted by H).
NEW: Add ComputeCommonAnnotatedHash to generate annotated fingerprints from arbitrary strings.
NEW: Add CommonAnnotatedDerivedKeySignature and CommonAnnotatedHashedDataSignature to denote these generated key variations.
NEW: Update key generation to use Base62 for all encoded checksums (including primary keys). As a result, all test keys (in which the randomized component is a common character) will be valid (because we no longer will generate special characters in the computed checksum).
NEW: Add longForm argument to ComputeDerivedCommonAnnotatedKey and ComputeCommonAnnotatedHash to support backwards-compatible, full 64-byte encoded forms of these keys.
NEW: Provide ComputeDerivedCommonAnnotatedKey and ComputeCommonAnnotatedHash overloads that accept an arbitrary secret (and which allow platform and provider data to be explicitly specified).
Previously, we appear to have shipped 1.6.0 without including the ComputeCommonAnnotatedHash API. This API as authored required a CASK secret to operate but this is clearly not sufficient: providers that update their logic for producing derived keys and hashes may need to operate against a legacy secret that drives the signing process. To add this capability, however, we need to update the API to accept all the data (i.e., the CASK reserved platform + provider data) that is possible to encoded in a key. This was not previously required because we flowed that data from the CASK signing secret. This has the added benefit of allowing users to decide whether to flow data from a primary CASK key or to override it.
While making this change, I decided to take the plunge and simply make our key generation logic use a Base62 checksum. One positive result is that every test key (by CASK specification) will generate a legal key (because these specified patterns will never produce a special character that's illegal in CASK). We already had to use Base62 for the derived and hashed key cases; it is not a stretch to do so for primary keys. I've left back-up logic in the API for handling the case where the checksum is expressed as decoded base64 bytes. That means this library will continue to handle any historical key minters that are producing the older checksums.
This work also revealed a couple of small bugs related to the new hashing API: we needed to update our common regex to understand the H reserved key kind denoting this type and I fixed an issue in the literal generation logic that was not properly encoding D for derived keys and H for hashed.
StandardCommonAnnotatedKeySizetoStandardEncodedCommonAnnotatedKeySizeandLongFormCommonAnnotatedKeySizetoLongFormEncodedCommonAnnotatedKeySizeto distinguish these from const values for key lengths in bytes.CommonAnnotatedKeyRegexPatternto detect keys (as denoted byHin the platform signature) derived from hashing data with CASK keys or arbitrary secrets.GenerateCommonAnnotatedTestKeyhelper in which key kind signature was hard-coded forD(derived) for both derived and hashed keys (which should be denoted byH).ComputeCommonAnnotatedHashto generate annotated fingerprints from arbitrary strings.CommonAnnotatedDerivedKeySignatureandCommonAnnotatedHashedDataSignatureto denote these generated key variations.longFormargument toComputeDerivedCommonAnnotatedKeyandComputeCommonAnnotatedHashto support backwards-compatible, full 64-byte encoded forms of these keys.ComputeDerivedCommonAnnotatedKeyandComputeCommonAnnotatedHashoverloads that accept an arbitrary secret (and which allow platform and provider data to be explicitly specified).Previously, we appear to have shipped
1.6.0without including theComputeCommonAnnotatedHashAPI. This API as authored required a CASK secret to operate but this is clearly not sufficient: providers that update their logic for producing derived keys and hashes may need to operate against a legacy secret that drives the signing process. To add this capability, however, we need to update the API to accept all the data (i.e., the CASK reserved platform + provider data) that is possible to encoded in a key. This was not previously required because we flowed that data from the CASK signing secret. This has the added benefit of allowing users to decide whether to flow data from a primary CASK key or to override it.While making this change, I decided to take the plunge and simply make our key generation logic use a Base62 checksum. One positive result is that every test key (by CASK specification) will generate a legal key (because these specified patterns will never produce a special character that's illegal in CASK). We already had to use Base62 for the derived and hashed key cases; it is not a stretch to do so for primary keys. I've left back-up logic in the API for handling the case where the checksum is expressed as decoded base64 bytes. That means this library will continue to handle any historical key minters that are producing the older checksums.
This work also revealed a couple of small bugs related to the new hashing API: we needed to update our common regex to understand the
Hreserved key kind denoting this type and I fixed an issue in the literal generation logic that was not properly encodingDfor derived keys andHfor hashed.