Subject: [jose] JSON parser in JavaScript supporting canonicalization

From: Anders Rundgren <[email-masked]>
Date: Tue, 07 Jan 2014 09:33:26 +0100

This spec. describes an ultra-simple JSON canonicalization scheme:
https://openkeystore.googlecode.com/svn/resources/trunk/docs/jcs.html

An equally simple parser supporting this scheme can be found here:
https://code.google.com/p/openkeystore/source/browse/javascript/trunk/src/jsonparser/JSONParser.js

This (IMO) verifies my claim that cleartext JSON signatures is a viable alternative to JWS for applications
where the payload is complex which were not really the case for the original JOSE scenarios.

thanx,
Anders

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 7 Jan 2014 10:12:32 +0100

> https://openkeystore.googlecode.com/svn/resources/trunk/docs/jcs.html

That’s not JSON.
("Parsing Restrictions:” "• The original property order must be preserved.”)

(Members of the JSON WG will be painfully aware that, yes, this can be done in currently deployed in-Browser JavaScript implementations if certain key values are not being used, but it cannot be done in JSON in general.)

Grüße, Carsten

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 07 Jan 2014 10:31:16 +0100

> ("Parsing Restrictions:” "• The original property order must be preserved.”)

It is a correct but [somewhat] restricted JSON syntax.

This restriction is probably a minor problem (since it should be easy to
support), while the "cheap trick" canonicalization method preserving
non-normalized numbers like 4.50 was the thing that _required_ an upgraded
parser.  But as the latter turned out to be quite simple, I (FWIW) didn't
see that as a showstopper.  It was [almost] fun to write :-)

Regards,
Anders

> 
> (Members of the JSON WG will be painfully aware that, yes, this can be done in 
> currently deployed in-Browser JavaScript implementations if certain key values
> are not being used, but it cannot be done in JSON in general.)

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 7 Jan 2014 10:47:18 +0100

> It is a correct but [somewhat] restricted JSON syntax.

The syntax conformance is not the point.

In my version of a “somewhat restricted JSON syntax", a double newline in front of a string means that the string is a binary string in base64url decoding.  Fully conforming.  And, I’m expecting all of your implementations to heed this and automatically decode those binaries, of course.  Oh, and decode strings starting with \u003a as a symbol, while continuing to decode strings starting with an unescaped colon as a string.

That’s just not the way JSON works.

If you need a special parser for a syntax, it’s no longer JSON.

Grüße, Carsten

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 07 Jan 2014 11:37:57 +0100

> If you need a special parser for a syntax, it’s no longer JSON.

I'm sorry Carsten but my brain doesn't parse what you are writing :-)

The parser in question reads the JSON syntax as specified in the RFC.  At least that was the goal.

What's not described in the RFC is the way a JSON parser deal with the parsed data.
It is clear that no other parser out there can be used to verify signatures based on JCS.
If this makes the entire concept invalid that's a valid opinion, however it is not a fact.

Backward compatibility at any cost is at least not my recipe for success.

BTW, the whole JS-thing looks extremely odd, not even "long" and BigInteger are supported!
The XML syntax added in ES4 look quite ridiculous.  Who asked for that?

I'm actually quite happy with the "cheap trick canonicalization" scheme.  Even a third-rate
programmer should be able to get it right :-)

Regards,
Anders

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 7 Jan 2014 12:04:38 +0100

> If this makes the entire concept invalid that's a valid opinion, however it is not a fact.

It’s not the concept that is invalid.

When people read “JSON”, they expect to be able to make use of the vast JSON ecosystem.
That is not the case with the syntax that you are proposing.
So it is more honest not to call it JSON.
(Not beyond “leveraging JSON syntax for a new data interchange format”, that is.)

Grüße, Carsten

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 08 Jan 2014 11:42:36 +0100

> (Not beyond “leveraging JSON syntax for a new data interchange format”, that is.)

The only real snag with JCS which I'm aware of is that you cannot [safely] validate
such a signature when expressed as a JavaScript object literal:

var nonVerifiableSignedData = {
  "unnormalizedNumber", 4.50,
  "Signature":
     {
         ...
     }
};

It would require a patch i JavaScript itself to solve that (which is hardly an option).
That is, in a JS environment, you have to pass JCS objects through a separate
[enhanced] JSON parser as valid JS strings.

Given the fact that you should verify security protocol data thoroughly and base64
decode etc., it seems that no matter what you do there are additional parsing steps
involved which IMO makes the problem above fairly unimportant.

I'm currently integrating JCS with WebCrypto.  It's not easy but this has more to
do with my n00b-status on JS programming than with any fundamental problems in
the syntax or architecture.

It is possible that calling this JSON is false marketing, I leave that to the
market to decide :-)

Anders