Re: [jose] At a glance: JWS vs "in-object" ES6/JSON signatures

Anders Rundgren <anders.rundgren.net@gmail.com> Thu, 29 October 2015 07:08 UTC

Return-Path: <anders.rundgren.net@gmail.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4950E1A8ABF for <jose@ietfa.amsl.com>; Thu, 29 Oct 2015 00:08:09 -0700 (PDT)
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 0P50iO9o0tEi for <jose@ietfa.amsl.com>; Thu, 29 Oct 2015 00:08:07 -0700 (PDT)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 C0EAC1A8A92 for <jose@ietf.org>; Thu, 29 Oct 2015 00:08:06 -0700 (PDT)
Received: by wmff134 with SMTP id f134so18754366wmf.1 for <jose@ietf.org>; Thu, 29 Oct 2015 00:08:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=ttV5JcfiEsGWEcrvClkw+n3dh87j1OS4aXH/5VHAL8w=; b=YN1QSPOdoMOn90YQINNqchlGPdp2n0W94bwetc9M6UOKsoKbgc/pvUJRmyzE/jevS2 eE5DnDLpNr450vpjDqYips8NV6e7DFHXL7GnTmQoIUeQO+yunyrGPqRYmEf3GjffIBDV hN9bwgaLhMQubqJl0UeZ7U5f62UZuV2P1/eYgZG/BpsDQ0WE1sJ/bnHEGPn8UqHpNLMs a1M9jkSPqOXBjOSOobUOsitl+369jvpVEh3rJZnrDjYotJw26HzoWDAGDAlRyG3OJxbE B68UVw+zwzTz9LOnffj6UtZcryFC8sz/6eICsSduJLMGa8WJar+r9BNio3aEmsYPBZgK UyFw==
X-Received: by 10.28.23.208 with SMTP id 199mr1578268wmx.11.1446102485307; Thu, 29 Oct 2015 00:08:05 -0700 (PDT)
Received: from [192.168.1.79] (148.198.130.77.rev.sfr.net. [77.130.198.148]) by smtp.googlemail.com with ESMTPSA id w66sm1929189wme.11.2015.10.29.00.08.04 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Oct 2015 00:08:04 -0700 (PDT)
To: Mike Jones <Michael.Jones@microsoft.com>, "jose@ietf.org" <jose@ietf.org>
References: <5631BF2A.70109@gmail.com> <BY2PR03MB442AAE04D574F870B1C3D77F5200@BY2PR03MB442.namprd03.prod.outlook.com>
From: Anders Rundgren <anders.rundgren.net@gmail.com>
Message-ID: <5631C5CE.7030807@gmail.com>
Date: Thu, 29 Oct 2015 08:07:58 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <BY2PR03MB442AAE04D574F870B1C3D77F5200@BY2PR03MB442.namprd03.prod.outlook.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/jose/98WDwArMKybPQNR56VA4rEvYxjs>
Subject: Re: [jose] At a glance: JWS vs "in-object" ES6/JSON signatures
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jose/>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Oct 2015 07:08:09 -0000

On 2015-10-29 07:44, Mike Jones wrote:
> This may be just my personal opinion, but preserving member creation order is only one small part of producing canonical JSON, which would be what would be required for such a scheme to be guaranteed to work.  For instance, if the value 1e3 is part of the JSON input, will JSON.stringify() be guaranteed to emit it as 1e3, or might it be 1E3 or 100?  Unless it's deterministic, different serializers will produce different results, and therefore different signatures.  Without a canonical JSON being both defined and widely deployed, I can't recommend doing any work that requires a canonical JSON representation to deterministically succeed.

Mike,
There is no absolute need for a canonical format, but normalization of numbers is as you mention not without challenges.
However, as described in the linked document there is a pretty simple "workaround" which I believe is fully ES6-compatible.

It certainly isn't ideal building standards on workarounds but pragmatism apparently ruled when Ecma specified ES6 property order so why couldn't the same thinking be used for signatures?  The workaround could maybe even go away with a future ES iteration if the Ecma ES committee is notified of the issue.

Anyway, this is not [at all] about dismissing JWS, it is about offering an alternative which has some pros and cons versus JWS. The in-object scheme cannot easily deal with multiple signature for example.

Regarding non-ES parsers, I don't see that as a showstopper; JavaScript is the origin of JSON and now it has changed.

Cheers,
Anders

>
> 				-- Mike
>
> -----Original Message-----
> From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Anders Rundgren
> Sent: Wednesday, October 28, 2015 11:40 PM
> To: jose@ietf.org
> Subject: [jose] At a glance: JWS vs "in-object" ES6/JSON signatures
>
> ES6-compliant in-object JS/JSON signature:
>
>     var inObjectSignedData =
>       {
>           // Object data expressed as JS properties
>           "device": "Pump2",
>           "value": 1e-18,
>
>           // Object signature
>           "signature": {
>               ...Protected headers + Signature value expressed as JS properties...
>           }
>       };
>
> JavaScript's JSON.parse() and JSON.stringify() suffice for "canonicalization" purposes.
>
>
> Converting the above to JWS JSON Serialization you would get:
>
> var signedData =
>     {
>         // Object data in a coded format
>         "payload":"<payload contents>",
>
>         // Protected headers wrapped in Base64URL
>         "protected":"<integrity-protected header contents>",
>
>         // Signature in a unique format
>         "signature":"<signature contents>"
>     }
>
> ES6 was released in June 2015 so this opportunity is actually quite new.
>
> Cheers,
> Anders
>
> http://webpki.org/ietf/draft-rundgren-predictable-serialization-for-json-tools-00.html#rfc.section.3.3
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose