Hi Anders, I did some work very similar some time back for Learning Registry [1]. There are some known issues with the solution we chose and upon investigation of your doc, seems to suffer from similar problems.
My first question might be is what is your indented use case for this? Like
JOSE this seems to have very limited use due to a number of issues I'll outline
below.
JSON isn't guaranteed to serialize across systems consistently. These are
equivalent expressions:
// fig 1
{
"alpha": 1,
"beta": "kappa"
}
and
// fig 2
{
"beta": "kappa",
"alpha": 1
}
JOSE gets around this because the data is contained within the JWT
packaging. Additionally JOSE does signature validation of the base64 encoded
material - no the JSON entities. Like you've mentioned this isn't suitable for
usage as a data model.
The challenge is there's no good way (that I've uncovered) to
canonicalize JSON objects and retain use as a parsed data model that serializes
between platforms consistently. Ultimately what you've done is created a
canonical format that just treats the entire entity as a string. This wouldn't
necessarily work well as moving the data between Java, JavaScript, Ruby,
Python, etc… dictionary keys are not ordered consistently… say my system
receives fig 1 above and stores it for processing, the key order isn't
guaranteed when parsing it from it's native format. In our use case we use
CouchDB which stores documents as JSON. While CouchDB just happens to be
consistent in storing/retrieving dictionaries in the same order as they
submitted - there's not guarantee of that. Clients connecting to the DB also
may not reconstruct key order as well depending upon their JSON parsers. Thus
in order to make your solution work, Like JOSE, the canonical format must be
retained indefinitely in a portable format.
I've covered dictionaries… and FWIW XML shares the same problem with element
attributes. Other challenges in signing JSON are brought upon by floating point
and boolean values. Floating point precision is problematic unless encoded as
strings as floating point precision is not portable across platforms.
JavaScript, Erlang, and Python could introduce error when moving objects
between systems. Booleans have the same issue - some languages internally
store 1 and 0 others actually have native true and false.
Ultimately we chose to use Bencode [2] as part of a canonicalization solution
which unfortunately cannot handle floats very well, however in meeting I had
with BitTorrent folks some time ago we discussed Tagged Netstrings [3] as a
more viable solution.
IMO, the only way to make signing JSON objects reasonable is to have a solution
that is trivial to canonicalize the format for reconstruction of the signed
object and permits native serialization of the JSON. I don't want to have to
keep some string blob around because I need to preserve the canonical format.
To a certain extent the solution to this lies in the development,
implementation, and adoption of s "CJSON" or Canonical JavaScript Object
Notation, where the representation of the object is already canonical and
requires no transformations. Alas, there seems to be very little interest for
this, since most of the current work is like JOSE where signatures are only
needed short term for one time validation of data sent over the wire.
[1]
http://docs.learningregistry.org/en/latest/spec/Identity_Trust_Auth_and_Security/index.html#identity-and-digital-signatures
[2] https://wiki.theory.org/BitTorrentSpecification#Bencoding
[3] http://tnetstrings.org/
Jim Klo
Senior Software Engineer
Center for Software Engineering
SRI International
t. @nsomnac
On Aug 28, 2013, at 11:30 PM, Anders Rundgren <[email protected]> wrote:
> Since Google doesn't support XSD or XML DSig in Android I began looking at
> other alternatives.
> There were none :-( Now there is :-)
>
> https://openkeystore.googlecode.com/svn/resources/trunk/docs/Enveloped-JSON-Signatures.pdf
>
> Comments are welcome!
>
> Cheers
> Anders
>
smime.p7s
Description: S/MIME cryptographic signature
