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

Tero Kivinen <> Thu, 18 September 2014 08:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1BA231A7113; Thu, 18 Sep 2014 01:06:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.773
X-Spam-Status: No, score=-2.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652, SPF_NEUTRAL=0.779] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SQZTOnPk0thT; Thu, 18 Sep 2014 01:06:14 -0700 (PDT)
Received: from ( [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 876991A6FBB; Thu, 18 Sep 2014 01:06:14 -0700 (PDT)
Received: from (localhost []) by (8.14.8/8.14.8) with ESMTP id s8I868Ug001963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 18 Sep 2014 11:06:08 +0300 (EEST)
Received: (from kivinen@localhost) by (8.14.8/8.14.8/Submit) id s8I867T2023596; Thu, 18 Sep 2014 11:06:07 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-ID: <>
Date: Thu, 18 Sep 2014 11:06:06 +0300
From: Tero Kivinen <>
To: Tim Bray <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd)
X-Edit-Time: 9 min
X-Total-Time: 8 min
Cc: "" <>, "" <>, "" <>, Kathleen Moriarty <>, Michael Jones <>, "" <>, John Bradley <>
Subject: Re: [secdir] [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: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 18 Sep 2014 08:06:18 -0000

Tim Bray writes:
> The chance  of the JOSE working group moving the vast world of
> deployed JSON infrastructure round to 0.00.   Thus putting a MUST
> reject in here would essentially say you can’t use well-debugged
> production software, and would be a really bad idea.

And are none of those jose parsers open source? If any of them is open
source, then someone who wants to use jose, could take one, fix it to
reject duplicates, and use that still well-debugged production
software, with small patch, and he just need to add regression test
case for the new patch, and rerun the normal regression tests to know
everything else still works.

If all of them are closed source software which you cannot patch, then
it might be better that people write proper open source parser which
actually tries to be secure.

> On the other hand, if JOSE specified that producers’ messages MUST
> conform to I-JSON, and a couple other WGs climbed on that bandwagon,
> and the word started to get around, I wouldn’t be surprised if a few
> of the popular JSON implementations added an I-JSON mode.  That
> would be a good thing and lessen the attack surface of all
> JSON-based protocols (which these days, is a whole lot of them).

And if we say MUST reject structures with duplicate keys, that would
perhaps force them even more, especially as those vendors really
wanting to be conformant would start asking that.

On the other hand, I think most of the vendors would just issue
request for the fix, but still continue using the relaxed parser,
regardless what we write in the specification here. At least if we say
MUST then they hopefully will put the feature request in. If we say
SHOULD, they will not...