Le lun. 14 mai 2018 21:36, Anders Rundgren <[email protected]> a écrit :
> On 2018-05-14 19:40, Romain Manni-Bucau wrote: > > > > > > Le lun. 14 mai 2018 17:12, Anders Rundgren < > [email protected] <mailto:[email protected]>> a > écrit : > > > > On 2018-05-14 17:13, Romain Manni-Bucau wrote: > > > Hmm > > > > Hi Romain :-) > > > > > > 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. > > > > As I understand JSON-B, property sorting like in my revised proposal > is the default: > > > > 3.13 Attribute order > > > > Class properties MUST be serialized in lexicographical order into > > the resulting JSON document. In case of inheritance, properties > > declared in super class MUST be serialized before properties > declared > > in a child class. > > > > Related: https://github.com/javaee/jsonb-spec/issues/81 > > > > Shouldnt and in 1.0 it was clear it was not the case. > > This is information I got from the Oracle guys. > > Anyway, does this mean that the following is incorrect as well? > > 4.2 Customizing Property Order > To customize the order of serialized properties, JSON Binding provides > javax.json.bind.config.PropertyOrderStrategy class. > Class javax.json.bind.config.PropertyOrderStrategy provides the most > common property order strategies. > • LEXICOGRAPHICAL > • ANY > • REVERSE > > Here I would consider PREDICTIVE (like ECMAScript) because it is quite > cool. Way more useful than REVERSE and ANY at least. > This is some ordering but you can explicitly specify it with @jsonbpropertyorder iirc. Default is aligned on java so stable by compilation cycle. > > Also it doent help signing since you must ensure what you sign goes > last. Ignoring the fact it assumes the formatting of the ending document > (prettified or not) and only uses the content (which opens security holes > if not coupled to other external solutions) then it only works assuming the > signing headers are first on the read side (validate before reading) and > last on signing side (if you want to avoid to have it all in mem). > > You must indeed parse the entire object before you can validate the > signature. > > > > Globally it means signing either match the jwt constraint and ijson > doesnt help or you'd better sign outside the payload (http header or so). > > FWIW, the MSFT person involved in this work (Mike Jones) is the actual > designer of JWT. > > Binding a message to HTTP is an option, unfortunately not very universal. > > > > For reference on johnzon ijson support: > https://github.com/apache/johnzon/blob/f9a916200233f8777addcbaf73807067aa7559f6/johnzon-jsonb/src/main/java/org/apache/johnzon/jsonb/JohnzonBuilder.java#L264 > > That is a rather sad interpretation of I-JSON since it doesn't accomplish > what it actually was designed for. > But ijson is nothing more too ATM :(. > > > > > Im still not sure what your goal is, > > Doing what the XML folks have done since 15Y+ back. > This is fine but also doesnt say which parts, if xml means soap you have ws* which is way outside the scope of jsonb. Jaxb doesnt handle signing to be concrete and has the same api than jsonb for marshalling. > > > seems to add the signing in the message but what about properties > conflicts? > > A signature is just another property of a JSON object. You can assign it > a name as any other property. > > Why not give it a try? It won't kill you, I promise :-) > https://mobilepki.org/jose-jcs/verify I know what it is but there is kothing really standard here and will pby not be (well keep standard*s* cause cases are very diversed). So question is: what does the spec miss for your case? Formatting and ordering is in the spec and other parts are ourside jsonb so we are all good right? > > Anders > > > > > > > > > Cheers, > > Anders > > > > > 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] <mailto:[email protected]> > <mailto:[email protected] <mailto: > [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] <mailto:[email protected]> > <mailto:[email protected] <mailto: > [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 > > > >> > > > >> > > > >> > > > >> > > > > > > > > > > >
