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

Richard Barnes <> Thu, 18 September 2014 15:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EE5211A0097 for <>; Thu, 18 Sep 2014 08:03:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6n5b_9VFB2Cc for <>; Thu, 18 Sep 2014 08:03:58 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 351FA1A0110 for <>; Thu, 18 Sep 2014 08:03:37 -0700 (PDT)
Received: by with SMTP id ty20so1309021lab.7 for <>; Thu, 18 Sep 2014 08:03:35 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5Ul9swLms5JANkfMw91BLo4pscHdxx8vlUN8yKrWK7M=; b=Z9lcp5Hhj9uSG/AsETgCF1TadXYw5jYB9nmx9rB/a5uJrMndTeqqPTw9QWWn6UW4gt hAM4wUAeEf9H+G+P3pCK7SHLEftrq+2jpvlvUOIVcM23xp9+HOxTpyIBtHpFRsHdURXV 95F4YJb2hI34d8jqEvQl0DeNJ2wNUPQd1+QD0Za9pxdocbWBH5ervIInpgAV2/+AXqng K5v7FvsQBwVKbROk86QV0TRI5ndGiyap0TS3gabdCv6uWOwglHR5kF/EeZuOLZm0fJYN bmnCAc1qJnodt8O7nz++0Gb5LJIF1YFJxZpVB7vAOxwH7cgBndz6O4OXAoWGSogg7wLX yjHA==
X-Gm-Message-State: ALoCoQlFyRL5h0pwQTLBoqxFOgm0JCjK/itR5WRJenQUskIr0o7CVAsT0xtzYit9asU6fF+JFUWg
MIME-Version: 1.0
X-Received: by with SMTP id uk2mr112637lbb.97.1411052615317; Thu, 18 Sep 2014 08:03:35 -0700 (PDT)
Received: by with HTTP; Thu, 18 Sep 2014 08:03:35 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Thu, 18 Sep 2014 11:03:35 -0400
Message-ID: <>
From: Richard Barnes <>
To: Tero Kivinen <>
Content-Type: multipart/alternative; boundary="047d7b342f0ce5451b050358490b"
Cc: "" <>, "" <>, "" <>, Michael Jones <>, Kathleen Moriarty <>, Tim Bray <>, "" <>, John Bradley <>
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: Thu, 18 Sep 2014 15:04:00 -0000

We had a whole working group on JSON, which I was hoping would solve the
problem of duplicate members (by forbidding them).  That would have caused
the parser community to get more strict.

Unfortunately, that didn't happen, largely due to concern over streaming
generators/parsers that can't keep track of what keys they've seen.
Whether you agree with that or not, that's the IETF consensus in the
current JSON RFC.

The JOSE documents are not the place to solve JSON's duplicate-key
problems.  We tried to that problem and decided not to.

So we have two choices: Either deal with the limitations of the tool, or
throw it away and use another.  The limitations here are really not bad.
There are no attacks that would be enabled by duplicate keys, and there are
no other tools that provide what we need.  Regardless  of the merits of
I-JSON, the software base doesn't exist, and this spec isn't going to make
it exist (but if it does come to be, then implementations can use it!).
The current text basically says, "use an off-the-shelf parser that works
the way most off-the-shelf parsers work."  It accommodates the limitations
of reality.

Continuing to tilt at this windmill is just going to result in either
killing JOSE deployment or creating a portion of the spec that is
universally ignored.  And moreover, it will demonstrate further how
out-of-touch the IETF is with reality.


On Thu, Sep 18, 2014 at 4:06 AM, Tero Kivinen <> wrote:

> 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...
> --
> _______________________________________________
> secdir mailing list
> wiki: