Re: [dispatch] Other uses of JCS (JSON Canonicalization Scheme)

Another set of examples are:

1) In the cyber threat intelligence space, organizations, ISACs, ISAOs, vendors, and tools share a lot of indicators of compromise and higher level intelligence (threat actors, campaigns, intrusion sets, TTPs, etc)  that is related in a graph (nodes/vertices and edges). In the ecosystem there can be billions of new objects created on a daily basis.  Each of these are connected to the graph.  The data in the objects is acted on and used all across the ecosystem and is used as linkage to the graph. What is needed is the ability to have a canonical representation of JSON so that it can be hashed and/or digitally signed by a producer so that a consumer will know that it was not modified by a threat actor trying to poison the data.  This community is very large and very stable and needs JCS or something very much like it ASAP.

2) In the CTI space, one often wants to do semantic equivalency checks against nodes in the graph. This can be done by using a deterministic ID method like UUIDv5 from RFC4122 where the “name” is canonicalized JSON.  Another option is using fuzzy hash technologies to see how different various pieces of threat intelligence actually are. In both cases, you need a canonicalization of JSON.  

3) The CACAO work for playbooks and collaborative courses of action will need the ability to like CTI to hash and sign data, but it will also need the ability to layer hashes and signatures and also hash and sign parts of the JSON data.  JCS gives us this ability.  

Some say, well JCS does not work for every conceivable type of data that someone might stick in to a JSON blob.  These individuals would be 100% correct.  But we are not trying to boil the ocean.  Nor solve corner cases and edge cases.  We are trying to solve the 98+% use case.  Further, in the CTI space and in the future CACAO documents, we will be talking about using I-JSON to limit JSON numbers to the IEEE number anyway.  So in this case, the specs will ALREADY support any restrictions that JCS requires.  

Thanks,
Bret
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

> On May 16, 2019, at 7:11 AM, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
> 
> Since the value of clear text messaging has been unilaterally declared to be zero, maybe other and more sophisticated uses of JCS could be of some interest?
> 
> In Saturn[1] JCS is used in many different ways including for signatures and encryption.
> However, the ability to only take a hash of JSON objects has also been put to good work.  Yes, "hashable" JSON is what JCS really is.
> 
> Slightly simplified....
> 1. Merchant creates a signed PaymentRequest in the form of a JSON object and sends it to the User for authorization.
> 2. The User (SW) creates a JSON object with various properties including a timestamp, account ID and a hash of the received PaymentRequest.
> 3. The User (SW) signs the new JSON object using an account- and user-specific authorization private key.
> 4. The User (SW) encrypts the signed JSON object (User authorization) using a bank-specific encryption public key.
> 5. The User(SW) returns the encrypted authorization object + URL to the User's Bank to the Merchant.
> 6. The Merchant puts the PaymentRequest, the encrypted User authorization object and a Merchant receive account in a new JSON object.
> 7. The Merchant counter-signs the new JSON object and sends it to the User's Bank for "redemption".
> 8. The User's Bank verifies the inner and outer Merchant signatures and decrypts the User authorization object.
> 9. The User's Bank verifies that the User authorization object is signed by a key matching the claimed account ID.
> 10. If the hash of the Merchant-supplied PaymentRequest matches that of the hash in the User authorization object the request is considered valid.
> Next follows the actual payment transaction...
> 
> Using JWS as is, the PaymentRequest would need to be duplicated in step #2.
> This may not seem like a big deal but why duplicate data if not necessary?
> 
> JCS is BTW used some 8 times above.
> 
> Quirky, ugly and potentially error-prone signature solutions like TEEP's OTrP also isn't my cup of tea: https://mailarchive.ietf.org/arch/msg/dispatch/ULq1QoecXC0xXu6M5o6m3xPtUPQ
> 
> Thanx,
> Anders
> 
> 1] https://cyberphone.github.io/doc/saturn
> 
> 
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch