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

[Mark Watson <[e-mail]>]

On Thu, Oct 29, 2015 at 4:07 PM, Anders Rundgren <
[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.

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]] On Behalf Of Anders Rundgren
>> Sent: Wednesday, October 28, 2015 11:40 PM
>> To: [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]
>> https://www.ietf.org/mailman/listinfo/jose
>>
>
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose
>