johnzon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: Digitally Signed JSON
Date Mon, 14 May 2018 15:13:19 GMT
Hmm

Actually order is not guaranteed - and believe me this is not a part i like
much - from the java side and will not by default - we discussed it. It is
mainly for perf and ensure operability which doesnt rely on that. Ijson
mode should force it though no?

Le lun. 14 mai 2018 15:21, Anders Rundgren <anders.rundgren.net@gmail.com>
a écrit :

> On 2018-05-14 15:04, Romain Manni-Bucau wrote:
> > Hi Anders
>
> Hi Romain,
>
> > I miss one thing I think.
> >
> > If you take jwt or derivatives it signs/validates json without need of
> any
> > normalization cause it mainly works on the raw payload.
>
> Right.  At the expense of obscuring both the message and the message
> structure.
>
> Anybody can try out clear text JSON signatures in seconds if they like:
> https://mobilepki.org/jose-jcs
>
>
> > Is the issue you speak about being idempotent?
>
> I'd rather describe this as accomplishing what the XML folks did 15Y+ ago.
>
>
> > If so what is the issue? while we use the same defaults it works, no? If
> > not you need a business key which is quite common too since json order is
> > never guaranteed too.
>
> This is a core issue.  The IETF draft builds on exploiting the fact that
> ECMAScript do guarantee property order.
> I implemented that in Java and it was dead simple:
> https://docs.oracle.com/javase/7/docs/api/java/util/LinkedHashMap.html
>
> However, I have recently changed my mind on that and now push for
> canonicalization
> https://github.com/cyberphone/json-canonicalization#json-canonicalization
> because it can be provided as a "dumb filter" which is quicker than
> standardizing features on the parser/serializer level.
>
> This is only really difficult part:
>
> https://github.com/cyberphone/json-canonicalization/tree/master/dotnet/es6numberserialization
> Microsoft is actually testing their JS serializer with my 100 million test
> value set :-)
>
> Cordialement (we are both in France),
> Anders
>
> >
> >
> > Le lun. 14 mai 2018 11:45, Anders Rundgren <
> anders.rundgren.net@gmail.com>
> > a écrit :
> >
> >> Hi Johnzoners!
> >>
> >> In case you want to digitally sign JSON messages/documents, the
> >> standardized way of doing that is dressing the JSON data in Base64Url.
> IMO
> >> this defeats the value of clear text formats.
> >>
> >> Current standard (JWS):
> >>
> eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOiJiMDhmODZhZi0zNWRhLTQ4ZjItOGZhYi1jZWYzOTA0NjYwYmQifQ.-xN_h82PHVTCMA9vdoHrcZxH-x5mb11y1537t3rGzcM
> >>
> >> The (AFAIK...) only workable solution around that problem is
> normalization
> >> of JSON data so that it gets a unique/stable representation.  Proposed
> >> alternative (Cleartext JWS):
> >> {
> >>     "now": "2018-04-16T11:23:06Z",
> >>     "name": "Joe",
> >>     "id": 2200063,
> >>     "signature": {
> >>       "alg": "ES256",
> >>       "kid": "example.com:p256",
> >>       "val":
> >>
> "GagHnDBKhU7ynzLLH1Qs3tYmzbwxyokDtu7f0Iz1mB0GL-9ER_J5fJA9qz3IG6IR_jLHh3fsUEKAzB4GzLex2A"
> >>     }
> >> }
> >>
> >> The "signature" property contains the signature, the other properties
> are
> >> just arbitrary application data.
> >>
> >> The #1 problem is the serialization of JSON Numbers [1].  It would be
> >> FANTASTIC if this feature (which is 100% compatible with JSON), became a
> >> part of the Java/JSON standards.
> >>
> >> Recent standardization activity supported by Microsoft relying on this
> >> feature:
> >> https://tools.ietf.org/id/draft-erdtman-jose-cleartext-jws-00.html
> >>
> >> Cheers,
> >> Anders
> >>
> >> 1] The idea is using ECMAScript's definition which I currently have
> >> running for Java, C# .NET and Python 3
> >>
> >>
> >>
> >>
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message