Thanks! On Wednesday, February 10, 2010, Manger, James H <[email protected]> wrote: > 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 >
-- -- John Panzer / Google [email protected] / abstractioneer.org / @jpanzer _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
