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

Stephen Kent <> Mon, 15 September 2014 19:01 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E2FD91A8723; Mon, 15 Sep 2014 12:01:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.852
X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F9HGX_A_QKfH; Mon, 15 Sep 2014 12:01:21 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 62CDC1A6FCE; Mon, 15 Sep 2014 11:51:23 -0700 (PDT)
Received: from ([]:33094 helo=comsec.home) by with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <>) id 1XTbN2-000PNE-K8; Mon, 15 Sep 2014 14:51:28 -0400
Message-ID: <>
Date: Mon, 15 Sep 2014 14:51:11 -0400
From: Stephen Kent <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Mike Jones <>, Kathleen Moriarty <>, "" <>, "" <>, "" <>, "" <>
References: <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------090207070302040409080400"
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 19:01:26 -0000


> ...
> 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?
I read the rationale. Is there a good baseline of experience showing 
that JSON parsers are
not very exploitable today? We have seen problems with ASN.1 parsers, 
problems that have
taken years to surface, despite extensive use of ASN.1 in both certs and 
in SNMP.  I suggest,
without substantiation, that bugs in ASN.1 parsers were not exploited in 
the SNMP context
because there was little to gain. Use of ASN.1 for certs, where there 
can be financial incentives
for exploiting flaws, motivated more analysis by attackers. If JOSE 
represents an initial
step into an arena where crypto is to be applied to JSON in a widespread 
fashion, it also
may represent a new motivation for attackers to try to exploit any bugs 
in parsers. If so, then
the lack of identified vulnerabilities in JSON parsers so far may not be 
indicative of their

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

I did misunderstand your point, perhaps because you said:

"I understand that that's an ideal long-term solution, once I-JSON 
parsers are common/ubiquitous, but I don't expect that to be the case 
for a number of years and _*people are using JOSE now.*_"