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
