John, I like your choice of base64url as a way to armour binary data and avoid escaping issues.
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. The example used throughout the spec is wrong. It looks like two "-" characters have been accidentally dropped (which is not a good advertisement for the robustness that base64url offers!) 4th line: change "bWUPHVy" to "bWU-PHVy" (decodes to "me><ur") 10th line: change " bGUU2Fs" to "bGU-U2Fs" (decodes to "le>Sal") Curiously, there are no "_" characters in the examples (data or sig). Changing the <title> to end with a "?", instead of a "!", would introduce one. Base64url is uncommon so examples using its differences from normal base64 might help catch a few implementation bugs. [actually I just noticed a "_" in the example modulus, but one in the example data would be even better] The signature is wrong, but not random so it is misleading. Decrypting the example signature with the example key produces a 20-byte value -- which happens to the be SHA-1 hash of the empty string (I don't recognize many hash values on sight, but this is one of them!). It should be the hash of the (armoured) data. It should be a SHA-256 hash, not SHA-1 as per <me:alg>RSA-SHA256</me:alg>. It should be wrapped in a DER-encoded DigestInfo structure (basically includes an id for SHA-256). It should have the PKCS#1 v1.5 "block type 1" prefix (01 FF FF… 00 <DigestInfo>), making the value a similar size to the modulus. Sorry for being picky ;) -- James Manger _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
