Re: [jose] Stephen Farrell's Discuss on draft-ietf-jose-json-web-key-33: (with DISCUSS and COMMENT)

Mike Jones <> Wed, 08 October 2014 00:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8ECA21A8ABD; Tue, 7 Oct 2014 17:48:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 z8oIAgAcrok6; Tue, 7 Oct 2014 17:48:15 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 747961A8AC8; Tue, 7 Oct 2014 17:48:15 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1044.10; Wed, 8 Oct 2014 00:48:13 +0000
Received: from (2a01:111:f400:7c10::1:108) by (2a01:111:e400:401e::28) with Microsoft SMTP Server (TLS) id 15.0.1049.19 via Frontend Transport; Wed, 8 Oct 2014 00:48:13 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Wed, 8 Oct 2014 00:48:13 +0000
Received: from ([]) by ([]) with mapi id 14.03.0210.003; Wed, 8 Oct 2014 00:47:35 +0000
From: Mike Jones <>
To: Barry Leiba <>, Stephen Farrell <>
Thread-Topic: [jose] Stephen Farrell's Discuss on draft-ietf-jose-json-web-key-33: (with DISCUSS and COMMENT)
Date: Wed, 08 Oct 2014 00:47:34 +0000
Message-ID: <>
References: <> <> <00c601cfe1a4$15d32900$41797b00$> <> <00dd01cfe1aa$eba7db10$c2f79130$> <> <00f101cfe1ad$6dc9fea0$495dfbe0$> <> <> <011b01cfe1d5$17f6d610$47e48230$> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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)(199003)(51704005)(189002)(13464003)(377454003)(19580395003)(50986999)(86362001)(68736004)(99396003)(19580405001)(44976005)(76482002)(33656002)(69596002)(6806004)(76176999)(120916001)(54356999)(84676001)(92566001)(85852003)(95666004)(26826002)(21056001)(55846006)(50466002)(86612001)(92726001)(97736003)(85806002)(104016003)(31966008)(107046002)(4396001)(106116001)(77096002)(106466001)(23726002)(81156004)(46102003)(2656002)(47776003)(97756001)(85306004)(87936001)(46406003)(230783001)(64706001)(20776003)(66066001)(93886004)(80022003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB1214;; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en;
X-Microsoft-Antispam: UriScan:;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB1214;
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 0358535363
Received-SPF: Pass ( domain of designates as permitted sender); client-ip=;;
Authentication-Results: spf=pass (sender IP is;
Cc: "" <>, Jim Schaad <>, Ted Lemon <>, "" <>, "" <>, The IESG <>
Subject: Re: [jose] Stephen Farrell's Discuss on draft-ietf-jose-json-web-key-33: (with DISCUSS and COMMENT)
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: Wed, 08 Oct 2014 00:48:17 -0000

> -----Original Message-----
> From: [] On Behalf Of Barry
> Leiba
> Sent: Tuesday, October 07, 2014 9:05 AM
> To: Mike Jones
> Cc: Stephen Farrell; Jim Schaad; Ted Lemon;; draft-
>; The IESG;
> Subject: Re: [jose] Stephen Farrell's Discuss on draft-ietf-jose-json-web-key-33:
> (with DISCUSS and COMMENT)
> > This brings me back around to wondering why just saying that Key ID
> > values are case sensitive strings is not enough, and leaving it up to
> > applications how to choose the contents of those case-sensitive
> > strings?
> Yes, that's fine, if that's adequate for the situation.

Yes, I believe that this is adequate to the situation, especially since the party generating the key is also extremely likely to be the one generating the Key ID value for the key, and publishing it when needed.  Parties receiving the key and the Key ID will use and compare these values literally - not interpret them in any way.

> Remember that this all came
> from what's in the documents now, with statements such as this (from JWT,
> Sections 5.1 and 5.2):
>    While media type names are not case-sensitive,
>    it is RECOMMENDED that "JWT" always be spelled using uppercase
>    characters for compatibility with legacy implementations.  Use of
>    this Header Parameter is OPTIONAL.
> That violates the "always case sensitive" rule, and requires that you deal with
> comparisons and/or normalization.

The real rule is "always case sensitive unless otherwise specified".  I think the right fix is to be clear on that point.  Stephen and Barry, can I proceed on that basis and have you review the proposed edits?

> If you just say that everything is case sensitive, or REQUIRE those strings to be
> case-normalized, that addresses the problem.

Per my comments above, no normalization should be necessary since the Key ID values are extremely likely to be published by the party publishing the key and used literally by parties using the key.  Different parties would never be generating Key ID values and seeing if they match.

I'll also note that MIME Media Type values are the only values that have case-insensitive portions in any of the 5 specs and that per RFC 2045, MIME Media Type values are restricted to a subset of ASCII Characters - so there's nothing difficult about doing case-insensitive comparisons of them.  None of the Unicode weirdness can happen.

> Barry

				-- Mike