Usually a digital signature is applied to a specific sequence of bytes so needing a canonical representation isn't necessary. (They are used to ensure the specific bytes are as signed).
What's the reason for requiring ordered keys in this case? Note that utf-8 has multiple representations per string, as do numeric values (as strings - which is an issue for text encoded json) - so ordered keys in the binary representation of an array is just one aspect. (The utf-8 rep of strings and decimal rep of numbers affect Json's byte-by-byte comparison too). Mark. Sent from my iPhone > On 12 Jan 2016, at 18:15, David Bovill <[email protected]> wrote: > > I was looking into standards for digitally signing JSON - and I wandered > about signing Livecode arrays. This would need some way to normalise the > array construction as (from the docs): > > Arrays in LiveCode are un-ordered. This means in particular that encoding >> two arrays will not necessarily produce the same result, even if the arrays >> had the same elements. To compare two arrays, simply use the = operator >> directly on them rather than encoding them first. > > > I take this to mean that depending on exactly how (the order of > construction), a Livecode array is created, it's hash will be different, as > will the result of arrayDecode. > > Is this right? Any thoughts on how to digitally sign an array? If this > proves as complex as i think, it may be more useful to replicate the JSON-LD > signature algorithm: <https://web-payments.org/specs/source/ld-signatures/> > > The following algorithm specifies how to create a digital signature that >> can be later used to verify the authenticity and integrity of a Linked >> Data Document >> <https://web-payments.org/specs/source/ld-signatures/#dfn-linked_data_document>. >> A Linked Data Document >> <https://web-payments.org/specs/source/ld-signatures/#dfn-linked_data_document> >> , document, a private key >> <https://web-payments.org/specs/source/ld-signatures/#dfn-private_key>, >> and an identifier for the public/private key pair, creator, are required >> inputs. Anonce >> <https://web-payments.org/specs/source/ld-signatures/#dfn-nonce> and a >> domain <https://web-payments.org/specs/source/ld-signatures/#dfn-domain> may >> also be optionally specified as inputs. A Signed Linked Data Document >> <https://web-payments.org/specs/source/ld-signatures/#dfn-signed_linked_data_document> >> is >> produced as output. Whenever this algorithm must encode strings, it uses >> UTF-8 encoding. >> >> 1. Create a copy of document, output. >> >> >> 1. Remove any signature nodes from the default graph in output. >> >> >> 1. Generate a normalized document by normalizing document according to >> the *URDNA2015* [RDF-DATASET-NORMALIZATION >> >> <https://web-payments.org/specs/source/ld-signatures/#bib-RDF-DATASET-NORMALIZATION>] >> algorithm. >> >> >> 1. Generate an ISO8601 combined date and time string, created containing >> the current date and time, accurate to at least one second, in Universal >> Time Code format. For example: 2011-09-23T20:21:34Z. Add an entry to >> headers with a key ofhttp://purl.org/dc/elements/1.1/created and a >> value of created. >> >> >> 1. Create a value tbs that represents the data to be signed, and set >> it to the result of running the Create Verify Hash Algorithm >> >> <https://web-payments.org/specs/source/ld-signatures/#create-verify-hash-algorithm> >> . >> >> >> 1. Digitally sign tbs using the private key >> <https://web-payments.org/specs/source/ld-signatures/#dfn-private_key> and >> the the *RSASSA-PKCS1-v1_5* [PKCS1 >> <https://web-payments.org/specs/source/ld-signatures/#bib-PKCS1>] >> algorithm and base-64 encode the resulting value. The resulting base-64 >> encoded string is the signatureValue >> <https://web-payments.org/specs/source/ld-signatures/#dfn-signaturevalue> >> . >> >> >> 1. Add a signature node to output containing a Linked Data Signature >> >> <https://web-payments.org/specs/source/ld-signatures/#dfn-linked_data_signature> >> using creator, created, signatureValue >> <https://web-payments.org/specs/source/ld-signatures/#dfn-signaturevalue>, >> and if given, the nonce >> <https://web-payments.org/specs/source/ld-signatures/#dfn-nonce>, and >> domain >> <https://web-payments.org/specs/source/ld-signatures/#dfn-domain>. >> >> >> 1. Return output as the Signed Linked Data Document >> >> <https://web-payments.org/specs/source/ld-signatures/#dfn-signed_linked_data_document> >> . > So make something like a Livecode version of this library - > https://www.npmjs.com/package/jsonld-signatures > _______________________________________________ > use-livecode mailing list > [email protected] > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
