get-proof-by-hash doesn't support base64 URL encoding

[gdbelvin]

FromBase64 does not support Base64 URL encoding. The result is that some hashes cannot be queried via /v1/get-proof-by-hash.

Witness:

http://<server>/ct/v1/get-proof-by-hash?tree_size=10&hash=ti7UvcXhFSYLtcmdhNHAzS3smSYFX+ViUTHjsO0I/rs=

Expected result:

{
"error_message": "Couldn't find hash.",
"success": false
}

Actual result:

{
"error_message": "Invalid \"hash\" parameter.",
"success": false
}

The problem, of course, is that / is a base64 character in the Std encoding that can't be used in a URL. Please update the server to support base64 URL encodings.

[pphaneuf]

Aviator also seems to have a similar issue?

{
  "error_message": "Missing \u0026#39;hash\u0026#39; parameter",
  "success": false
}

[gdbelvin]

Perhaps. Please verify. I'm surprised that this hasn't been a big issue so far. Please fix.

[RJPercival]

@gdbelvin, it looks like you weren't percent-encoding the URLs you used. Standard Base64 works fine in URLs so long as you swap the characters with special meaning (e.g. "/", "+", "=") for their percent-encoded equivalents ("%2F", "%2B", "%3D").

[gdbelvin]

Good to know. I'll update my client for now.
For the future though, percent encoding seems like a hack. Can we change the server to support proper URL Base64 encoding? I didn't find a particular base64 encoding specified in the RFC - perhaps we should include that in the next revision?

[pphaneuf]

RFC 6962 refers to it as "base64 encoding", which is how RFC 4648 says you're supposed to refer to the encoding we're using as "base64", and additionally says that that the URL-safe one should not be referred to as simply "base64".

Most HTTP libraries let you set key/value URL parameters and take care of the encoding for you, it's rarely been a problem (and even with the base64url encoding, the "=" still has to be percent-encoded anyway).