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

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Fri, 12 September 2014 11:59 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 176391A070F; Fri, 12 Sep 2014 04:59:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tySfm2PeyK2; Fri, 12 Sep 2014 04:59:51 -0700 (PDT)
Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F21D61A06DA; Fri, 12 Sep 2014 04:59:50 -0700 (PDT)
Received: by mail-la0-f45.google.com with SMTP id b17so786785lan.18 for <multiple recipients>; Fri, 12 Sep 2014 04:59:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=2MP268llEyTf+de0rMONvTc2T9CMaqPxImKVQtZa4r8=; b=OnLkA0eONOw13TQrp6Tw9s+lIJYkmoQnhyx1UwfT2ey9mL+4I7/axGHc5soOTuyItM P8ZIpK4deNWutMGv3fPtxBDp00B+FfcU3HeX1f3MnDIS8yv6Nod1O53LX3o02V21POb7 RT/X06+P8eXkEZdBoXdi+f/s2R7tYpKChXCXMfgYwt5krY2xEGhUH21LyIzlNIZYoxld 0ZwGoiTIpLQ0x/Fvy1JGSz2RlhM5I13CgqJpUXtEj/iK3uwSjsYuTASwyAvxQ57sfruO WtJ5oSYTXz0ihl08M0IiLiqSqwnlbwk8+4i0QYIQopXANir6v+qCsA1vJTOdxiP9q6VM UfCw==
MIME-Version: 1.0
X-Received: by 10.112.138.201 with SMTP id qs9mr7849650lbb.41.1410523189246; Fri, 12 Sep 2014 04:59:49 -0700 (PDT)
Received: by 10.112.64.170 with HTTP; Fri, 12 Sep 2014 04:59:49 -0700 (PDT)
Date: Fri, 12 Sep 2014 07:59:49 -0400
Message-ID: <CAHbuEH4Ccn2Z=8kEECzvgjmtshwsFoa-EH_NpkJPos7zirGeaQ@mail.gmail.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
To: "jose@ietf.org" <jose@ietf.org>, "jose-chairs@tools.ietf.org" <jose-chairs@tools.ietf.org>, draft-ietf-jose-json-web-key.all@tools.ietf.org, secdir@ietf.org, Stephen Kent <kent@bbn.com>, Michael Jones <Michael.Jones@microsoft.com>
Content-Type: multipart/alternative; boundary=089e01176ff9a47e120502dd0541
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/glL1UrNLvRjJw0E9kGvX9di1ZTg
Subject: [secdir] JWK member names, was: [jose] SECDIR review of draft-ietf-jose-json-web-key-31
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Sep 2014 11:59:54 -0000

Hi Mike,

The text Steve called out below has been very problematic as you know.
 Could you call out some options here as the last time this came up, we
didn't resolve it.  The working group was asked for suggestions, but none
came through.  If you could provide some options and then have the working
group weigh in, I think that would be good.

I snipped away the rest of the review and changed the subject as not to get
in the way of the current dialog.

Thanks.

On Wed, Sep 10, 2014 at 8:57 PM, Mike Jones <Michael.Jones@microsoft.com>
wrote:

>  Hi Stephen.  Thanks for your detailed and useful review.  I’ve cc’ed the
> working group in my reply so they’re aware of the contents of your review.
> Replies are inline below…
>
>
>
> *From:* Stephen Kent [mailto:kent@bbn.com <kent@bbn.com>]
> *Sent:* Tuesday, September 02, 2014 1:09 PM
> *To:* secdir@ietf.org; Mike Jones; jose-chairs@tools.ietf.org; Moriarty,
> Kathleen
> *Subject:* SECDIR review of draft-ietf-jose-json-web-key-31
>
>
>
> [snip]

>
>
> This section imposes a rather wimpy constraint on parameter names:
>
>
>
>    The member names within a JWK MUST be unique; recipients MUST either
>
>    reject JWKs with duplicate member names or use a JSON parser that
>
>    returns only the lexically last duplicate member name, as specified
>
>    in Section 15.12 (The JSON Object) of ECMAScript 5.1 [ECMAScript].
>
>
>
> This text says that member names MUST be unique, but if they are not,
> that’s OK too; just use the last instance of a member with a duplicate
> name. This seems like a terrible design principle. It imposes what appears
> to be a requirement, then says how to accommodate data structures that fail
> to meet the requirement. This would seem to encourage sloppy
> implementations (for JWK generation). I’d like to see the rationale for
> this.
>
>
>
>
>
> Unfortunately, the intentional laxness in the spec in this regard is a
> reflection of the semantics of the actual JSON specifications and
> implementations.  For instance,
> http://tools.ietf.org/html/rfc7159#section-4 says:
>
>
>
>    An object whose names are all unique is interoperable in the sense
>
>    that all software implementations receiving that object will agree on
>
>    the name-value mappings.  When the names within an object are not
>
>    unique, the behavior of software that receives such an object is
>
>    unpredictable.  Many implementations report the last name/value pair
>
>    only.  Other implementations report an error or fail to parse the
>
>    object, and some implementations report all of the name/value pairs,
>
>    including duplicates.
>
>
>
> This topic has been heavily discussed by the working group, and while the
> specs used to just say that objects with duplicate member names MUST be
> rejected, working group members, including Tim Bray (the editor of the JSON
> spec), prevailed on us to weaken this so that parsers that implement the
> ECMAscript behavior of returning only the last member name may be legally
> used.  (The argument was made that there was more security downside in
> effectively requiring people to write and debug their own strict parsers
> than in using laxer, but well-supported and debugged parsers.)
>
>
>
> However, we also intentionally require that producers use only one
> instance of each member name, so that legally produced objects will never
> exercise the ambiguities that are present in real JSON parsers.  That
> seemed to be the most practical solution to the working group.
>
>
>
> [snip]
>
>                                                             Thanks again,
> Stephen,
>
>                                                             -- Mike
>
>
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>
>


-- 

Best regards,
Kathleen



-- 

Best regards,
Kathleen