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

<> Wed, 06 February 2013 17:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3C01E21F85DF for <>; Wed, 6 Feb 2013 09:52:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IEiGwGXuDH1G for <>; Wed, 6 Feb 2013 09:52:42 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id BC55021F8545 for <>; Wed, 6 Feb 2013 09:52:41 -0800 (PST)
Received: from (unknown [xx.xx.xx.2]) by (ESMTP service) with ESMTP id 983F73B41A1 for <>; Wed, 6 Feb 2013 18:52:40 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown []) by (ESMTP service) with ESMTP id 811FE27C046 for <>; Wed, 6 Feb 2013 18:52:40 +0100 (CET)
Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Wed, 6 Feb 2013 18:52:40 +0100
To: "" <>
Thread-Topic: [jose] POLL(s): header criticality
Thread-Index: AQHOAua+D+q84ufpKkeM13mXQx76+5htB8eggAAX9IA=
Date: Wed, 06 Feb 2013 17:52:40 +0000
Message-ID: <5163_1360173160_51129868_5163_5092_1_9DCA6A69E825794F80108BF7815EE1A8144059@PEXCVZYM11.corporate.adroot.infra.ftgroup>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <38ADE42DF08F86429755D1C537A51F82@adroot.infra.ftgroup>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version:, Antispam-Engine:, Antispam-Data: 2013.2.6.141216
Subject: Re: [jose] POLL(s): header criticality
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 06 Feb 2013 17:58:21 -0000



>-----Original Message-----
>From: [] On Behalf Of
>Karen O'Donoghue
>Sent: Monday, February 04, 2013 6:49 AM
>Subject: [jose] POLL(s): header criticality
>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.
>FIRST POLL: Should all header fields be critical for implementations to
>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
>C - Other??? (Please specify in detail.)
>jose mailing list


Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.