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

Bret Jordan <jordan.ietf@gmail.com> Wed, 23 January 2019 10:48 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 DB639130E46 for <json-canon@ietfa.amsl.com>; Wed, 23 Jan 2019 02:48:14 -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 l4AV6R6rLGoE for <json-canon@ietfa.amsl.com>; Wed, 23 Jan 2019 02:48:12 -0800 (PST)
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 7EC2B12E04D for <json-canon@ietf.org>; Wed, 23 Jan 2019 02:48:11 -0800 (PST)
Received: by mail-ed1-x52d.google.com with SMTP id a20so1295024edc.8 for <json-canon@ietf.org>; Wed, 23 Jan 2019 02:48:11 -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=+/Afg/bc1u0unQPu6PxMV1mRhkLC/Pb0fhjVOcRfXRs=; b=b1QWSQjihTo9xJ6b7q8X68H1pE8147jiM+g4raJ1ILl/efZU1jHOe17UgEqB7lomCA nytfAxqdCvnHGH8GujZIvSh2gxuzKyS74KM3fM88OnDLlCy6zcJnq+kbzNZl1igIgaGN owN+8zV3TkCE80GvOMR+4A/JmKkeK6IE3uf+dzXrZmQZpqSxwFjVA3KiCMq8Ko12vG7U X28e2lxMPEIVbPtRgzTYSEHs3Mbb5Sz9mVZyUkDffrmbrsofTaPVNEeM7M4Xx99GiHT2 ICvv02jNNp2nseg1z0TK2L0HmdsotazEvFA30xaE+IdeimIoe1EvAtmz19Mq12gtvE9Q f3Nw==
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=+/Afg/bc1u0unQPu6PxMV1mRhkLC/Pb0fhjVOcRfXRs=; b=cX/UB9nLfFuf3P9YfmKnNPeHeOFXhuIWQFzVKZH2mPmaWlre8AJdLjEY7LSkyRx5xy LJhw+UFOwvOUA1YbXe3sqtfsrM21FddSNrNXCyuZAeheWVuxmhiweHVKp7sqn4drAZaW qLGms3IpdvTWZr7MIdcKojwaInJjbkKifK7DXYQts14ZwK0DEGkmPzcvQcHzWjbV+dxn GZ1T8yvbqhrwKL/oBObW/K/VslX9cyLsaBw8xsZsUXF/HXX+nxoALQkvhYzMYLlFxGCk DRiflRO0oxDyMHxMLfaK3yU0odmeSkINj5JA70h8Y/0KFwiKJrMQtZzUwkR2K+dXlSO6 FnJw==
X-Gm-Message-State: AJcUukdW2qn6ZhlW8oIUHbwX3gvvHJkX3ffkts0oCFRPcq3w2h5WofTM JChvztBensmiEMjQvfhEpjh0tA2p
X-Google-Smtp-Source: ALg8bN5w6C7y6ss3QORfAIHWA8PAW7YJmlfJm6LpshkBfCy9RdANcXye2XJl8m31a1s0qvWavx3jLA==
X-Received: by 2002:a50:afa3:: with SMTP id h32mr2222333edd.150.1548240489792; Wed, 23 Jan 2019 02:48:09 -0800 (PST)
Received: from [156.106.225.150] ([156.106.225.150]) by smtp.gmail.com with ESMTPSA id i46sm10156373eda.37.2019.01.23.02.48.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Jan 2019 02:48:09 -0800 (PST)
From: Bret Jordan <jordan.ietf@gmail.com>
Message-Id: <FA88BB03-ADA7-49EB-AE71-7750BFE71013@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4EFC3AE0-8BDC-4252-AA4A-5E98EC757240"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Wed, 23 Jan 2019 11:47:56 +0100
In-Reply-To: <40731AB0-9640-4D74-99B3-EC6E7A51850B@tzi.org>
Cc: Richard Struse <rjs@mitre.org>, "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>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/json-canon/ABee9TTf7afsUSlORQOH0ir8aBs>
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 10:48:15 -0000

Carsten,

Here are two examples…

1) Creating deterministic IDs for STIX Cyber Observables.  STIX Cyber Observables are simple JSON blobs (think network traffic, file data, email data, etc) of data and we define for each object what properties should be used for the ID.  And when you build out your graph, you do not want a million vertices for the same thing.  You want to be able to just relate things together in a deterministic way. 

So say you have something super super simple like this file object:

{
  "type": "file",
  "hashes": {
    "SHA-256": "fe90a7e910cb3a4739bed9180e807e93fa70c90f25a8915476f5e4bfbac681db"
  },
  "size": 25536,
  "name": "foo.dll"
}

You would want to be able to treat this as a string that you could pipe in to some hashing algorithm.  So you would want something like this:

Id := Sha256hash(<JSON DATA>)


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


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
>