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 Tue, 15 May 2018 11:05:24 GMT
Le lun. 14 mai 2018 21:36, Anders Rundgren <anders.rundgren.net@gmail.com>
a écrit :

> On 2018-05-14 19:40, Romain Manni-Bucau wrote:
> >
> >
> > Le lun. 14 mai 2018 17:12, Anders Rundgren <
> anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> 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 <
> anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>
> <mailto:anders.rundgren.net@gmail.com <mailto:
> 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 <mailto:anders.rundgren.net@gmail.com>
> <mailto:anders.rundgren.net@gmail.com <mailto:
> 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