On Mon, Dec 3, 2012 at 2:35 PM, Mike Koss <m...@coinlab.com> wrote:
> Why don't we sign the text representation of a (utf8) JSON, rather than some
> complex encoding standard of JSON?
Because the results from standard JSON parsers are undefined if I give
you an "envelope" JSON that has repeated keys.
For example:
{
"pki_data" : "...hex-or-base64-encoded certificate chain...",
"signature" : "....hex-or-base64-encoded-signature-bytes",
"message" : "....string-encoded-utf8-JSON",
"message" : "....another string-encoded-utf8-JSON",
"signature" : "....more hex-or-base64-encoded-signature-bytes",
"pki_data" : "...another certificate chain...",
}
The JSON spec doesn't say what you'll get when you decode that mess.
Maybe the first instance of each field, maybe the last, maybe one
picked at random...
The JOSE (Javascript Signing and Encryption) spec says "Thou Shalt Use
A JSON Parser That Treats Multi-defined-keys As An Error."
I expect that most developers will be lazy and will just use whatever
JSON parser is convenient, no matter how much the spec/documentation
warns them not to. And that makes me nervous, because I can imagine
attackers taking advantage of mismatches between (say) the JSON
parsing software used by some back-end server process and a front-end
JavaScript web wallet UI.
--
--
Gavin Andresen
------------------------------------------------------------------------------
Keep yourself connected to Go Parallel:
BUILD Helping you discover the best ways to construct your parallel projects.
http://goparallel.sourceforge.net
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
