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

Bret Jordan <jordan.ietf@gmail.com> Wed, 23 January 2019 13:09 UTC

Return-Path: <jordan.ietf@gmail.com>
X-Original-To: json-canon@ietfa.amsl.com
Delivered-To: json-canon@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D73E126F72 for <json-canon@ietfa.amsl.com>; Wed, 23 Jan 2019 05:09:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9J52eJGYkPG0 for <json-canon@ietfa.amsl.com>; Wed, 23 Jan 2019 05:09:27 -0800 (PST)
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 456DE1228B7 for <json-canon@ietf.org>; Wed, 23 Jan 2019 05:09:27 -0800 (PST)
Received: by mail-ed1-x529.google.com with SMTP id b3so1670472ede.1 for <json-canon@ietf.org>; Wed, 23 Jan 2019 05:09:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=PvxwcU3HbnqsdtCrsBObwNJaIJs7lWeJGp1Lqs2eFfY=; b=jsv+T9cyqiFYoJa7e1W4zKnS6qWX5iTrjA3bmDinjcsxT9GmDbvKExc1IbNX0y31oJ nfFXfjqnyKncTPNQ/tXJEIgFLkyL0R/MCF7V9ZOss8qUTJGIz7yqR+DYlpzSmbe1jPPU 9giJ9FlHjTKrRYap5OlDQl3SC7Z1MY+CupaPkOgvjCoPzPnB4+z1M/4tGbxm05UPI/pN /lNacoUVwRO5sPVsj4e8x6WCKuUVdy8/3WCYzM3QztO4PtdwFAHTkun9lZbFWB+1tGFr neAE2jfnPj1mylfOKevbBE1oEzeiFKPzqH66uK7q6Qsgf+gXEVYptBbVhtJYXfvJLh2w e5DA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=PvxwcU3HbnqsdtCrsBObwNJaIJs7lWeJGp1Lqs2eFfY=; b=c/Z6HJjUPDhD9oy2RcDKS7GbxrNp+1tt6tb8iIUuVIagOZ09Lzntf3MYaaEJeC0Ywr FBpnsI+n7Pr8kyNAoB0XV6Gm5Tju5tFJ9zmxY3HXe5Gsbxw/BE49rexWyZ3s5C4/LSrh NxuPXdWcHEIoF1Fz+qC7ekEcH02bcV9imDmw4VV7aos44QzgOpNBBRqIpgoSB8vWiWJm OyLmDpsGS+aP0Rz7SKFAFuBa2VUJwn3SaKdID+hHE/Lcd8Dx/QPWfLTsQoDLzLBsLqOY PlkgvvUejGDRgQU2W38fUi8DiJZ9xERj/XtqzZcwPJSklMVmk8yZEBG2l/2u9iJDoL9p VU9w==
X-Gm-Message-State: AJcUukfIHjVHRKyvLSFDgW7AA9GEEtXIhLBZTHg0KiOeGvr9thUPXHiw kWgR0QbbrlLLQZtqbM4LQCEC+KQx
X-Google-Smtp-Source: ALg8bN5RZ8uq4aIaj5OMk1+9I3+4TqjoooXx1BfmseiNOombGWi9EvHPFaDZY5QrCjaxs17NckGK0w==
X-Received: by 2002:a17:906:2287:: with SMTP id p7mr1584481eja.173.1548248965688; Wed, 23 Jan 2019 05:09:25 -0800 (PST)
Received: from [156.106.225.150] ([156.106.225.150]) by smtp.gmail.com with ESMTPSA id p24sm6799ejz.46.2019.01.23.05.09.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Jan 2019 05:09:24 -0800 (PST)
From: Bret Jordan <jordan.ietf@gmail.com>
Message-Id: <A37C3DD6-65F9-4B6B-BCAC-FE0DCC10D1FB@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B0C11E98-54B8-4F99-82CE-BBEBE70022EF"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Wed, 23 Jan 2019 14:09:08 +0100
In-Reply-To: <100898B7-CCA6-4B00-895F-AD39AAAEF052@tzi.org>
Cc: "json-canon@ietf.org" <json-canon@ietf.org>
To: Carsten Bormann <cabo@tzi.org>
References: <38C84459-3D2E-4E78-BF48-FE277388E33A@contoso.com> <21415_1547794000_5C417650_21415_473_1_34A23FAA-C8F5-40E3-8358-FD42C5F78126@tzi.org> <60B977A0-0958-4DDF-A666-A44F074E5946@mitre.org> <CBC45241-0BBB-410C-AF8C-9D49C642566B@tzi.org> <00243004-7200-4887-BB46-ED30D03C4545@gmail.com> <40731AB0-9640-4D74-99B3-EC6E7A51850B@tzi.org> <FA88BB03-ADA7-49EB-AE71-7750BFE71013@gmail.com> <100898B7-CCA6-4B00-895F-AD39AAAEF052@tzi.org>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/json-canon/fTD4AbwC25f1p1ZxARPD2k4PI70>
Subject: Re: [Json-canon] [EXT] Re: Support for a WG
X-BeenThere: json-canon@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: JSON Canonicalization <json-canon.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json-canon>, <mailto:json-canon-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/json-canon/>
List-Post: <mailto:json-canon@ietf.org>
List-Help: <mailto:json-canon-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json-canon>, <mailto:json-canon-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Jan 2019 13:09:31 -0000

I would probably point you to this site that we put together. However, if there is something specific you would like to know, I can answer that.  Or we can schedule a WebEx and I can walk you through it. 

https://oasis-open.github.io/cti-documentation/ <https://oasis-open.github.io/cti-documentation/>


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 1:22 PM, Carsten Bormann <cabo@tzi.org> wrote:
> 
> 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 <cabo@tzi.org> 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 <jordan.ietf@gmail.com> 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 <cabo@tzi.org> wrote:
>>>>> 
>>>>> Hi Richard,
>>>>> 
>>>>>> On Jan 22, 2019, at 13:31, Struse, Richard J. <rjs@mitre.org> 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
>>>>> json-canon@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/json-canon
>>>> 
>>>> -- 
>>>> json-canon mailing list
>>>> json-canon@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/json-canon
>>> 
>> 
>> -- 
>> json-canon mailing list
>> json-canon@ietf.org
>> https://www.ietf.org/mailman/listinfo/json-canon
>