What is Nostr?
Gavin Andresen [ARCHIVE] /
npub1s4lā€¦44kw
2023-06-07 10:42:44
in reply to nevent1qā€¦x238

Gavin Andresen [ARCHIVE] on Nostr: šŸ“… Original date posted:2012-12-03 šŸ“ Original message:On Mon, Dec 3, 2012 at ...

šŸ“… Original date posted:2012-12-03
šŸ“ Original message:On Mon, Dec 3, 2012 at 2:35 PM, Mike Koss <mike at 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
Author Public Key
npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kw