Re: [Acme] [jose] [Json] Signed JSON document / Json Content Metaheader / JSON Container

Anders Rundgren <anders.rundgren.net@gmail.com> Thu, 29 January 2015 14:26 UTC

Return-Path: <anders.rundgren.net@gmail.com>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A27A1A19E9; Thu, 29 Jan 2015 06:26:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
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 bawPE3Lrrwaf; Thu, 29 Jan 2015 06:26:08 -0800 (PST)
Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59B291A03A3; Thu, 29 Jan 2015 06:26:08 -0800 (PST)
Received: by mail-wg0-f46.google.com with SMTP id l2so23310306wgh.5; Thu, 29 Jan 2015 06:26:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=wK9ZOHRUr2sBy1X727+94m2OGRidRCqFrFp+aqgrnXM=; b=H+Uohog/YHqX93EFJbOEZXgSFqzrPPuEWd17kq1Es+8jM8nBracEzrFQgcVkPqX77i lac9Zn/ixhdzfQve+EFKTfNjZDqCmQG4hxJD0K5Cz9zjfkuoiKuVOdkdjNi4yMBJovkL 5lkXW/d0QBrV90gSJH5BMBFMh4x1KLpl2sMioonFTd0oTFU4RMsqYA0/OecN6x68oJIm nZvpTP03ha+Fv9UnagKTH45Fk5eHKG5QqIUbsQoCRDAFNDHUpb5zVvkYhyDmweyaCE/P sOqWNlg6kpIC/3IC1b3WembyWvlQi11HtR7EUMXK2Y7r1N18ge/z3mluVgtMS/2djO/Q dpfg==
X-Received: by 10.194.236.200 with SMTP id uw8mr1895478wjc.10.1422541566905; Thu, 29 Jan 2015 06:26:06 -0800 (PST)
Received: from [192.168.1.79] (48.194.130.77.rev.sfr.net. [77.130.194.48]) by mx.google.com with ESMTPSA id bb2sm10678480wjc.43.2015.01.29.06.26.05 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Jan 2015 06:26:06 -0800 (PST)
Message-ID: <54CA42FC.7040201@gmail.com>
Date: Thu, 29 Jan 2015 15:26:04 +0100
From: Anders Rundgren <anders.rundgren.net@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Justin Richer <jricher@mit.edu>, Fraser Tweedale <frase@frase.id.au>, Phillip Hallam-Baker <phill@hallambaker.com>
References: <CAMm+Lwh12jzrH3ZVaS4HTqkNZkteg9mL+n6LYRsj5P1r-Q-DbQ@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E1284ED9AA38@WSMSG3153V.srv.dir.telstra.com> <CABzCy2DTa+2usPhGJRX7kq8vdxaC+LgAEgoZWNiBmaQNOaYdEg@mail.gmail.com> <CAMm+Lwirvv5tLU-2AEqnQe9DUDKT=GbJK9Jyy69BJVfeDZjCiA@mail.gmail.com> <20150129042508.GA4845@bacardi.hollandpark.frase.id.au> <54C9C765.7080604@gmail.com> <54CA3242.10109@mit.edu>
In-Reply-To: <54CA3242.10109@mit.edu>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/YLAUZzkB2QzMTD0qNZwS5iU5St4>
Cc: "Manger, James" <James.H.Manger@team.telstra.com>, "acme@ietf.org" <acme@ietf.org>, Nat Sakimura <sakimura@gmail.com>, "jose@ietf.org" <jose@ietf.org>
Subject: Re: [Acme] [jose] [Json] Signed JSON document / Json Content Metaheader / JSON Container
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Jan 2015 14:26:12 -0000

On 2015-01-29 14:14, Justin Richer wrote:
> Relying on side-effects of a handful of contemporary implementations is
> dangerous at best and absolutely foolhardy at worst, especially when it
> comes to security systems. You *need* to have a formal canonicalization,
> normalization, or serialization in order for these things to work in
> practice.

You are right: JCS isn't guaranteed to run on any JSON implementation.

However, JCS doesn't rely on side-effects, it has a formal normalization
scheme (the description may be crap but there is one at least), which is
explicitly implemented in two (yes, only two) reference implementations.

Then I have with the help of available documentation and communication
with the authors, verified that two "commercial" JSON implementations
also can support "predictive serialization" which BTW is a requested
item by the general JSON community for the simple reason that humans
(unlike computers) find it somewhat odd that if you define properties
A,B,C they come out as A,C,B.

The only (known NB) "fly in the soup" is that floating-point serialization
usually requires some specific measures to work as mandated by the JCS
normalization scheme.  If this is a show-stopper and can't be corrected,
your best option is using JWS of course.  The idea was never ever to
"compete" but to "complement".  I have adjusted the JCS during the voyage
so that it nowadays reuses JOSE algorithms, curves, public key objects, and
signature blob format.  "Crypto compatible".

> Otherwise, you're betting on luck, and that's just daft.

Since I don't consider myself a gambler, I guess I have to settle on "daft" then :-)

Anders


>
>    -- Justin
>
> On 1/29/2015 12:38 AM, Anders Rundgren wrote:
>> On 2015-01-29 05:25, Fraser Tweedale wrote:
>> Hi Fraser,
>>
>>> I agree the JSON ship has sailed, but there *are* drawbacks.
>>
>>
>> The JSON ship may have sailed but it is actually more like a dinghy when
>> look closer making a turn or two fairly realistic.
>>
>> Using predictable serialization which is anything but rocket-science,
>> "canonicalization" can [often] be reduced to "stringify":
>>
>> https://openkeystore.googlecode.com/svn/resources/trunk/docs/jcs.html
>>
>> https://code.google.com/p/openkeystore/source/browse/python/trunk/src/org/webpki/json
>>
>> https://code.google.com/p/openkeystore/source/browse/resources/trunk/docs/JCSDemo.cs
>>
>>
>> Anders
>>
>>> On Wed, Jan 28, 2015 at 11:03:05PM -0500, Phillip Hallam-Baker wrote:
>>>> On Wed, Jan 28, 2015 at 9:57 PM, Nat Sakimura <sakimura@gmail.com>
>>>> wrote:
>>>>
>>>>> On a side note: if such a spec is to be defined here, IMHO, it
>>>>> should use
>>>>> the algorithms and probably header parameters specified by JWA,
>>>>> etc. It
>>>>> should limit the scope to payload processing and expression of the
>>>>> entire
>>>>> thing in JSON Log like format, and leave the rest to JOSE.
>>>>>
>>>>
>>>> Absolutely. In fact that is why I am not raising it in JOSE as that
>>>> just
>>>> provides the format for the main crypto attributes.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> On Thu Jan 29 2015 at 11:51:24 Manger, James <
>>>>> James.H.Manger@team.telstra.com> wrote:
>>>>>
>>>>>> A signed JAR file meets some of these requirements.
>>>>>>
>>>>>> Metadata and signatures are in extra files in the ZIP archive:
>>>>>> META-INF/MANIFEST.MF, META-INF/MYKEY.SF, META-INF/MYKEY.RSA.
>>>>>>
>>>>>> Content is the other files in the archive.
>>>>>>
>>>>>> It is not JSON of course, and the signature & certs are packaged in
>>>>>> ASN.1, but it is a useful comparison. It avoids BASE64 on the
>>>>>> content; can
>>>>>> adds signatures, digests, and other metadata; can transport
>>>>>> content and
>>>>>> metadata as a regular blob (*.jar file); can sign complete code
>>>>>> distributions.
>>>>>>
>>>>>>
>>>>>>
>>>> I have used signed jar files. But Sun rather poisoned the well there by
>>>> suing Microsoft over control of Java followed up by further lawsuits
>>>> from
>>>> Oracle.
>>>>
>>>> I can't imagine anyone is going to accept Jar or anything involving
>>>> assinine.1 as a wire format for packaging. Those days are long past.
>>>> The
>>>> way you get coherence is to pick one encoding and stick to it. JSON
>>>> seems
>>>> to have been the one we picked. It has all the functionality offered
>>>> by the
>>>> alternatives and none of the drawbacks.
>>>
>>> There are ∞ valid ways to serialise a JSON object.  If a JSON object
>>> is signed over, it must be canonicalised, or signed over and
>>> transported in serialised form.  JOSE takes the latter approach
>>> (base64url-encoded serialised JSON object, inside a JSON object),
>>> while JWK thumbprint draft uses canonicalisation.  ASN.1 encodings
>>> and deterministic binary serialisations can avoid the need for these
>>> sorts of hacks.
>>>
>>> I agree the JSON ship has sailed, but there *are* drawbacks.
>>>
>>> Regards,
>>> Fraser
>>>
>>>> _______________________________________________
>>>> Acme mailing list
>>>> Acme@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/acme
>>>
>>>
>>>
>>> _______________________________________________
>>> Acme mailing list
>>> Acme@ietf.org
>>> https://www.ietf.org/mailman/listinfo/acme
>>>
>>
>> _______________________________________________
>> jose mailing list
>> jose@ietf.org
>> https://www.ietf.org/mailman/listinfo/jose
>