Re: [jose] POLL(s): header criticality
Russ Housley <housley@vigilsec.com> Sun, 10 February 2013 23:01 UTC
Return-Path: <housley@vigilsec.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 33F6321F880B for <jose@ietfa.amsl.com>; Sun, 10 Feb 2013 15:01:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 uuC-aaEpCKT2 for <jose@ietfa.amsl.com>; Sun, 10 Feb 2013 15:01:44 -0800 (PST)
Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 939A021F8804 for <jose@ietf.org>; Sun, 10 Feb 2013 15:01:44 -0800 (PST)
Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id D1A469A4004; Sun, 10 Feb 2013 18:01:52 -0500 (EST)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id OFX9qUXUJp51; Sun, 10 Feb 2013 18:01:37 -0500 (EST)
Received: from [192.168.2.100] (pool-96-255-37-162.washdc.fios.verizon.net [96.255.37.162]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 5450D9A4001; Sun, 10 Feb 2013 18:01:48 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset="windows-1252"
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <510FCA42.5000704@isoc.org>
Date: Sun, 10 Feb 2013 18:01:37 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <E1CF038F-E2BE-4409-B42A-D6C985C4C99F@vigilsec.com>
References: <510FCA42.5000704@isoc.org>
To: odonoghue@isoc.org
X-Mailer: Apple Mail (2.1085)
Cc: jose@ietf.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: Sun, 10 Feb 2013 23:01:45 -0000
FIRST POLL: NO SECOND POLL: NO THIRD POLL: C First, when designing CMS we discussed this field criticality topic to death. I'm sad that we are exploring the same ratholes in even greater detail yet again. If an implementation supports key agreement, then it needs to understand all of the key agreement headers, but it might ignore fields associated with other recipient that are using other key management approaches. If an implementation supports key transport, then it needs to understand all of the key transport headers, but it might ignore fields associated with other recipient that are using other key management approaches. If an implementation supports password-based encryption then it needs to understand all of thepassword-based encryption headers, but it might ignore fields associated with other recipient that are using other key management approaches. And so on. Russ On Feb 4, 2013, at 9:48 AM, Karen O'Donoghue wrote: > ******************* > 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] POLL(s): header criticality Karen O'Donoghue
- Re: [jose] POLL(s): header criticality Anthony Nadalin
- Re: [jose] POLL(s): header criticality John Bradley
- Re: [jose] POLL(s): header criticality Matt Miller (mamille2)
- Re: [jose] POLL(s): header criticality Mike Jones
- Re: [jose] POLL(s): header criticality Dick Hardt
- Re: [jose] POLL(s): header criticality Breno de Medeiros
- Re: [jose] POLL(s): header criticality Breno de Medeiros
- Re: [jose] POLL(s): header criticality George Fletcher
- Re: [jose] POLL(s): header criticality Dick Hardt
- Re: [jose] POLL(s): header criticality Edmund Jay
- Re: [jose] POLL(s): header criticality sebastien.brault
- Re: [jose] POLL(s): header criticality Mike Jones
- Re: [jose] POLL(s): header criticality Brian Campbell
- Re: [jose] POLL(s): header criticality Nat Sakimura
- Re: [jose] POLL(s): header criticality Richard Barnes
- Re: [jose] POLL(s): header criticality Eric Rescorla
- Re: [jose] POLL(s): header criticality Peter Yee
- Re: [jose] POLL(s): header criticality Axel.Nennker
- Re: [jose] POLL(s): header criticality hideki nara
- Re: [jose] POLL(s): header criticality Ryo Ito
- Re: [jose] POLL(s): header criticality Hannes Tschofenig
- Re: [jose] POLL(s): header criticality Roland Hedberg
- Re: [jose] POLL(s): header criticality Mike Jones
- Re: [jose] POLL(s): header criticality charles.marais@orange.com
- Re: [jose] POLL(s): header criticality Hannes Tschofenig
- Re: [jose] POLL(s): header criticality Casper Biering
- Re: [jose] POLL(s): header criticality Manger, James H
- Re: [jose] POLL(s): header criticality Stephen Kent
- Re: [jose] POLL(s): header criticality Dirkjan Ochtman
- Re: [jose] POLL(s): header criticality Mike Jones
- Re: [jose] POLL(s): header criticality Richard Barnes
- Re: [jose] POLL(s): header criticality Mike Jones
- Re: [jose] POLL(s): header criticality Hannes Tschofenig
- Re: [jose] POLL(s): header criticality nov matake
- Re: [jose] POLL(s): header criticality Andreas Åkre Solberg
- Re: [jose] POLL(s): header criticality Prateek Mishra
- Re: [jose] POLL(s): header criticality Richard Barnes
- Re: [jose] POLL(s): header criticality Salvatore D'Agostino
- Re: [jose] POLL(s): header criticality Chuck Mortimore
- Re: [jose] POLL(s): header criticality Torsten Lodderstedt
- Re: [jose] POLL(s): header criticality Russ Housley
- Re: [jose] POLL(s): header criticality Vladimir Dzhuvinov / NimbusDS
- Re: [jose] POLL(s): header criticality Stephen Kent
- Re: [jose] POLL(s): header criticality HAYASHI, Tatsuya