On Thu, Oct 29, 2015 at 4:07 PM, Anders Rundgren < [email protected]> 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. 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:[email protected]] On Behalf Of Anders Rundgren >> Sent: Wednesday, October 28, 2015 11:40 PM >> To: [email protected] >> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/jose >> > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
