Re: [jose] At a glance: JWS vs "in-object" ES6/JSON signatures

[Anders Rundgren <[e-mail]>]

On 2015-10-29 08:16, Mark Watson wrote:
>
>
> On Thu, Oct 29, 2015 at 4:07 PM, Anders Rundgren <[e-mail] <mailto:[e-mail]>> wrote:
>
>     On 2015-10-29 07:44, Mike Jones wrote:
>
>         This may be just my personal opinion, but preserving member creation order is only one small part of producing canonical JSON, which would be what would be required for such a scheme to be guaranteed to work. For instance, if the value 1e3 is part of the JSON input, will JSON.stringify() be guaranteed to emit it as 1e3, or might it be 1E3 or 100?  Unless it's deterministic, different serializers will produce different results, and therefore different signatures.  Without a canonical JSON being both defined and widely deployed, I can't recommend doing any work that requires a canonical JSON representation to deterministically succeed.
>
>
>     Mike,
>     There is no absolute need for a canonical format, but normalization of numbers is as you mention not without challenges.
>
>
> ​Also strings. Any character in a JSON string can be replaced with the \uxxxx format, changing the serialization without changing the string.

Mike,
I can't speak for all JSON-parsers in the world but the ES6-variant do the right thing already (normalize strings) and that's good enough for a standard that (primarily) would target ES6 (and JSON systems compatible with ES6).

Anders

>
> Unless you have canonical serialization you are going to need to insert / extract the signature member "manually" (without really parsing) to convert to / from the object-with-signature and the object-to-be-signed.​
>
> ...Mark
>
>
>     However, as described in the linked document there is a pretty simple "workaround" which I believe is fully ES6-compatible.
>
>     It certainly isn't ideal building standards on workarounds but pragmatism apparently ruled when Ecma specified ES6 property order so why couldn't the same thinking be used for signatures?  The workaround could maybe even go away with a future ES iteration if the Ecma ES committee is notified of the issue.
>
>     Anyway, this is not [at all] about dismissing JWS, it is about offering an alternative which has some pros and cons versus JWS. The in-object scheme cannot easily deal with multiple signature for example.
>
>     Regarding non-ES parsers, I don't see that as a showstopper; JavaScript is the origin of JSON and now it has changed.
>
>     Cheers,
>     Anders
>
>
>
>                                         -- Mike
>
>         -----Original Message-----
>         From: jose [mailto:[e-mail] <mailto:[e-mail]>] On Behalf Of Anders Rundgren
>         Sent: Wednesday, October 28, 2015 11:40 PM
>         To: [e-mail] <mailto:[e-mail]>
>         Subject: [jose] At a glance: JWS vs "in-object" ES6/JSON signatures
>
>         ES6-compliant in-object JS/JSON signature:
>
>             var inObjectSignedData =
>               {
>                   // Object data expressed as JS properties
>                   "device": "Pump2",
>                   "value": 1e-18,
>
>                   // Object signature
>                   "signature": {
>                       ...Protected headers + Signature value expressed as JS properties...
>                   }
>               };
>
>         JavaScript's JSON.parse() and JSON.stringify() suffice for "canonicalization" purposes.
>
>
>         Converting the above to JWS JSON Serialization you would get:
>
>         var signedData =
>             {
>                 // Object data in a coded format
>                 "payload":"<payload contents>",
>
>                 // Protected headers wrapped in Base64URL
>                 "protected":"<integrity-protected header contents>",
>
>                 // Signature in a unique format
>                 "signature":"<signature contents>"
>             }
>
>         ES6 was released in June 2015 so this opportunity is actually quite new.
>
>         Cheers,
>         Anders
>
>         http://webpki.org/ietf/draft-rundgren-predictable-serialization-for-json-tools-00.html#rfc.section.3.3
>
>         _______________________________________________
>         jose mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/jose
>
>
>     _______________________________________________
>     jose mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/jose
>
>