Subject: [jose] Base64url is not canonical

From: Richard Barnes <[email-masked]>
Date: Tue, 2 Jul 2013 19:30:09 -0400

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