PROPOSAL: Use unpadded base64url encoding in Magic Signatures

[John Panzer]

All,

Over the past few weeks we've gotten feedback on the Magic Signatures Experimental draft (http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-experimental-00.html).  There is one issue that is almost but not quite a bikeshed color one; there seems to be consensus in the web development community that when using base64url armoring for data, we should avoid the use of "padding" characters. 

A small explanation:  The standard base64 encoding requires that the string be a multiple of 4 bytes.  To achieve this, it requires that you append up to 3 '=' (equals) characters at the end of a base64-encoded string.  Presumably this was originally done to make base64 decoding more efficient; but no one is arguing that it makes a difference these days.  In particular, equals signs require escaping when the content is used in URL parameters, and so can cause trouble.  This is still the case for base64url, which replaces all of the other characters with urlsafe variants.

The original base64 spec does  allow for non-padded variants, and some libraries (Java, perhaps others?) do have a flag that controls whether they are emitted or required on input.  However some languages don't have this, so you need to write a line of code to add the padding back in when parsing.  There's a (verbose) example at http://self-issued.info/docs/draft-goland-json-web-token-00.html#base64urlnotes; in most languages you can compress the re-padding down to 1 more complex line.

The trade-off here is that you need to do a bit of math and fix up strings for languages that don't support unpadded base64url text, but you never need to worry about escaping problems for properly encoded original strings.  Specs such as JSON Web Tokens and other proprietary APIs are going the unpadded route, so I think this is likely to be common practice.

PROPOSAL:  Change the Magic Signatures spec to require non-padded base64url strings.  This means that after removing whitespace, implementations must either call their equivalent of base64url_without_padding_decode or remove the padding and then call base64url_decode.  On the output side, implementations may need to strip off any trailing '=' characters.

--
John Panzer / Google
jpa...@google.com / abstractioneer.org / @jpanzer

[Bob Aman]

> PROPOSAL:  Change the Magic Signatures spec to require non-padded base64url
> strings.  This means that after removing whitespace, implementations must
> either call their equivalent of base64url_without_padding_decode or remove
> the padding and then call base64url_decode.  On the output side,
> implementations may need to strip off any trailing '=' characters.

Ruby wasn't too bad:

Base64.decode64(data.gsub('-', '+').gsub('_', '/').ljust(data.size +
(data.size % 4), '='))