Re: [jose] POLL(s): header criticality

nov matake <matake@gmail.com> Fri, 08 February 2013 15:56 UTC

Return-Path: <matake@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 7A91421F8AD0 for <jose@ietfa.amsl.com>; Fri, 8 Feb 2013 07:56:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, 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 jcEL7WwCYIwy for <jose@ietfa.amsl.com>; Fri, 8 Feb 2013 07:56:00 -0800 (PST)
Received: from mail-da0-f43.google.com (mail-da0-f43.google.com [209.85.210.43]) by ietfa.amsl.com (Postfix) with ESMTP id C32C221F8AB6 for <jose@ietf.org>; Fri, 8 Feb 2013 07:55:54 -0800 (PST)
Received: by mail-da0-f43.google.com with SMTP id u36so1806170dak.2 for <jose@ietf.org>; Fri, 08 Feb 2013 07:55:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=Fem0eurZy+fIwX0NHFD3q01R/4JRBne9ps6Wp0KoW/Y=; b=1At7xdNBbO4lJYnz5Pq3XxBqdXUMmC9A4VNK1Yyt/c2GX6vDbOwIZqVkvLU1OYxvfg JjHf2Nw8zOrzEQ8Bi8iHu1TcOjJ1OXZ3f2KR5fapvm36ClaQTbkwyGisuOi7YxIGw9Nk bI5RdzcwQcmkG/u69CjMs+teOmAsaA0yJd2E385SqDhxGJxc2lQBIUalSCFT8tsM7LHh FFgNwsTuAgJHlGK6NO2OojLCWq5uK77DTGEqIklOw1HA6jBKBYqhSKR46Y5I74nXTDHS M/aeYSkJvXeJaHcJiJvqabi4oUse2Vr9nqJP/nNZaR5bLb46Y30dvzGY2jsU9yDyV7jA TSuA==
X-Received: by 10.66.52.50 with SMTP id q18mr18684469pao.16.1360338954317; Fri, 08 Feb 2013 07:55:54 -0800 (PST)
Received: from [192.168.1.31] (ac149127.dynamic.ppp.asahi-net.or.jp. [183.77.149.127]) by mx.google.com with ESMTPS id z6sm29400016pav.3.2013.02.08.07.55.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Feb 2013 07:55:52 -0800 (PST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: nov matake <matake@gmail.com>
In-Reply-To: <D86D2308-21CE-463D-B83E-72AAFA0C634B@gmail.com>
Date: Sat, 9 Feb 2013 00:56:03 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <5BE5D79C-F301-4A62-8DFA-7A2388515E84@gmail.com>
References: <510FCA42.5000704@isoc.org> <77177F76-6BC1-467A-8771-F2E1B7AEC7B4@gmail.com> <D86D2308-21CE-463D-B83E-72AAFA0C634B@gmail.com>
To: Dick Hardt <dick.hardt@gmail.com>
X-Mailer: Apple Mail (2.1499)
Cc: "jose@ietf.org" <jose@ietf.org>, "odonoghue@isoc.org" <odonoghue@isoc.org>
Subject: Re: [jose] POLL(s): header criticality
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: Fri, 08 Feb 2013 15:56:01 -0000

FIRST POLL: YES, but only for top level keys.
SECOND POLL: YES
THIRD POLL: C, +1 for defining a ignorable parameters container key as Dick proposed.

On 2013/02/07, at 2:40, Dick Hardt <dick.hardt@gmail.com> wrote:

> I misunderstood the Third Poll options.
> 
> I was thinking that all properties to be ignored would be a property of the header object. ie. all ignorable properties are sub property of a "ignorable" property.
> 
> eg. all "ign" properties can be ignored
> 
> { "alg": "ES256"
> , "ign": 
> 	{  "notes":"this property can be ignored" }
> }
> 
> 
> So I am voting C for the third poll, a different option.
> 
> btw: I continue to be surprised that we are using JSON and only doing name/value pairs.
> 
> -- Dick
> 
> On Feb 6, 2013, at 9:03 AM, Dick Hardt <dick.hardt@gmail.com> wrote:
> 
>> FIRST POLL: Yes
>> 
>> SECOND POLL: YES
>> 
>> THIRD POLL: B
>> 
>> On Feb 4, 2013, at 6:48 AM, Karen O'Donoghue <odonoghue@isoc.org> wrote:
>> 
>>> Folks,
>>> 
>>> I am wrestling with how to help drive consensus on the topic of criticality of headers. For background, please review the current specification text, the minutes to the Atlanta meeting (IETF85), and the mailing list (especially the discussion in December with (Subj: Whether implementations must understand all JOSE header fields)). We need to come to closure on this issue in order to progress the specifications.
>>> 
>>> As a tool to gather further information on determining a way forward, the following polls have been created. Please respond before 11 February 2013.
>>> 
>>> Thanks,
>>> Karen
>>> 
>>> *******************
>>> FIRST POLL: Should all header fields be critical for implementations to understand?
>>> 
>>> YES – All header fields must continue to be understood by implementations or the input must be rejected.
>>> 
>>> NO – A means of listing that specific header fields may be safely ignored should be defined.
>>> 
>>> ********************
>>> SECOND POLL: Should the result of the first poll be "YES", should text like the following be added? “Implementation Note: The requirement to understand all header fields is a requirement on the system as a whole – not on any particular level of library software. For instance, a JOSE library could process the headers that it understands and then leave the processing of the rest of them up to the application. For those headers that the JOSE library didn’t understand, the responsibility for fulfilling the ‘MUST understand’ requirement for the remaining headers would then fall to the application.”
>>> 
>>> YES – Add the text clarifying that the “MUST understand” requirement is a requirement on the system as a whole – not specifically on JOSE libraries.
>>> 
>>> NO – Don’t add the clarifying text.
>>> 
>>> ************************
>>> THIRD POLL: Should the result of the first poll be "NO", which syntax would you prefer for designating the header fields that may be ignored if not understood?
>>> 
>>> A – Define a header field that explicitly lists the fields that may be safely ignored if not understood.
>>> 
>>> B – Introduce a second header, where implementations must understand all fields in the first but they may ignore not-understood fields in the second.
>>> 
>>> C - Other??? (Please specify in detail.)
>>> _______________________________________________
>>> jose mailing list
>>> jose@ietf.org
>>> https://www.ietf.org/mailman/listinfo/jose
>> 
> 
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose