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

Tero Kivinen <> Tue, 16 September 2014 08:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4E6251A0456; Tue, 16 Sep 2014 01:03:21 -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 uE1jRQFKitus; Tue, 16 Sep 2014 01:03:18 -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 446A41A0422; Tue, 16 Sep 2014 01:02:36 -0700 (PDT)
Received: from (localhost []) by (8.14.8/8.14.8) with ESMTP id s8G82TDd017404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 16 Sep 2014 11:02:29 +0300 (EEST)
Received: (from kivinen@localhost) by (8.14.8/8.14.8/Submit) id s8G82S1x022194; Tue, 16 Sep 2014 11:02:28 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <>
Date: Tue, 16 Sep 2014 11:02:28 +0300
From: Tero Kivinen <>
To: John Bradley <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd)
X-Edit-Time: 8 min
X-Total-Time: 7 min
X-Mailman-Approved-At: Tue, 16 Sep 2014 08:40:44 -0700
Cc: "" <>, "" <>, "" <>, Michael Jones <>, Kathleen Moriarty <>, Tim Bray <>, "" <>
Subject: Re: [jose] [secdir] 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: Tue, 16 Sep 2014 08:03:21 -0000

John Bradley writes:
> 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)

I do not understand this. Why would they need to write their own
parsers? I would expect they would require the existing parsers to be
fixed to reject objetcs with duplicate keys. If I understand correctly
that would already be allowed, as you said some implementations do
that, some return the last key.

If we make it MUST reject JW* items with duplicate keys, that would
make changes to parsers high priority items for the users of the JW*,
thus that would most likely get those changes done quite soon.

Of course there would still be some broken implementations allowing
broken JW* items to be parsed, but the only thing would been that
those implementations cannot claim to be complient with the RFC we are
publishing now. If they want to clam to be complient with RFC xxxx,
they would have to make sure their parser is also fixed...

I mean how many lines of code it would be in the parser to reject the
object if there is duplicate keys? I would expect the change to be
quite small (in order of few to few tens of lines). 

If we do not mandate this now, then nothing is going to change. There
is no demand to the existing parsers to be fixed, which means they
will not get fixed, and we will be stuck with bad parsers forever...

Ps. Following and participating this thread has been almost impossible
to me because some people write text inline without any indication
which is quoted text and which is original text. Only after going to
the secdir archives I noticed there are some color differences to
indicate quoted text, and on my text only screen session all that
information is lost... It would be nice to people actually do
something else than rely on some html-formatted colors to indidate
quoted text vs new text.