johnzon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anders Rundgren <anders.rundgren....@gmail.com>
Subject Re: Digitally Signed JSON
Date Mon, 14 May 2018 20:36:40 GMT
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.

> 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.

>
> Im still not sure what your goal is, 

Doing what the XML folks have done since 15Y+ back.


> 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

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
View raw message