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
Published at
2023-06-07 10:42:44Event JSON
{
"id": "4b88209ee513eb02fbee32d79957f0383b2092d2c46fd836e9046a65bd7ffe7d",
"pubkey": "857f2f78dc1639e711f5ea703a9fc978e22ebd279abdea1861b7daa833512ee4",
"created_at": 1686134564,
"kind": 1,
"tags": [
[
"e",
"1bd78b419247dfb60fa2e8b1cf4983b406411160c7aa6e19780a4034c5da34de",
"",
"root"
],
[
"e",
"b1fa7afa155fba84beb0bb90b99471ba6945a6b070e1b550d16cff3fb062930b",
"",
"reply"
],
[
"p",
"6c35cbce1572019d239813b345be98c18b740a50728c6e7191def884ca18a058"
]
],
"content": "š
Original date posted:2012-12-03\nš Original message:On Mon, Dec 3, 2012 at 2:35 PM, Mike Koss \u003cmike at coinlab.com\u003e wrote:\n\u003e Why don't we sign the text representation of a (utf8) JSON, rather than some\n\u003e complex encoding standard of JSON?\n\nBecause the results from standard JSON parsers are undefined if I give\nyou an \"envelope\" JSON that has repeated keys.\n\nFor example:\n\n{\n \"pki_data\" : \"...hex-or-base64-encoded certificate chain...\",\n \"signature\" : \"....hex-or-base64-encoded-signature-bytes\",\n \"message\" : \"....string-encoded-utf8-JSON\",\n \"message\" : \"....another string-encoded-utf8-JSON\",\n \"signature\" : \"....more hex-or-base64-encoded-signature-bytes\",\n \"pki_data\" : \"...another certificate chain...\",\n}\n\nThe JSON spec doesn't say what you'll get when you decode that mess.\nMaybe the first instance of each field, maybe the last, maybe one\npicked at random...\n\nThe JOSE (Javascript Signing and Encryption) spec says \"Thou Shalt Use\nA JSON Parser That Treats Multi-defined-keys As An Error.\"\n\nI expect that most developers will be lazy and will just use whatever\nJSON parser is convenient, no matter how much the spec/documentation\nwarns them not to. And that makes me nervous, because I can imagine\nattackers taking advantage of mismatches between (say) the JSON\nparsing software used by some back-end server process and a front-end\nJavaScript web wallet UI.\n\n-- \n--\nGavin Andresen",
"sig": "c94078f682d6178a9be069e330a70098d9cfd375af0810f77bf8220ff980216b2e4dbb8bea59a7203f619bc9a3bfd621f902484d76bb788d10a70e6b42b67ccd"
}