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

<Axel.Nennker@telekom.de> Tue, 18 December 2012 08:52 UTC

Return-Path: <Axel.Nennker@telekom.de>
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 7736F21F87A3 for <jose@ietfa.amsl.com>; Tue, 18 Dec 2012 00:52:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.147
X-Spam-Level:
X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[AWL=-0.902, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, TRACKER_ID=2.003]
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 kl5sl69gg3Bt for <jose@ietfa.amsl.com>; Tue, 18 Dec 2012 00:52:50 -0800 (PST)
Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id 4F10421F875A for <jose@ietf.org>; Tue, 18 Dec 2012 00:52:48 -0800 (PST)
Received: from he111297.emea1.cds.t-internal.com ([10.125.90.15]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 18 Dec 2012 09:52:28 +0100
Received: from HE111541.emea1.cds.t-internal.com ([10.125.90.94]) by HE111297.EMEA1.CDS.T-INTERNAL.COM ([fe80::9835:b110:c489:6d64%16]) with mapi; Tue, 18 Dec 2012 09:52:27 +0100
From: Axel.Nennker@telekom.de
To: Michael.Jones@microsoft.com, jose@ietf.org
Date: Tue, 18 Dec 2012 09:52:26 +0100
Thread-Topic: [jose] Whether implementations must understand all JOSE header fields
Thread-Index: Ac3c6fKiGIpH7bZFS4icWSDz6kDFIAAEWr0A
Message-ID: <CE8995AB5D178F44A2154F5C9A97CAF4025238FC2A45@HE111541.emea1.cds.t-internal.com>
References: <4E1F6AAD24975D4BA5B16804296739436694758E@TK5EX14MBXC284.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436694758E@TK5EX14MBXC284.redmond.corp.microsoft.com>
Accept-Language: de-DE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: de-DE
Content-Type: multipart/alternative; boundary="_000_CE8995AB5D178F44A2154F5C9A97CAF4025238FC2A45HE111541eme_"
MIME-Version: 1.0
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: Tue, 18 Dec 2012 08:52:53 -0000

I did not comment on this because I thought I needed to think about all alternatives.

3) have a field "ver" denoting the version of the JWT. All headers and values are defined in a version. If a recipient does not understands a version then the JWT must be rejected, if he understands the version then all header fields and values must be understood and there are no extra header fields.

4) For each value of alg and enc there is a new optinal field with the name of the value of alg or enc containing the parameters for this value of alg or enc.
Example:

    {"alg":"ES1024T", /* some new algorithm */

      "ES1024T ":{"param1": "value1","param2":"value2"};

     "notes":"This signature need not be checked when the moon is full"

    }
Recipient must understand alg and its value. If there is a field like ES1024T then recipient must understand all fields in its value e.g. param1, value1
All other header fields like notes can safely be ignored because they are not relevant to alg or enc.
There needs to be wording to prevent name clashes likes this alg="user_jwk"

Axel


From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Tuesday, December 18, 2012 7:36 AM
To: jose@ietf.org
Subject: Re: [jose] Whether implementations must understand all JOSE header fields

Are people interested in discussing this, or are we proceed to have the chairs conduct polls and make consensus calls?  Thus far, no one has commented on the note below...

                                                            -- Mike

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Friday, December 14, 2012 10:17 AM
To: jose@ietf.org
Subject: [jose] Whether implementations must understand all JOSE header fields


Currently the JOSE specs contain the following language declaring that all header (and some other) fields must be understood:  "Implementations MUST understand the entire contents of the header; otherwise, the ... MUST be rejected."  There's currently an open issue about whether all header fields should be required to be understood by implementations using them or whether to relax this requirement in some circumstances.  We would like the working group to consider the following potential resolutions to the issue.



1.  Maintain the current requirement that all header fields must be understood by implementations using them.



PRO:  This is a simple rule designed to result in secure implementations.  Representations of existing JWS & JWE objects are unchanged.

CON:  Extensibility is limited to cases where all participating parties understand new fields that are introduced.



2A.  Take an alternative approach where, by default, all fields must be understood, but where an explicit list of fields can be designated as "may be ignored if not understood".  For instance, an "ign" (may be ignored) member could be defined whose value is an array listing the member names that may be safely ignored if not understood.  An example using this field in a JWS header is:



    {"alg":"ES256",

     "ign":["notes"],

     "notes":"This signature need not be checked when the moon is full"

    }



(Obviously, the "ign" field MUST NOT contain the value "ign".)



PRO:  This would enable adding non-critical header fields without breaking implementations.  It would maintain the current semantics, while allowing explicit exceptions to be made in cases where the fields are not security-critical and the structure has a meaningful interpretation without them.  Representations of existing JWS & JWE objects are unchanged.

CON:  Requires coordination of field names and may-be-ignored list, adding some implementation complexity.



2B.  Take an alternative approach where instead of one header object, there would be two header objects.  Implementations would be required to understand all fields in the first header object.  Implementations would be allowed to ignore fields in the second header object if not understood.  An example of this approach, adding the second header object after the first in a JWS, would be:



    eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9

    .

    eyJub3RlcyI6IlRoaXMgc2lnbmF0dXJlIG5lZWQgbm90IGJlIGNoZWNrZWQgd2hlbiB0aGUgbW9vbiBpcyBmdWxsIn0

    .

    eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ

    .

    dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk



The first, third, and fourth fields are from the example JWS in the current spec. The new second field is the base64url encoded representation of the string '{"notes":"This signature need not be checked when the moon is full"}'.



PRO:  May-be-ignored fields are easily distinguishable from must-be-understood fields.

CON:  Implementations must consult/merge two sets of headers to understand the meaning/structure of the object, adding some implementation complexity.  Existing JWS & JWE object representations would become invalid.



After a discussion period, we believe that it would be useful for the chairs to make two formal consensus calls of the following kind:



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 "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.



                                                Thanks for considering these questions,

                                                Richard Barnes, John Bradley, Mike Jones