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

Anders Rundgren <anders.rundgren.net@gmail.com> Thu, 29 January 2015 05:38 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 E9F761A8BC1; Wed, 28 Jan 2015 21:38:55 -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 bsOdZ3hEJoQ3; Wed, 28 Jan 2015 21:38:52 -0800 (PST)
Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (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 5EAA51A8BB1; Wed, 28 Jan 2015 21:38:52 -0800 (PST)
Received: by mail-wi0-f170.google.com with SMTP id bs8so4767616wib.1; Wed, 28 Jan 2015 21:38:51 -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=g+Wal+x6H83KcEl3DvwZ2gitgI5r3t3f2meSx5Ch+CY=; b=qncVj/JPPT8lzv+hiZO0sph45Pyglt6iDBpEWTf18p04P50VarYzRnPt+LqZqVFNq1 M7zHrH2IKC8Gq97uWz4wDX1fZiE8iB8o7Gont21su73HFiDBa0Ar5IUT/qXsA122MtYD /vlSAZ2AmUEPqxvMqPMuPhGe7FnQiFuGEjqDW0z7z3HB57E/CZDh0+Qyv0zPbUw0NMG2 Tegguda6Nlmx4hMlwyKM69QpZWwXr78EX9LmBcsrpUn7qk1/2UJsPJSz5wUW+vYXpMZB aTlPbI6pC1OOywqsIh3tAkk8RoaU2MXDOld2RHxDeP8zkiktW9z2f2Ug5NGVTsK/Rjaj oT3g==
X-Received: by 10.180.72.199 with SMTP id f7mr822923wiv.58.1422509931176; Wed, 28 Jan 2015 21:38:51 -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 dc1sm887196wib.18.2015.01.28.21.38.49 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Jan 2015 21:38:50 -0800 (PST)
Message-ID: <54C9C765.7080604@gmail.com>
Date: Thu, 29 Jan 2015 06:38:45 +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: 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>
In-Reply-To: <20150129042508.GA4845@bacardi.hollandpark.frase.id.au>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/KLbBnpdxpB9K8d7SbY8cAdpwg-E>
Cc: Nat Sakimura <sakimura@gmail.com>, "acme@ietf.org" <acme@ietf.org>, "Manger, James" <James.H.Manger@team.telstra.com>, "jose@ietf.org" <jose@ietf.org>
Subject: Re: [Acme] [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 05:38:56 -0000

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
>