Feedback specific to the Salmon proposal should go to the Salmon list [1]. EHL
[1] http://groups.google.com/group/salmon-protocol/subscribe > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Manger, James H > Sent: Wednesday, February 10, 2010 10:59 PM > To: OAuth WG ([email protected]); John Panzer > Subject: Re: [OAUTH-WG] FW: Salmon signatures proposal - base64url > > 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 _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
