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

"Jim Schaad" <> Mon, 15 September 2014 22:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5DA7E1A87DE; Mon, 15 Sep 2014 15:51:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OzHYZYpOrDK6; Mon, 15 Sep 2014 15:51:07 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EC2711A87D1; Mon, 15 Sep 2014 15:51:06 -0700 (PDT)
Received: from Philemon ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 5F3CB2CA2E; Mon, 15 Sep 2014 15:51:05 -0700 (PDT)
From: Jim Schaad <>
To: 'Tim Bray' <>, 'John Bradley' <>
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Date: Mon, 15 Sep 2014 15:48:41 -0700
Message-ID: <062601cfd137$32db19e0$98914da0$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0627_01CFD0FC.867F4F20"
X-Mailer: Microsoft Outlook 14.0
Content-Language: en-us
Thread-Index: AQGhCu56AbVyg2yQms2r387DvC+5QAJm+9NfAfDIj4QCSdWUkwG5bHoPAU5961gCM+z1zwLmzZ9XAL2003Ob5EejgA==
Cc:, 'Stephen Kent' <>,,, 'Kathleen Moriarty' <>, 'Michael Jones' <>,
Subject: Re: [jose] JWK member names, was: SECDIR review of draft-ietf-jose-json-web-key-31
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Javascript Object Signing and Encryption <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 15 Sep 2014 22:51:10 -0000

My problem is that MUST NOT send means nothing to an attacker.  Esp. if the attacker is the message originator.  The only meaningful enforcement of any of this is going to be by the recipient.   If the recipient cannot enforce this restriction, then it will always be open to some type of attack from duplicate keys.


I would note that the MUST NOT for reordering of fields is not a JSON requirement but only a JavaScript requirement.  So an intermediate agent can read in and re-order the fields if it writes them out and not have a problem with the JSON specifications.





From: jose [] On Behalf Of Tim Bray
Sent: Monday, September 15, 2014 2:21 PM
To: John Bradley
Cc:; Stephen Kent;;; Kathleen Moriarty; Michael Jones;
Subject: Re: [jose] JWK member names, was: SECDIR review of draft-ietf-jose-json-web-key-31


On Mon, Sep 15, 2014 at 12:18 PM, John Bradley <> 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?​





John B.



On Sep 15, 2014, at 3:54 PM, Tim Bray <> 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 <> 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)?




- Tim Bray (If you’d like to send me a private message, see

jose mailing list


jose mailing list



- Tim Bray (If you’d like to send me a private message, see