Re: [jose] Whether implementations must understand all JOSE header fields

"Manger, James H" <> Wed, 19 December 2012 05:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8C93121E802E for <>; Tue, 18 Dec 2012 21:12:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.752
X-Spam-Status: No, score=-0.752 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Vhhod2u1lvGG for <>; Tue, 18 Dec 2012 21:12:08 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 3DDE421F85EE for <>; Tue, 18 Dec 2012 21:12:06 -0800 (PST)
X-IronPort-AV: E=Sophos; i="4.84,315,1355058000"; d="scan'208,217"; a="110494045"
Received: from unknown (HELO ([]) by with ESMTP; 19 Dec 2012 16:12:05 +1100
X-IronPort-AV: E=McAfee;i="5400,1158,6930"; a="102950993"
Received: from ([]) by with ESMTP; 19 Dec 2012 16:12:04 +1100
Received: from ([]) by ([]) with mapi; Wed, 19 Dec 2012 16:12:04 +1100
From: "Manger, James H" <>
To: Mike Jones <>, "" <>
Date: Wed, 19 Dec 2012 16:12:03 +1100
Thread-Topic: [jose] Whether implementations must understand all JOSE header fields
Thread-Index: Ac3da4u39ZRiYSLMQBShe+M/5UR54QAALdFQAAH0xRAAByH0sA==
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US, en-AU
Content-Language: en-US
acceptlanguage: en-US, en-AU
Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E115041F5FFCWSMSG3153Vsrv_"
MIME-Version: 1.0
Subject: Re: [jose] Whether implementations must understand all JOSE header fields
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Dec 2012 05:12:08 -0000

James said:
>> I would also appreciate your thoughts on whether someone can extend JWS by specifying: when the “zip” field is present in a JWS the content is compressed.
That looks legitimate with the current “MUST understand or reject” rule. I think it is likely, however, that such an extension will cause security problems. Some implementations will confirm that “zip” is on the list of known standard fields, but will ignore it in the JWS processing code.

Mike said:
> One would define “zip” in a JWS in the normal way that extensions are made to IETF specs – you’d write a spec defining the meaning for it and register the “zip” value in the IANA JSON Web Signature and Encryption Header Parameters registry for JWS usage.

Lets ignore the process for now (IETF, IANA…), the issue is whether this style of extension is sensible: an extension that indicates a change of semantics by the presence of a new field. A style that the “MUST understand everything” rule encourages.
My argument is that this style is too dangerous a way to indicate new semantics. When changing semantics (as “zip” does) it would be much better to change a field we are confident implementations will be looking at, as opposed to relying on them to notice a new field.

James Manger