I've had a nagging concern in my head about Base64url. I think it's probably not a problem, but I wanted to run it by the group just in case.
There's an ambiguity in RFC 4648 in cases where the length of the encoded octet stream is not a multiple of 3. Namely, RFC 4648 requires encoder behavior (pad with 0 bits), but it doesn't say what a decoder should do with the 2 or 4 left-over bits. In principle, if these bits are non-zero, then the string is invalid (since the encoder didn't do the right thing). In practice, I have not found a decoder that will reject a string for this reason. For example, all four of the following base64url strings decode to the ASCII string "asdf": "YXNkZg", "YXNkZh", "YXNkZi", and "YXNkZj". This can create a problem when cryptographic operations are done over base64url-encoded strings, as they are right now in JWS. Since there are multiple valid forms, it's possible that a change could be made that would not change the encoded content, but which would break the signature. Even when the base64url string is not input to a cryptographic operation, the spare bits could be used as a covert channel. Now, I don't think these are really a problem in practice. Encoder behavior is normalized, so real encoders should obey the rules. And of the two above attacks, (1) fails safe, and (2) seems too minor to worry about. But since there is an issue here in principle, I just wanted to get it out on the list in case anyone cares. --Richard
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
