Re: [Json-canon] [EXT] Re: Support for a WG

[Carsten Bormann <[e-mail]>]

Hi Bret,

> 1) Creating deterministic IDs for STIX Cyber Observables.  

Now that is very concrete!  Thank you.
What would be the best reference I could use to learn how STIX uses JSON?

> 2) Creating digital signatures for JSON objects using the JSON data “as-is”.  

Right, that is one very general use case, but as Allan and I hinted, it may be worth looking at the JSON data in a bit more detail.  Using Richard’s problem statement:

“two objects, each with the same contents, having the same hash value based on their representation in JSON.”

This has this gaping hole what “same contents” actually mean.
So far, I-JSON (RFC 7493) is the closest we have to a specification of the generic data model with which we are using JSON as an interchange format.
Maybe that is all we need, but that remains to be verified — best in the context of the applications that actually have a concept of what “same contents” would be.

So I still think analyzing a few applications would be a good thing before we can claim the generic use case (2) is covered.

Grüße, Carsten


> 
> 
> 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 Jan 23, 2019, at 11:32 AM, Carsten Bormann <[e-mail]> wrote:
>> 
>> Hi Bret,
>> 
>> I’ve been in your shoes.
>> “It’s not that complicated.”  Yeah.
>> 
>> Allan already hinted at one possible complication.
>> You can of course declare that (very real!) issue out of scope.
>> But that is easier done if we know why we are doing this.
>> 
>> What’s so difficult about actually saying what the use cases are?
>> I’m not trying to suggest there needs to be an RFC that documents every single use case before there can be any work on the solution (I’m saying this because unfortunately we have had process hangups like this before and there simply is no need for this).
>> Instead, this mailing list is a great place to have some discussion on the use cases so the requirements are better understood.
>> “We want this because some people are telling us it’s easy” is not the level of discussion that can help with this.
>> 
>> On the solution side, having a solution but not having a well-understood description of what it does and what it does not is dangerous.  Even more so when some of the use cases have security considerations.
>> 
>> After all, the IETF would not be doing this solution as an ultimate goal — the point is that other protocols can build on top of this solution, and as we want to achieve interoperability (and maintain security), we need to know what the solution does and what requirements it places on its usage to actually achieve its desired properties.
>> 
>> Grüße, Carsten
>> 
>> 
>>> On Jan 23, 2019, at 10:27, Bret Jordan <[e-mail]> wrote:
>>> 
>>> Carsten,
>>> 
>>> I do not see what the hang up is for doing this. There is a document that proposes a very nice solution.  There are libraries for various programming languages that can do this.  What we need is a standard that people can reference when they want to use it.  At the end of the day people, organizations, vendors, and groups need a way of dealing with white space, ordering, and the JSON Number type in a consistent way.  They do not want to use CBOR, ASN.1, XML, or anything else.  The market wants to use plain and simple JSON. Right now we have various groups and organizations going off and doing their own form of this. It will save a lot of pain if we could just, finally, standardize this. 
>>> 
>>> Lets not make this overly complicated.  Organizations, vendors, other standards, and other working groups want the ability to use JSON “as-is” and perform security operations on that string of data.  To do this, we need a canonical string of data that can be consistently generated.   
>>> 
>>> 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 Jan 22, 2019, at 7:05 PM, Carsten Bormann <[e-mail]> wrote:
>>>> 
>>>> Hi Richard,
>>>> 
>>>>> On Jan 22, 2019, at 13:31, Struse, Richard J. <[e-mail]> wrote:
>>>>> 
>>>>> The use case is to enable other standards that use a JSON serialization to be able to count on two objects, each with the same contents, having the same hash value based on their representation in JSON.
>>>> 
>>>> Well, that is the technical requirement, but what do you use this property for?
>>>> 
>>>> JSON was discovered/presented around 2002 and so far has worked quite well without this property.  What use cases have sprung up that now need it?
>>>> 
>>>> I’m asking because for many use cases I have heard, there actually are better technical approaches than canonicalization.  Having said that, CBOR, a data format defined in 2013, does have recommendations for deterministic encoding (“canonicalization”), which turned out to be useful for instance for test scripts.  One thing we found out quickly is that deterministic encoding is dependent on the application concept of equality, so it is hard to define a single variant of it for a serialization used in multiple applications.  One more reason to find out about use cases.
>>>> 
>>>> Grüße, Carsten
>>>> 
>>>> -- 
>>>> json-canon mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/json-canon
>>> 
>>> -- 
>>> json-canon mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/json-canon
>> 
> 
> -- 
> json-canon mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/json-canon