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

John Bradley <> Tue, 16 September 2014 15:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0D8071A0ACB for <>; Tue, 16 Sep 2014 08:37:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YgIyC0aZwg-f for <>; Tue, 16 Sep 2014 08:37:14 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F2E8B1A085C for <>; Tue, 16 Sep 2014 08:37:13 -0700 (PDT)
Received: by with SMTP id l13so3768689iga.5 for <>; Tue, 16 Sep 2014 08:37:13 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=8WI0K8OxfWIjqBwEMxDTUtsPTfr+fMxFattw0cD1LBU=; b=frNrvf0t+LJ8tCKypHkOPqk54Awu0nGUMzUz05KfIMdha2MP+tBus1t7Vmpb/qwfn7 TGwfnM6Bc82LdjxYqKYrPzQbnC/btYtbAbVVURsean6DDdq3oxc4vuHl44iUXmMMCE0s I3M6wuy7XcHl5oJcQdOWe/l9AfWUC9vq2xbKAxU0P4so1DiPRFxJ7FPBi58haQFbuCyA Y638aUN1PGbOxJn76vpfFP9BJeWMp2pyJ0PX88hPyxcaM2/WeeWeK7oAJ/Hfi7Tv7s0D gFfUzRT7Mj71ABVDLgxjDlmju2V2jKJF+mPLw0qJRZDhzQGawFE55ogQjXNTVqjDckYd 7/lg==
X-Gm-Message-State: ALoCoQkHZI8ROMrBwZhx9r4QpeIuV9SYSGcoh+59N3m6/mKwu9nSDJiwxuSdoyT81Yrhh3l5h/sN
X-Received: by with SMTP id lk20mr34392294icc.17.1410881833204; Tue, 16 Sep 2014 08:37:13 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id lq10sm1659442igb.22.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Sep 2014 08:37:10 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_9AED66D4-418C-4058-B5D7-224ECC9FD650"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: John Bradley <>
In-Reply-To: <>
Date: Tue, 16 Sep 2014 12:35:49 -0300
Message-Id: <>
References: <> <> <> <> <> <> <> <> <>
To: Tero Kivinen <>
X-Mailer: Apple Mail (2.1878.6)
Cc: "" <>, "" <>, "" <>, Michael Jones <>, Kathleen Moriarty <>, Tim Bray <>, "" <>
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: Tue, 16 Sep 2014 15:37:16 -0000

I was mostly trying to dig out what Tim was advocating.

I make no claims to be a expert on JSON parsers.  
That most of them accept duplicate keys is a reflection of the current JSON specs.

As Tim stated in a later message most of them don't reject or report duplicate keys.
He is proposing a new JSON profile I-JSON that changes that.

Changing things that are currently in wide deployment in many environments will not be a overnight thing.
It may be that in some environments ignoring duplicate keys may be seen by some (not me) as a feature.

I think we all agree that producers must be prohibited from emitting JSON envelopes with duplicate keys.

As Jim points out that won't stop bad people from doing it.

The only real protection is if receivers check and reject.

I agree that making it a MUST will encourage parsers behaviour to change more quickly. 

In the interim there are going to be a lot of non compliant implementations.

My only concern is to get people to fix the parsers properly rather than JOSE libraries building there own,
 parsers from scratch that may not be well tested and have other issues.

This did receive a lot of debate in the WG and the current wording was changed from MUST reject duplicate elements, based
on feed back from the JSON community.

This is not just a JWK issue, it also applies to JWE and JWS.

I am open to changing it if there is support for it in the WG.

John B.

On Sep 16, 2014, at 5:02 AM, Tero Kivinen <> wrote:

> 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.
> --