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

From: Anders Rundgren <[email-masked]>
Date: Thu, 29 Oct 2015 07:39:38 +0100

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

---

From: Mike Jones <[email-masked]>
Date: Thu, 29 Oct 2015 06:44:16 +0000

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

-----Original Message-----
From: jose [mailto:[email-masked]] On Behalf Of Anders Rundgren
Sent: Wednesday, October 28, 2015 11:40 PM
To: [email-masked]
Subject: [jose] At a glance: JWS vs "in-object" ES6/JSON signatures

   var inObjectSignedData =
     {

         // Object signature
         "signature": {

var signedData =
   {

Cheers,
Anders

_______________________________________________
jose mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/jose

---

From: Mike Jones <[email-masked]>
Date: Thu, 29 Oct 2015 06:46:13 +0000

Typo correction: s/100/1000/

-----Original Message-----
From: jose [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Wednesday, October 28, 2015 11:44 PM
To: Anders Rundgren; [email-masked]
Subject: Re: [jose] At a glance: JWS vs "in-object" ES6/JSON signatures

				-- Mike

-----Original Message-----
From: jose [mailto:[email-masked]] On Behalf Of Anders Rundgren
Sent: Wednesday, October 28, 2015 11:40 PM
To: [email-masked]
Subject: [jose] At a glance: JWS vs "in-object" ES6/JSON signatures

   var inObjectSignedData =
     {

         // Object signature
         "signature": {

var signedData =
   {

Cheers,
Anders

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 29 Oct 2015 08:07:58 +0100

> 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 guarante…

Mike,
There is no absolute need for a canonical format, but normalization of numbers is as you mention not without challenges.
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

---

From: Mark Watson <[email-masked]>
Date: Thu, 29 Oct 2015 16:16:21 +0900

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

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 29 Oct 2015 08:26:04 +0100

On 2015-10-29 08:16, Mark Watson wrote:
>
>
> On Thu, Oct 29, 2015 at 4:07 PM, Anders Rundgren <[email-masked] <mailto:[email-masked]>> wrote:
>
> ​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
>
>
>         From: jose [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Anders Rundgren
>         To: [email-masked] <mailto:[email-masked]>
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 29 Oct 2015 04:47:54 -0700

Is there any reason to believe that other JSON libraries are going to
implement the ES6 standard?  For example, what should one expect either a
hand rolled version or a C# version do?

> JavaScript's JSON.parse() and JSON.stringify() suffice for
"canonicalization"
> purposes.
http://webpki.org/ietf/draft-rundgren-predictable-serialization-for-json-too
ls-
> 00.html#rfc.section.3.3

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 29 Oct 2015 14:09:27 +0100

> hand rolled version or a C# version do?

I can only speak for myself.  I'm currently upgrading my Java-tools
to support ES6 number serialization.  The rest already supports a
superset of ES6 (with respect to JSON processing NB).

Anyway, since JavaScript is the mother of JSON, it seems logical that
the off-springs adapt as well :-)

Anders