Subject: [Json] RFC 8785 - JSON Canonicalization Scheme

From: Anders Rundgren <[email-masked]>
Date: Sat, 4 Jul 2020 20:27:12 +0200

https://www.rfc-editor.org/rfc/rfc8785

In case you would like to test what you can do with JSON canonicalization, there are two public Web applications at your disposal:
Using JWS: https://mobilepki.org/jws-jcs
Using an "unwrapped" JWS called Java Signature Format (JSF): https://mobilepki.org/jsf-lab

A real-world implementation from OWASP using JSF: https://cyclonedx.org/use-cases/#authenticity

In Saturn JSF is not only a security solution, it is also used for counter-signatures to simplify state-holding in payment systems:
https://cyberphone.github.io/doc/saturn/hybrid-payment.html#6

By securely embedding related messages in each other (aka "Russian doll"), there is no need for external references to previous messages.

Enjoy!

Anders

---

From: Ulysse Carion <[email-masked]>
Date: Sun, 5 Jul 2020 18:10:33 -0700

Hi Anders,

Nice job with JCS. I've taken a stab at implementing it here (in
Golang), because I have a possible use for something like this, and
your Golang reference implementation wasn't super usable as-is:

https://github.com/ucarion/jcs

Overall, I think this document makes sense, and -- given its
prerequisites -- is the design any one of us would have landed on
given time to meditate on the details. I usually specifically avoid
embedding signatures within the data being signed, but when that's not
an option JCS seems a quite reasonable choice.

Two notes on what you could do to help future implementers:

1. I wish you could provide some sort of script that generates
floating-point test-cases, instead of having folks download a 3.8G
file if they want to make sure they're correctly aping JavaScript's
float-to-string algorithm.

2. I don't understand why implementations MUST detect and error on
invalid surrogate pairs. For implementations that aren't implementing
their own JSON parser at the same time, doing so may not always be
possible. Can you elaborate on the reasoning, and maybe offer
implementers guidance on the relevant parts of the Unicode spec? A
prospective implementer already needs to go pretty deep into the hairy
details of floating-point numbers and character encoding, and a bit of
guidance in the developer portal would go a long way.

These are just details. Overall, I think JCS is quite nicely done.
Thanks for making this.

Best,
Ulysse

On Sat, Jul 4, 2020 at 11:27 AM Anders Rundgren
<[email-masked]> wrote:
> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json

---

From: John Cowan <[email-masked]>
Date: Sun, 5 Jul 2020 23:04:38 -0400

We need to catch and reject unpaired surrogates because all the world isn't
Java, JavaScript, and C#.  Languages that deal in UTF-8 literally have no
way to represent unpaired surrogates, and shouldn't have to do something
horribly wrong to handle them.

On Sun, Jul 5, 2020 at 9:11 PM Ulysse Carion <[email-masked]> wrote:

> > In case you would like to test what you can do with JSON
> canonicalization, there are two public Web applications at your disposal:
> > A real-world implementation from OWASP using JSF:
> https://cyclonedx.org/use-cases/#authenticity
> >
> > In Saturn JSF is not only a security solution, it is also used for
> counter-signatures to simplify state-holding in payment systems:
> > By securely embedding related messages in each other (aka "Russian
> doll"), there is no need for external references to previous messages.
> >
> > Enjoy!
> >
> > Anders
> >

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 6 Jul 2020 15:57:25 +0200

> Hi Anders,
Hi Ulysse,
> https://github.com/ucarion/jcs

Great job! Your code (modulo comments) weighed in at a mere 200 lines.

> given time to meditate on the details. 

Well, we didn't exactly "landed" there; RFC 8785 represents a third
and complete rewrite. Although working, the previous attempts were
pretty much c**p from an implementation point-of-view.  Without the
great (but sometimes rather dismissive) input from the IETF community,
it would maybe never even had happened :)

> I usually specifically avoid

In my case the ability to (in a reasonable manner), serialize a signed
HTTP request was *one* of the biggest motivations.  AFAICT, none of the
current efforts in the IETF, the W3C or more recently in ETSI, have this
capability.

> float-to-string algorithm.

I'm currently spending my limited cycles on the next steps on this
journey which will take a lot of work although they are (IMO)
technically ready as well as implemented:
https://cyberphone.github.io/doc/security/jsf.html
https://cyberphone.github.io/doc/security/jef.html

> implementers guidance on the relevant parts of the Unicode spec?

If you don't honor all parts of a specification, you may run into
interoperability problems.  JCS is supposed to be "complete" but
I'm sure that most people (currently including myself...), won't
bother to death about this particular requirement in their actual
implementations...

> A prospective implementer already needs to go pretty deep into the hairy

There is hope:
https://github.com/ulfjack/ryu/issues/87#issuecomment-646550719

> These are just details. Overall, I think JCS is quite nicely done.

Thanx,
Anders