Re: [secdir] [jose] JWK member names, was: SECDIR review of draft-ietf-jose-json-web-key-31

John Bradley <ve7jtb@ve7jtb.com> Mon, 15 September 2014 21:41 UTC

Return-Path: <ve7jtb@ve7jtb.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFF0E1A8784 for <secdir@ietfa.amsl.com>; Mon, 15 Sep 2014 14:41:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNXhj5yW_FIR for <secdir@ietfa.amsl.com>; Mon, 15 Sep 2014 14:41:05 -0700 (PDT)
Received: from mail-qg0-f42.google.com (mail-qg0-f42.google.com [209.85.192.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27A9D1A877E for <secdir@ietf.org>; Mon, 15 Sep 2014 14:41:05 -0700 (PDT)
Received: by mail-qg0-f42.google.com with SMTP id q107so4766166qgd.1 for <secdir@ietf.org>; Mon, 15 Sep 2014 14:41:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=1m+Z6Y359ifdQnxuGxTn/ejYwoQbTOTrRIt4++G1WRA=; b=D0mTRRIbJ+duDcsYojc9xrupiWQi5vfRqgD0aDtB1REZV4qU/K0j8j/AqLweUXxAiE nZw9Rl8BY0GOSLG1KZ9Z85A+tIbqBoQJUdZmQpd/AjCPJaMYa6GBcbMRdyIyiDNFC2SR amBvAhp1r1GRsG7WBpPsc5ktaOEEetHHTj9OtaA2j1MYjT1Hv1QzD2IpltSdzx7+BzLB czVLe/8aU9YMcMTI5F7ree1jNG+FEz8VV4qEZARMJ/Gv1UFig8QG7rbcgDYDkZJ+0r1p 1EUzqHGajNfbVjEDavbz728f6q+XQrRDMOaqPdN76QmP51b7/MSYzMEtNpri/JKyBv1Y mgJg==
X-Gm-Message-State: ALoCoQmsvlIR6lHIuusCBIXHuGLbK8PA9AbQh2HKChOcqiYguimaTo74MGjCpGWZrBvKyYduLb28
X-Received: by 10.140.89.179 with SMTP id v48mr9385485qgd.65.1410817263890; Mon, 15 Sep 2014 14:41:03 -0700 (PDT)
Received: from [192.168.0.90] ([186.67.38.12]) by mx.google.com with ESMTPSA id e5sm10482227qaa.33.2014.09.15.14.41.01 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Sep 2014 14:41:02 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_EE04313C-AA47-48DF-9A63-C4950A25C8F4"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <CAHBU6ivny2qZBK+Afay=Y2kUx-NXCNaeQRZkHtf07JJrVAWWAQ@mail.gmail.com>
Date: Mon, 15 Sep 2014 18:40:58 -0300
Message-Id: <AB84713A-586F-469D-8D26-9C0EE9E1348A@ve7jtb.com>
References: <CAHbuEH4Ccn2Z=8kEECzvgjmtshwsFoa-EH_NpkJPos7zirGeaQ@mail.gmail.com> <4E1F6AAD24975D4BA5B16804296739439AEC00DB@TK5EX14MBXC292.redmond.corp.microsoft.com> <5416FE10.3060608@bbn.com> <CAHBU6iu3GfsLCAint3z7risZUnVW4EK0WrGVW6Dv=gvppiHSxQ@mail.gmail.com> <4E1F6AAD24975D4BA5B16804296739439AECCCDD@TK5EX14MBXC292.redmond.corp.microsoft.com> <54173546.5000400@bbn.com> <CAHBU6ivb3BeEufcnJB+eSk8wgETMx+qzH3miE6Z1jtrQkXNR3w@mail.gmail.com> <EB1515F8-95D4-4F9F-B2EC-F6B0D54C1CC2@ve7jtb.com> <CAHBU6ivny2qZBK+Afay=Y2kUx-NXCNaeQRZkHtf07JJrVAWWAQ@mail.gmail.com>
To: Tim Bray <tbray@textuality.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/PP7JeUR4ZzwDTp_VJIjFlmZm1to
Cc: "jose-chairs@tools.ietf.org" <jose-chairs@tools.ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-jose-json-web-key.all@tools.ietf.org" <draft-ietf-jose-json-web-key.all@tools.ietf.org>, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, Michael Jones <Michael.Jones@microsoft.com>, "jose@ietf.org" <jose@ietf.org>
Subject: Re: [secdir] [jose] JWK member names, was: SECDIR review of draft-ietf-jose-json-web-key-31
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Sep 2014 21:41:09 -0000

Inline
On Sep 15, 2014, at 6:21 PM, Tim Bray <tbray@textuality.com> wrote:

> On Mon, Sep 15, 2014 at 12:18 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
> Are you recommending that:
> That receivers MUST reject JOSE objects with duplicate keys.  
> 
> This would require compliant implementations to write there own parsers (perhaps not a good idea), or wait for I-JSON parsers (perhaps sometime soonish)
> 
> ​Agree, sigh.​
> 
> 
> Or that JOSE require producers not to send dup keys, and receivers SHOULD reject them if possible based on the parser.
> 
> ​Yeah… MUST NOT send malformed JSON (I argue that an economical way to do that would be to reference I-JSON if the schedule works).  As for the receiver, I like SHOULD reject, but I’m wondering if we can get away with that given that a high proportion of receiving software will have no way to detect the error.​
> 
> 
> For JWE and JWS the header is integrity protected so we are talking about duplicate keys inserted by a bad producer rather than an attacker modifying the message after signing..
> 
> ​Whatever. If you get a busted message, something is wrong somewhere upstream.​
> 
> 
> I suspect the important issue is taking care that when producing a JWE/JWS you are not accepting arbitrary elements for the header without verifying that they are not JOSE parameters.
> 
> ​Hm, for ID Tokens, didn’t we do exactly the opposite, and end up with a Must-Ignore policy?​

Yes the receiver ignores unknown elements in the body of the JWT.  

I think that is different than a JWS/JWE library accepting additional parameters from a calling application to go into the envelope.   In that case the sender lib may want to check that they are not JW* reserved names that might cause some interoperability problems.

The lib producing the JWE/S is probably not going to normally duplicate elements on it's own.

Where I see it perhaps going bas is if someone is counting on the receiver taking the last one of a duplicate element and trying to override some header parameter by inserting a duplicate after the lib generated one.   This would work sometime and fail others depending on the receivers parser.

We probably want to be clear that anything extra going into an envelope needs to be checked to avoid reserved elements.

John B.
> 
> 
>  
> 
> John B.
> 
> 
> On Sep 15, 2014, at 3:54 PM, Tim Bray <tbray@textuality.com> wrote:
> 
>> ​When I talk about existing software I’m referring to generic JSON parsers such as are included in the basic library set of every programming language now, and which are unfortunately idiosyncratic and inconsistent in their handling of dupe keys, but in almost no cases actually inform the calling software whether or not dupe keys were encountered.
>> 
>> On Mon, Sep 15, 2014 at 11:51 AM, Stephen Kent <kent@bbn.com> wrote:
>> OK, I'm a bit confused.
>> 
>> I thought the JOSE specs were intended to create standards for transport of keys, and for sigs,
>> MACs, and encryption of JSON objects.
>> 
>> What is the existing software to which you and Tim refer, when referring to keys (vs.
>> JSON parsing in general)?
>> 
>> Steve
>> 
>> 
>> 
>> 
>> -- 
>> - Tim Bray (If you’d like to send me a private message, see https://keybase.io/timbray)
>> _______________________________________________
>> 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
> 
> 
> 
> 
> -- 
> - Tim Bray (If you’d like to send me a private message, see https://keybase.io/timbray)