BUG: Make round-tripping of common annotated security keys through base64 encoding/decoding more robust. We previously emitted illegal ending base64 characters (when appending base62 encoded checksums).
When generating CASK keys, we previously would emit final characters in the apparent base64 encoded string that weren't actually legal as the final encoded character (which must be constrained to 2 bits, one of the A, Q, g or w characters.
.NET is very forgiving of this issue when decoding and re-encoding, it will simply stop processing at the appropriate byte boundary and halt. As a result, a round-tripped CASK secret might differ from the original CASK that was emitted.
Now, the round-tripping to ensure base64-validity is added to the key minting logic.
As @rwoll has pointed out, the base64 vs. base62 confusion has resulted in unfortunate complexity in emitting this standard. Before finalizing it as a public format, we should fix that. It's too late for existing adopters! Such is the tyranny of back-compat.
Still, as long as we maintain compatibility with legacy keys, we can design (yet another) revision.
When generating CASK keys, we previously would emit final characters in the apparent base64 encoded string that weren't actually legal as the final encoded character (which must be constrained to 2 bits, one of the
A,Q,gorwcharacters..NET is very forgiving of this issue when decoding and re-encoding, it will simply stop processing at the appropriate byte boundary and halt. As a result, a round-tripped CASK secret might differ from the original CASK that was emitted.
Now, the round-tripping to ensure base64-validity is added to the key minting logic.
As @rwoll has pointed out, the base64 vs. base62 confusion has resulted in unfortunate complexity in emitting this standard. Before finalizing it as a public format, we should fix that. It's too late for existing adopters! Such is the tyranny of back-compat.
Still, as long as we maintain compatibility with legacy keys, we can design (yet another) revision.