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

"Manger, James H" <James.H.Manger@team.telstra.com> Thu, 20 December 2012 02:08 UTC

Return-Path: <James.H.Manger@team.telstra.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C883B21F84D8 for <jose@ietfa.amsl.com>; Wed, 19 Dec 2012 18:08:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.789
X-Spam-Level:
X-Spam-Status: No, score=-0.789 tagged_above=-999 required=5 tests=[AWL=0.111, 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 mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwQm5ci67bKT for <jose@ietfa.amsl.com>; Wed, 19 Dec 2012 18:08:32 -0800 (PST)
Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id E9B6E21F843E for <jose@ietf.org>; Wed, 19 Dec 2012 18:08:30 -0800 (PST)
X-IronPort-AV: E=Sophos; i="4.84,321,1355058000"; d="scan'208,217"; a="109188715"
Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipoavi.tcif.telstra.com.au with ESMTP; 20 Dec 2012 13:08:22 +1100
X-IronPort-AV: E=McAfee;i="5400,1158,6931"; a="154977373"
Received: from wsmsg3703.srv.dir.telstra.com ([172.49.40.171]) by ipcavi.tcif.telstra.com.au with ESMTP; 20 Dec 2012 13:08:22 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3703.srv.dir.telstra.com ([172.49.40.171]) with mapi; Thu, 20 Dec 2012 13:08:21 +1100
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: Mike Jones <Michael.Jones@microsoft.com>, "jose@ietf.org" <jose@ietf.org>
Date: Thu, 20 Dec 2012 13:08:20 +1100
Thread-Topic: [jose] Whether implementations must understand all JOSE header fields
Thread-Index: Ac3da4u39ZRiYSLMQBShe+M/5UR54QAALdFQAAH0xRAAByH0sAAkEbRAAApz+pAAAl46sAAAXPvw
Message-ID: <255B9BB34FB7D647A506DC292726F6E115042EDB85@WSMSG3153V.srv.dir.telstra.com>
References: <4E1F6AAD24975D4BA5B168042967394366968592@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E115040898B5@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B16804296739436696ABC0@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E115041F5FFC@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B168042967394366977627@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E115042EDB0C@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B16804296739436697AEE2@TK5EX14MBXC283.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436697AEE2@TK5EX14MBXC283.redmond.corp.microsoft.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-AU
Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E115042EDB85WSMSG3153Vsrv_"
MIME-Version: 1.0
Subject: Re: [jose] Whether implementations must understand all JOSE header fields
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 20 Dec 2012 02:08:32 -0000

> The prefix for “alg” values would have exactly the same property as adding a new header parameter. If the new alg value was not understood, the JWS would be useless to the receiver.

I am very confident that every (reasonable) JOSE implementation will notice the “alg” value, ie fail-safe on an unrecognized “alg” value.

> (Just as it would be useless if a new header value was used, if not understood.)  I’m not sure why the former is any more usable than the latter.

I have far far less confidence that every (reasonable) JOSE implementation will notice an unexpected field, particularly a known field in an unexpected context.

--
James Manger
                                                                Cheers,
                                                                -- Mike

From: Manger, James H [mailto:James.H.Manger@team.telstra.com]
Sent: Wednesday, December 19, 2012 5:39 PM
To: Mike Jones; jose@ietf.org<mailto:jose@ietf.org>
Subject: RE: [jose] Whether implementations must understand all JOSE header fields

> “zip” is a perfect example of indicating a change of semantics with the presence of a new field.  The processing of a JWE without a “zip” field is different than the processing of it with one.  An implementation must understand the field to use the resulting JWE.  The same would be true of any JWS that used a “zip” extension.
>
> It would never be safe to ignore this field, whether defined as part of the base spec, or defined as an extension later.

I agree.
When I looked at a handful of publicly available JOSE implementations quite a while ago none enforced the “MUST understand everything” rule — so a zip-for-JWS extension would be dangerous for them. One implementation later added code to enforce the rule using one fixed list of all header fields defined in JW* — so a zip-for-JWS extension would be dangerous for that too.

We know the “MUST understand everything” rule makes it hard to deploy non-critical extensions.
It seems to me that the rule also makes it dangerous to deploy critical extensions.
About the only safe way to define a critical extension will be to define a prefix for “alg” values (eg "alg": "zip;RSA1_5"). I hope that isn’t the most practical option we leave for anyone wanting to extend JOSE.

--
James Manger