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

Dirkjan Ochtman <dirkjan@ochtman.nl> Thu, 20 December 2012 07:47 UTC

Return-Path: <djc.ochtman@gmail.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 80BDA21F8A87 for <jose@ietfa.amsl.com>; Wed, 19 Dec 2012 23:47:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 df0O3zEozByn for <jose@ietfa.amsl.com>; Wed, 19 Dec 2012 23:47:22 -0800 (PST)
Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by ietfa.amsl.com (Postfix) with ESMTP id ACC3721F8A85 for <jose@ietf.org>; Wed, 19 Dec 2012 23:47:22 -0800 (PST)
Received: by mail-qa0-f46.google.com with SMTP id r4so4972608qaq.5 for <jose@ietf.org>; Wed, 19 Dec 2012 23:47:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=TFV2Wue9TBtClyUaaBRKvs9HnZQCIMNhwTmdgV0dDrM=; b=nFxcPNQf/rzng0ovriyLvICleDOWRmEa8aPZkwRw/lCy2wXo0DO5r8LGRcRzGHirdL wv3DY2SEkM9sGkjnnuItzxn4J/6hwi80EffL8bBeYobF1DTxcYfDDlmRarwvb6l0l0MX y4x0g30SFqevgOl8DCrLMKTcb2gPrv6eSLv/VYvWSFSWwUS+cel+j46ZugK8YaqJa54x y6QQkvKGx5KAeM6IrIUZFZN4mUOfZdlTUt1r8iIl9Kv0DtEs5gZAf+0gL0/6QPcZkWlZ GF8KA+4pCs97JWuQfAgMDiJoC8F5BtseRK8l1YRiGMgXXwab2o/pdIfGTRN4PHxrcDhs Gm2Q==
Received: by 10.49.96.1 with SMTP id do1mr4768936qeb.26.1355989642124; Wed, 19 Dec 2012 23:47:22 -0800 (PST)
MIME-Version: 1.0
Sender: djc.ochtman@gmail.com
Received: by 10.49.1.17 with HTTP; Wed, 19 Dec 2012 23:47:02 -0800 (PST)
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436697B301@TK5EX14MBXC283.redmond.corp.microsoft.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> <255B9BB34FB7D647A506DC292726F6E115042EDB85@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B16804296739436697B301@TK5EX14MBXC283.redmond.corp.microsoft.com>
From: Dirkjan Ochtman <dirkjan@ochtman.nl>
Date: Thu, 20 Dec 2012 08:47:02 +0100
X-Google-Sender-Auth: bXeC4wAuiIcFcFtH6QGdazSZ2Rc
Message-ID: <CAKmKYaAP2q6SYO6F_UqA7-kB7Hm8kybmEo-+210sZ+P33cqUCQ@mail.gmail.com>
To: Mike Jones <Michael.Jones@microsoft.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "Manger, James H" <James.H.Manger@team.telstra.com>, "jose@ietf.org" <jose@ietf.org>
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 07:47:23 -0000

Yeah, that makes sense to me.

Also, even having a small set of must-understand fields (alg and zip
and maybe 1 or 2 others) is very different from having a
must-understand-all policy.

Cheers,

Dirkjan

On Thu, Dec 20, 2012 at 3:12 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:
> Fair enough, but I am also very confident that every implementation trying
> to use a compressed payload where it was expecting an uncompressed one would
> quickly notice the difference and then do what it takes to get their
> implementation fixed/updated. J
>
>
>
>                                                             -- Mike
>
>
>
> From: Manger, James H [mailto:James.H.Manger@team.telstra.com]
> Sent: Wednesday, December 19, 2012 6:08 PM
>
>
> To: Mike Jones; jose@ietf.org
> Subject: RE: [jose] Whether implementations must understand all JOSE header
> fields
>
>
>
>> 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
> 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
>
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>