Re: [jose] draft-ietf-jose-json-web-signature ; flattened serialization

Sergey Beryozkin <sberyozkin@gmail.com> Wed, 29 October 2014 10:05 UTC

Return-Path: <sberyozkin@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 1D5B91A3BA3 for <jose@ietfa.amsl.com>; Wed, 29 Oct 2014 03:05:03 -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 NSpiMq72jjdr for <jose@ietfa.amsl.com>; Wed, 29 Oct 2014 03:05:00 -0700 (PDT)
Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 011071A702F for <jose@ietf.org>; Wed, 29 Oct 2014 03:04:59 -0700 (PDT)
Received: by mail-wi0-f181.google.com with SMTP id n3so4085750wiv.8 for <jose@ietf.org>; Wed, 29 Oct 2014 03:04:58 -0700 (PDT)
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=483rJV26idngPGqDd8b4U0ELHff+FOldRP1Zf/8qK2c=; b=zaRivWvmaU77VfEb8cLvpVucZ8Yt2lY8lGWpOJwi606B1q5Wkev1P5daw/RjQ172tJ yM5yuNBiow5agqRjQFWdUOQExrwuS4KcxBExOpUtl79NAfWhMkJe7fkzlx0rQ/AOj77k Jbn9BS9c3DzS7KixnnGYqDHvLhTzWO9oeOylUgr4MX4PscA1s3MfQLo0GwK4pmOCfjPf hdo9t987DuZ1zlo2ezSs6vaCgPyGIaDprJgeKZM+/jcS+d+OJSUqlkDvS0ehXlFx+fcS dFuZB/tJXMo60NFgzUC73nKpfk3CbSGpve4LDM60G9wqrayO/t+knEMXqk7fKMUpmrF2 ejUQ==
X-Received: by 10.194.91.144 with SMTP id ce16mr11343293wjb.101.1414577098634; Wed, 29 Oct 2014 03:04:58 -0700 (PDT)
Received: from [192.168.2.7] ([109.255.82.67]) by mx.google.com with ESMTPSA id cs2sm18192163wib.2.2014.10.29.03.04.57 for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Oct 2014 03:04:57 -0700 (PDT)
Message-ID: <5450BBB9.7080905@gmail.com>
Date: Wed, 29 Oct 2014 10:04:41 +0000
From: Sergey Beryozkin <sberyozkin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Mike Jones <Michael.Jones@microsoft.com>, Fraser Tweedale <frase@frase.id.au>, "draft-ietf-jose-json-web-signature@tools.ietf.org" <draft-ietf-jose-json-web-signature@tools.ietf.org>, "jose@ietf.org" <jose@ietf.org>
References: <20141029041043.GC55748@bacardi.hollandpark.frase.id.au> <4E1F6AAD24975D4BA5B16804296739439BB2FE2B@TK5EX14MBXC286.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BB2FE2B@TK5EX14MBXC286.redmond.corp.microsoft.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/jose/Oi9ZYgIaklEJmWW-lxALIxTT_wU
Cc: Richard Barnes <rlb@ipv.sx>
Subject: Re: [jose] draft-ietf-jose-json-web-signature ; flattened serialization
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: <http://www.ietf.org/mail-archive/web/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: Wed, 29 Oct 2014 10:05:04 -0000

Our project has recently got the initial JWE Serialization code added in 
(from FH Köln contributors).

I agree with Fraser. It's an obvious case of the premature optimization, 
we are talking about saving 10-15 bytes of the payload at the cost of 
introducing two JWS Serilaization variants with the flattened option 
mostly duplicating what JWS Compact Serialization can do.

It won't affect us much because the default JSON parsing in our case is 
not 'stream-aware'. Probably not a big deal over all but I just wanted 
to support Fraser's comments

Sergey



On 29/10/14 04:25, Mike Jones wrote:
> Thank you for your feedback, Fraser.  It would be useful to hear from others who have implemented the JSON Serializations whether they agree with Fraser or Richard.
>
> 				-- Mike
>
> P.S.  The list you sent it to reached the editors and chairs.  The jose@ietf.org list reaches the whole JOSE working group.
>
> -----Original Message-----
> From: Fraser Tweedale [mailto:frase@frase.id.au]
> Sent: Tuesday, October 28, 2014 9:11 PM
> To: draft-ietf-jose-json-web-signature@tools.ietf.org
> Subject: draft-ietf-jose-json-web-signature ; flattened serialization
>
> Hello,
>
> (I am not familiar with IETF WG processes so I hope I am communicating in a useful way and in the right place.)
>
> JWS draft 36 adds a "flattened JWS syntax" for the case where there is a single signature.  A similar change was made for JWE in the single recipient case.
>
> Richard Barnes proposed these changes on the following basis:
>
>      ``I've had several implementors trying to use JWS in the JSON
>      serialization ask why it was necessary to include a "signatures"
>      array in cases where there's only one signer.  It seems like this is
>      going to be a major barrier to deployment and re-use.''
>
> I am the author of a Haskell JOSE library
> (http://hackage.haskell.org/package/jose) and object to these changes on the following bases:
>
> - They add substantial complexity to the parsing of JWS and JWE
>    objects (which is already complex).
>
> - The nature of the "optimisation" for the single-signature case is
>    unclear.  If the optimisation is for compactness, this is obviated
>    by "7.2. JWE JSON Serialization" which states ``This
>    representation is neither optimized for compactness nor
>    URL-safe.''  If the optimisation is for simplicity, it is a false
>    economy.
>
> - The fact that implementors were asking about this part of the spec
>    does not imply an impediment to deployment and re-use.  (Perhaps
>    comments to this effect were in fact made, but as written the
>    justification is speculative.)
>
> The wish for a "simpler" serialization for a common use case is understandable, but this is a case of "be careful what you wish for".  Commentary to the effect of "the signatures array is used even when there is a single signature/recipient to keep parsing as simple as possible" would give implementors the answer to this question and relieve them of the additional complexity required to support the Flattened Serialization in addition to the General Serialization.
>
> Please consider reverting this recent change to the specification.
>
> Regards,
>
> Fraser Tweedale
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>