Magic Signatures: Sign bytes before armouring?

[GoogleCodeExporter]

From James Manger: 
It might be nicer to sign the bytes that get armoured, instead of the ASCII 
output of the armouring.
I don't think this compromises the robustness aim of Magic Signatures.
It would mean you sign the binary message, then use base64url armouring 
to ensure the exact bytes signed make it unaltered to the other end. The 
armouring applies equally to the data and signature, but isn't actually 
involved in the crypto.

An extra little advantage is that the code to remove the armour [eg byte[] 
dearmour(String)] can also skip whitespace. With the current arrangement, 
a separate step to remove the whitespace is required as you need the 
base64url encoding without whitespace to verify the signature.

Original issue reported on code.google.com by jpanzer@google.com on 26 Feb 2010 at 6:15

[GoogleCodeExporter]

I think the security is the same either way.  I liked the clarity of signing 
the 
(normalized) base64 bytes because it's not possible to get confused about bytes 
vs. 
characters here -- it's ASCII, 1 bytes == 1 character, it's nearly impossible 
to mess 
up.  I worry about people with text buffers (e.g., UCS-2) running a signature 
generation over that, then converting to the armored encoding in a separate 
step and 
getting confused.  I may be over-paranoid though.

Original comment by jpanzer@google.com on 26 Feb 2010 at 9:39

[GoogleCodeExporter]

One nice thing about signing the base64 data is that it becomes much easier to 
build 
standard support libraries for handling the hard bits when the library 
developer can 
expect uniform inputs.

Original comment by bobwyman on 26 Feb 2010 at 9:48

[GoogleCodeExporter]

I'm going to close this out as WONTFIX I believe that the current behavior is 
the best approach -- we're going  
also need to sign the algorithm and encoding used, and I think that appending 
them to the base64url 
encoded data is simpler and safer than appending them to the original data 
(because then you have more 
normalization problems).

Please yell if you see this as a big problem.

Original comment by jpanzer@google.com on 6 Apr 2010 at 10:06

• Changed state: WontFix