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 <[email protected]> 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 < > [email protected]> > > 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 > >> > >> > >> > >> > > > >
