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

Mike Jones <> Mon, 15 September 2014 16:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C941B1ACD2A; Mon, 15 Sep 2014 09:51:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Hk4eY2MO0JqU; Mon, 15 Sep 2014 09:51:35 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 100CE1A03A9; Mon, 15 Sep 2014 09:17:48 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1029.13; Mon, 15 Sep 2014 16:17:47 +0000
Received: from (2a01:111:f400:7c10::153) by (2a01:111:e400:401e::52) with Microsoft SMTP Server (TLS) id 15.0.1029.13 via Frontend Transport; Mon, 15 Sep 2014 16:17:47 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1019.14 via Frontend Transport; Mon, 15 Sep 2014 16:17:46 +0000
Received: from ([]) by ([]) with mapi id 14.03.0195.002; Mon, 15 Sep 2014 16:17:38 +0000
From: Mike Jones <>
To: Stephen Kent <>, Kathleen Moriarty <>, "" <>, "" <>, "" <>, "" <>
Thread-Topic: JWK member names, was: [jose] SECDIR review of draft-ietf-jose-json-web-key-31
Thread-Index: AQHPzoESD2WvkanDakGRB2XPz/nr6pv9mXgQgASz7ACAABG9IA==
Date: Mon, 15 Sep 2014 16:17:37 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439AECCC93TK5EX14MBXC292r_"
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(189002)(377454003)(199003)(84326002)(84676001)(83322001)(85806002)(15975445006)(44976005)(512954002)(86612001)(6806004)(77096002)(19300405004)(87936001)(16236675004)(2656002)(33656002)(31966008)(74662001)(19625215002)(26826002)(15202345003)(86362001)(76482001)(81342001)(81542001)(71186001)(46102001)(54356999)(99396002)(76176999)(50986999)(85852003)(83072002)(79102001)(55846006)(92566001)(92726001)(2201001)(77982001)(104016003)(107046002)(107886001)(2501002)(69596002)(19580395003)(19580405001)(68736004)(64706001)(97736003)(20776003)(80022001)(66066001)(90102001)(230783001)(85306004)(21056001)(74502001)(4396001)(106466001)(95666004)(81156004)(106116001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0301MB0837;; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:;
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 03355EE97E
Received-SPF: Pass ( domain of designates as permitted sender); client-ip=;;
Authentication-Results: spf=pass (sender IP is;
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 16:51:39 -0000

Replies inline below...

From: Stephen Kent []
Sent: Monday, September 15, 2014 7:56 AM
To: Mike Jones; Kathleen Moriarty;;;;
Subject: Re: JWK member names, was: [jose] SECDIR review of draft-ietf-jose-json-web-key-31


Sure.  Here's an analysis of the requirements about duplicate member names.

There could be two very different kinds of objections to the present text:
A.  People think we have the semantics for duplicate identifiers wrong.
B.  People think we should explain the current semantics for duplicate identifiers more clearly.

I sure hope that we're dealing with B and not A.  Stephen, which is the nature of your critique of this text?
C- don't accept duplicate IDs, is what I was hoping for.

I noted why allowing a recipient to accept a dup name, and use just the last instance, will
likely lead to such behavior being perpetuated, based on PKIX experience.

So you're advocating this alternative from the analysis, correct?
1.  Require producers not use duplicate members and require consumers to reject inputs with duplicate member names.
Pros:  This is the most locked-down, consistent, and alternative.
Cons:  Real JSON parsers don't all reject duplicate inputs.  If we force people to write custom parsers, this will result in exploitable bugs (and some just won't do it and won't be conformant).

The primary reason that the working group changed from this alternative in draft -12 in July 2013 to the present one is that it allows JSON parsers as actually deployed and supported to be used.  The argument made then was that forcing people to write a custom parser to reject duplicate member names is likely to create security bugs, since insufficiently locked down parsers are a fertile area for security vulnerabilities.  It was thought that it was better to have people using well-maintained, standard parsers and count on producers to not emit duplicate member names in the first place.  Is there some aspect of this reasoning that doesn't seem convincing to you, Stephen?

As for perpetuating the behavior, it's not clear to me that the behavior will ever start, since producers can't use duplicate member names and consumers are allowed to reject them.  Thus, producers can't count on consumers accepting the illegal inputs, and so have a strong disincentive against ever producing them.  Is there something I'm missing here?

Also, in a reply to Tim, I think you argued that people have already implemented JOSE and so
we ought not make any changes at this late stage. If that's what you said, I disagree emphatically.
The IETF always warns implementers that specs may change until an RFC is published, and thus
one implements a pre-RFC spec at risk.

You apparently misunderstood the point of my reply to Tim.  I wasn't saying that changes aren't possible.  I was saying that we want JOSE to be usable by people now - not just several years in the future when parsers for a more locked-down JSON dialect may become available.


                                                            -- Mike