Subject: [jose] JCS - JSON Clear Text Signature

From: Anders Rundgren <[email-masked]>
Date: Sun, 01 Sep 2013 11:05:02 +0200

New name and updated documentation.

https://openkeystore.googlecode.com/svn/resources/trunk/docs/JSON-Clear-Text-Signature-Scheme.pdf

Enjoy!

Anders

---

From: "Manger, James H" <[email-masked]>
Date: Mon, 2 Sep 2013 10:54:14 +1000

> ----------
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Anders Rundgren
> Sent: Sunday, 1 September 2013 7:05 PM
> 

Anders,

This is quite an attractive approach — as long as canonicalization works. A canonical JSON form is viable, though many are reluctant to consider it due to historical challenges with canonical XML (and DER).

The canonical form described in JCS is not precise enough. It doesn't discuss escapes in strings (eg "/" vs "\/" vs"\u002f" vs "\u002F"). I'm not sure what "UTF-8 order" is: sorting on Unicode scalar values would be better. Sorting in descending order (Z before A) is a strange (poor) choice. JCS doesn't define a canonical form for numbers, instead a receiver must keep the original form. That effectively means you cannot use any "normal" parser (that returns an int or double when parsing a number).

JSON.stringify [ECMAScript v5.1; http://www.ecma-international.org/ecma-262/5.1/#sec-15.12.3] already precisely defines 1 form for any number or string. Add sorting object elements (and using lower-case for \uxxxx escapes) and you have great basis for a highly-interoperable JSON c14n spec.
[see a discussion on the IETF JSON WG list: http://www.ietf.org/mail-archive/web/json/current/msg00134.html]

--
James Manger

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 02 Sep 2013 07:58:10 +0200

On 2013-09-02 02:54, Manger, James H wrote:
> This is quite an attractive approach — as long as canonicalization works.
>  A canonical JSON form is viable, though many are reluctant to consider
>  it due to historical challenges with canonical XML (and DER).

James,

Thanx for your input, I _really_ appreciate although I'm not trying to create a standard, only a useful system. Canonicalization is a difficult topic.  Since the actual target for JCS are security protocols to be written, rather than legacy applications, I have taken the liberty doing a few shortcuts.

>
>
> The canonical form described in JCS is not precise enough.

You are absolutely right.  I have updated the spec and code accordingly.

>  It doesn't discuss escapes in strings (eg "/" vs "\/" vs"\u002f" vs "\u002F").

Now it does :-)

You probably disagree on the result but since JSON parsers are trivial (I know, I just wrote one), the few that may want to support clear-text signatures should be able to perform the needed updates.  Compared to the crypto it should be piece of cake.

In my mind the JSON clear-text concept gets severely obstructed by the \/ escape.
It also creates an artificial gap between the "on-the-wire" and "in-the-doc" worlds.  So I simply abolished it!

Dealing with \uhhhh on-the-wire is only interesting for "hand-written" JSON and that's completely out-of-scope for JCS.

>  I'm not sure what "UTF-8 order" is: sorting on Unicode scalar values would be better.

Fixed.

> Sorting in descending order (Z before A) is a strange (poor) choice.

Fixed.

>  JCS doesn't define a canonical form for numbers, instead a receiver must
> keep the original form. That effectively means you cannot use any "normal"
> parser (that returns an int or double when parsing a number).

I would put it like this: As an _engineer_ I wouldn't consider using methods that already have been proven to be "brittle".

> JSON.stringify [ECMAScript v5.1; http://www.ecma-international.org/ecma-262/5.1/#sec-15.12.3]
> already precisely defines 1 form for any number or string. Add sorting object elements (and using
> lower-case for \uxxxx escapes) and you have great basis for a highly-interoperable JSON c14n spec.

This is the path for standardization. I'm not going there.
Because If I did, I would probably end-up with dangerous stuff like the following extract from
draft-ietf-jose-json-web-key-14:

   The following is a non-normative example of a JWK with a RSA signing
   key represented both as a bare public key and as an X.509 certificate
   using the "x5c" parameter:

     {"kty":"RSA",
      "use":"sig",
      "kid":"1b94c",
      "n":"vrjOfz9CcjBPD5eunqsIo1vQ",
      "e":"AQAB",
      "x5c":
       ["MIIDQjCCAiqgAwIBAgIvACWpkA6SdS4xSvdXK3IVfOWA=="]
     }

How are applications supposed to deal with this?  Non-normatively I suppose  :-)  You use the key that sort of "feels" best?
IMHO, this smells "committee" and "edge-cases" a long way...

Cheers
Anders

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 3 Sep 2013 11:20:01 +1000

> Now it does :-)
> 
> You probably disagree on the result but since JSON parsers are trivial
> (I know, I just wrote one), the few that may want to support clear-text
> signatures should be able to perform the needed updates.  Compared to
> the crypto it should be piece of cake.
>
> It also creates an artificial gap between the "on-the-wire" and "in-
> the-doc" worlds.  So I simply abolished it!
> 
> Dealing with \uhhhh on-the-wire is only interesting for "hand-written"
> JSON and that's completely out-of-scope for JCS.

Forbidding \uhhhh means you are forbidding 27 control chars (eg U+0007 BELL) whose only legal JSON representation is in the form \u00hh.
That is probably fine for many apps, but not for a general purpose JSON signing scheme.

> Fixed.

How is this JSON object sorted? {"a\"b":1,"a#b":2}

P.S. Your code fails to handle \x escapes in object element names. That is, scanProperty() should call scanQuotedString(). Also, an empty string "" is a perfectly valid (if unusual) object element name.

--
James Manger

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 03 Sep 2013 06:39:03 +0200

James,

I have like 4 weeks of practical experience with JSON so I'm obviously _not_ an authority on every aspect of it.
However, I would be _surprised_ (have though happened before...) if what you write is valid for the majority of parsers out there; at least it would depart from how many other text-processing-systems usually work.

That is, if you give a JSON serializer the Java literal "hi\u0007" I would expect the output to actually contain three characters within quotes.
The IMO only reason for special treatments of certain characters like \" is because parsing would fail otherwise.
BELL should from a parser's point-of-view be no different than a EURO sign (when featured within a quoted string NB...).

> How is this JSON object sorted? {"a\"b":1,"a#b":2}

Here I would like to refer to the following lines in the specification:

  "Disclaimer: This document does not represent a standard of any kind.
   It might at best be useful as input to a future standardization process"

:-)

> 
> P.S. Your code fails to handle \x escapes in object element names. That is, scanProperty() should call scanQuotedString().
> Also, an empty string "" is a perfectly valid (if unusual) object element name.

Thanx, I will (eventually) look into this.  It is on the "edge" IMO.

If anybody feel tempted doing standardization work on something "JCS-ish", it's up for grabbers; I don't have the motivation (or funding) for that.

Right now I'm simply very pleased (after an intense week with pretty major iterations based on constructive input), having an ultra-simple clear-text signature scheme that is _way_ more suitable for supporting verbose security-protocols than heavy-footed XML standards.

Cheers
Anders