📅 Original date posted:2012-12-17
📝 Original message:On Sun, Dec 16, 2012 at 4:15 PM, Melvin Carvalho
<melvincarvalho at gmail.com> wrote:
> On 3 December 2012 20:35, Mike Koss <mike at coinlab.com> wrote:
>> It would also be really nice to migrate to textual representations of data
>> structures as opposed to binary ones. The most successful internet
>> standards are based on text, making them that much more accessible for
>> developers to deal with them. JSON would be my preferred candidate.
>>
>> Why don't we sign the text representation of a (utf8) JSON, rather than
>> some complex encoding standard of JSON? That way the signatures are simple
>> - and you need only retain the original textual representation of a message
>> to validate the signature (as well as the decoded version, if you don't want
>> to alway re-parse the message when writing programs that use it).
> Binary formats can be challenging to deal with and convert to other formats.
> The experiences in the PKI world of ASN.1 have not been great, in terms of
> interop. It tends to create islands and silos. This is probably one of the
> reasons why X.509 and GPG are fragmented and why we dont really have a
> widely deployed web of trust on the net. Another reason is simply lack of
> developer resources to make tools. In that respect I think JSON offers
> significant advantages, though I am interested in the security issues
> raised.
I thought this had already been covered up-thread?
When creating something that must be hashed and/or compared, the data
structure must be created and reproduced precisely, byte-for-byte.
JSON offers significant -disadvantages- in this regard. With JSON,
you would therefore require an additional middle layer, between JSON
and application, ensuring that all fields are output in the same
order, all whitespace is not only perfectly preserved -- but reliably
generates identical whitespace output for identical inputs, given two
separate JSON implementations.
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com
Jeff Garzik [ARCHIVE] /
npub1kf…f3f58
2023-06-07 10:43:00
in reply to nevent1q…5swg
Author Public Key
npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58Published at
2023-06-07 10:43:00Event JSON
{
"id": "26ad0a071b7fac0de8eb69b11f0552c109221f6367f041b62637b9a84d9874d2",
"pubkey": "b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11",
"created_at": 1686134580,
"kind": 1,
"tags": [
[
"e",
"1bd78b419247dfb60fa2e8b1cf4983b406411160c7aa6e19780a4034c5da34de",
"",
"root"
],
[
"e",
"2fc5e5e0e413e991d82018788fcdc506dfdf005da3051e18a58ea2dfd19510f9",
"",
"reply"
],
[
"p",
"e316966328c4cb66c34719ef9a7b3bc54ef601663ad4ab06185991237735aa19"
]
],
"content": "📅 Original date posted:2012-12-17\n📝 Original message:On Sun, Dec 16, 2012 at 4:15 PM, Melvin Carvalho\n\u003cmelvincarvalho at gmail.com\u003e wrote:\n\u003e On 3 December 2012 20:35, Mike Koss \u003cmike at coinlab.com\u003e wrote:\n\u003e\u003e It would also be really nice to migrate to textual representations of data\n\u003e\u003e structures as opposed to binary ones. The most successful internet\n\u003e\u003e standards are based on text, making them that much more accessible for\n\u003e\u003e developers to deal with them. JSON would be my preferred candidate.\n\u003e\u003e\n\u003e\u003e Why don't we sign the text representation of a (utf8) JSON, rather than\n\u003e\u003e some complex encoding standard of JSON? That way the signatures are simple\n\u003e\u003e - and you need only retain the original textual representation of a message\n\u003e\u003e to validate the signature (as well as the decoded version, if you don't want\n\u003e\u003e to alway re-parse the message when writing programs that use it).\n\n\u003e Binary formats can be challenging to deal with and convert to other formats.\n\u003e The experiences in the PKI world of ASN.1 have not been great, in terms of\n\u003e interop. It tends to create islands and silos. This is probably one of the\n\u003e reasons why X.509 and GPG are fragmented and why we dont really have a\n\u003e widely deployed web of trust on the net. Another reason is simply lack of\n\u003e developer resources to make tools. In that respect I think JSON offers\n\u003e significant advantages, though I am interested in the security issues\n\u003e raised.\n\nI thought this had already been covered up-thread?\n\nWhen creating something that must be hashed and/or compared, the data\nstructure must be created and reproduced precisely, byte-for-byte.\nJSON offers significant -disadvantages- in this regard. With JSON,\nyou would therefore require an additional middle layer, between JSON\nand application, ensuring that all fields are output in the same\norder, all whitespace is not only perfectly preserved -- but reliably\ngenerates identical whitespace output for identical inputs, given two\nseparate JSON implementations.\n\n-- \nJeff Garzik\nexMULTI, Inc.\njgarzik at exmulti.com",
"sig": "5aa53b603da88500499b4263ee303a2eb451ca2fba6cd3e651e9149d793519b33abf2088b4e4480799ab8d213a1f5da58f6a087ea34c9b5f9616d8a17a763331"
}