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

Dirkjan Ochtman <dirkjan@ochtman.nl> Wed, 19 December 2012 08:29 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 554AC21F852B for <jose@ietfa.amsl.com>; Wed, 19 Dec 2012 00:29:58 -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 ZJj0tsv9NpkL for <jose@ietfa.amsl.com>; Wed, 19 Dec 2012 00:29:57 -0800 (PST)
Received: from mail-vb0-f43.google.com (mail-vb0-f43.google.com [209.85.212.43]) by ietfa.amsl.com (Postfix) with ESMTP id B0E4A21F8528 for <jose@ietf.org>; Wed, 19 Dec 2012 00:29:57 -0800 (PST)
Received: by mail-vb0-f43.google.com with SMTP id fs19so1967787vbb.16 for <jose@ietf.org>; Wed, 19 Dec 2012 00:29:57 -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=2KXSruG4C/0wEoJ323Xe1b0mZSMwdmOmq8X7NXbXCZo=; b=X1zKE8j2fAn3xGG/L4uNFoqJZ++w5wqqlkNNiTA9zVcneUfw5x4AvmLvR+lJYVph6U ZLSOSdRX1Q+q/avuJ3l/t2mYeLmWUl4ziMHT3e0JVTEc4JTq1Aeg1mGVVsAN9AM/hmul TZMnCyTDJQuIQTSQR7F9bQ6tnLA7bLW4T8X1CQ+uH22DKLjURhZ+XLjFeO871KMUYiQm Hqf4DmAR6sRn7IJLiu1PKCEwN7NUPC+Icxp2CU8r73v07GdhF1KNLdRJZKLlkR1trcSO T9ey91H2nAtS1MM1c6hHGFiEDNMALQ4mPw1WMYgpu8qoFiDHCg4p9lz0OVC8e12vvDJs xAVA==
Received: by 10.52.90.241 with SMTP id bz17mr6616403vdb.40.1355905797061; Wed, 19 Dec 2012 00:29:57 -0800 (PST)
MIME-Version: 1.0
Sender: djc.ochtman@gmail.com
Received: by 10.58.75.15 with HTTP; Wed, 19 Dec 2012 00:29:36 -0800 (PST)
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115041F5FFC@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>
From: Dirkjan Ochtman <dirkjan@ochtman.nl>
Date: Wed, 19 Dec 2012 09:29:36 +0100
X-Google-Sender-Auth: 2r3UsS6sOMQXTGWDqB-dVehzH80
Message-ID: <CAKmKYaCQTTL762EDFNOhwOH=w3hOsfWYprnMdMTE9f=XZ-FDXg@mail.gmail.com>
To: "Manger, James H" <James.H.Manger@team.telstra.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: Mike Jones <Michael.Jones@microsoft.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: Wed, 19 Dec 2012 08:29:58 -0000

On Wed, Dec 19, 2012 at 6:12 AM, Manger, James H
<James.H.Manger@team.telstra.com> wrote:
> 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.

I fully agree with this.

I think the better style is somewhat like this: implementation MUST
use the value of the "alg" header to determine how to interpret the
contents. Any possible alg value may have different header fields that
are required to implement that algorithm. This may be too simplistic,
but it's much more in line with what implementors are prone to doing,
and closer to the expected semantics of JSON processing.

Cheers,

Dirkjan