Re: [jose] Whether implementations must understand all JOSE header fields
"Jim Schaad" <ietf@augustcellars.com> Sun, 30 December 2012 04:25 UTC
Return-Path: <ietf@augustcellars.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 E926921F886A for <jose@ietfa.amsl.com>; Sat, 29 Dec 2012 20:25:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.411
X-Spam-Level:
X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=-0.816, BAYES_00=-2.599, 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 qfYYDx9X620P for <jose@ietfa.amsl.com>; Sat, 29 Dec 2012 20:25:21 -0800 (PST)
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id ECB3D21F8864 for <jose@ietf.org>; Sat, 29 Dec 2012 20:25:20 -0800 (PST)
Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 1AE572CA29; Sat, 29 Dec 2012 20:25:17 -0800 (PST)
From: Jim Schaad <ietf@augustcellars.com>
To: 'Mike Jones' <Michael.Jones@microsoft.com>, jose@ietf.org
References: <4E1F6AAD24975D4BA5B168042967394366929F63@TK5EX14MBXC283.redmond.corp.microsoft.com> <002d01cde3b4$bd464590$37d2d0b0$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943669A869E@TK5EX14MBXC283.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943669A869E@TK5EX14MBXC283.redmond.corp.microsoft.com>
Date: Sat, 29 Dec 2012 20:24:57 -0800
Message-ID: <010d01cde645$a3ef3ff0$ebcdbfd0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_010E_01CDE602.95D093D0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIu1NOwxvsFfhrE3kb42icQdthreQEtjRp9ApbYxe6XUL420A==
Content-Language: en-us
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: Sun, 30 Dec 2012 04:25:25 -0000
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones Sent: Wednesday, December 26, 2012 2:32 PM To: Jim Schaad; jose@ietf.org Subject: Re: [jose] Whether implementations must understand all JOSE header fields That idea seems like it would (1) add to the overall complexity of implementations, (2) would be counter the goal of interoperable implementations, and (3) would likely be counter to goal of security. (1) The way I see it, if an extension mechanism (other than having both parties understand the extension, which already works) is going to be defined, we owe users of the specs a clear definition of how to do not-understood extensions. Otherwise implementations of each profile will potentially have to repeat the work of checking the fields used, rather than doing it in the JOSE libraries themselves, adding to overall implementation complexity. (2) Sometimes allowing fields to be not understood and sometimes requiring them to be, and possibly using different extension mechanisms in different profiles would definitely hurt interoperability. (3) If a profile decided that the "alg" field need not be understood, that would definitely defeat the security purposes of the JOSE specs. The same is true of many other fields. We owe it to users of the specs to be clear that security-critical fields must be understood. "Punting" this to profiles or just putting it in the security considerations unnecessarily risks having profile writers get this wrong. [JLS] I would be shocked if a JWS implementation would report that the signature verified in this case. So I don't think that there is any security issue here. Yes, in theory, we could include a consensus call question giving people this option as well, but unless support for it shows up on the list, it would just seem (to me) to unnecessarily complicate the questions we're asking people by including an option that's not actually viable from a complexity, interoperability, or security point of view. -- Mike From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Wednesday, December 26, 2012 2:03 PM To: Mike Jones; jose@ietf.org Subject: RE: [jose] Whether implementations must understand all JOSE header fields This does not include my recommended approach which is to punt the issue of required headers to the application rather than JOSE. Jim 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 . eyJub3RlcyI6IlRoaXMgc2lnbmF0dXJlIG5lZWQgbm90IGJlIGNoZWNrZWQgd2hlbiB0aGUgbW9v biBpcyBmdWxsIn0 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9p c19yb290Ijp0cnVlfQ . 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
- [jose] Whether implementations must understand al… Mike Jones
- Re: [jose] Whether implementations must understan… Mike Jones
- Re: [jose] Whether implementations must understan… Mike Jones
- Re: [jose] Whether implementations must understan… Axel.Nennker
- Re: [jose] Whether implementations must understan… Manger, James H
- Re: [jose] Whether implementations must understan… Mike Jones
- Re: [jose] Whether implementations must understan… Mike Jones
- Re: [jose] Whether implementations must understan… Richard Barnes
- Re: [jose] Whether implementations must understan… Manger, James H
- Re: [jose] Whether implementations must understan… Mike Jones
- Re: [jose] Whether implementations must understan… Manger, James H
- Re: [jose] Whether implementations must understan… Dirkjan Ochtman
- Re: [jose] Whether implementations must understan… Mike Jones
- Re: [jose] Whether implementations must understan… Manger, James H
- Re: [jose] Whether implementations must understan… Mike Jones
- Re: [jose] Whether implementations must understan… Manger, James H
- Re: [jose] Whether implementations must understan… Mike Jones
- Re: [jose] Whether implementations must understan… Dirkjan Ochtman
- Re: [jose] Whether implementations must understan… Jim Schaad
- Re: [jose] Whether implementations must understan… Mike Jones
- Re: [jose] Whether implementations must understan… Jim Schaad
- Re: [jose] Whether implementations must understan… Jim Schaad
- Re: [jose] Whether implementations must understan… Mike Jones
- Re: [jose] Whether implementations must understan… Jim Schaad
- Re: [jose] Whether implementations must understan… Mike Jones