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

Mike Jones <> Mon, 20 October 2014 15:39 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DB7761A0AF8; Mon, 20 Oct 2014 08:39:34 -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 PaCVr7Dn1EEk; Mon, 20 Oct 2014 08:39:31 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2D9A21A1B2F; Mon, 20 Oct 2014 08:37:55 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1054.13; Mon, 20 Oct 2014 15:37:53 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1054.13 via Frontend Transport; Mon, 20 Oct 2014 15:37:53 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1049.20 via Frontend Transport; Mon, 20 Oct 2014 15:37:52 +0000
Received: from ([]) by ([]) with mapi id 14.03.0210.003; Mon, 20 Oct 2014 15:37:23 +0000
From: Mike Jones <>
To: Stephen Farrell <>
Thread-Topic: [jose] Stephen Farrell's Discuss on draft-ietf-jose-json-web-key-33: (with DISCUSS and COMMENT)
Date: Mon, 20 Oct 2014 15:37:22 +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="utf-8"
Content-Transfer-Encoding: base64
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)(189002)(24454002)(164054003)(13464003)(479174003)(377454003)(15202345003)(20776003)(97736003)(66066001)(64706001)(47776003)(23676002)(15975445006)(84676001)(26826002)(110136001)(76482002)(33656002)(6806004)(2656002)(87936001)(92726001)(50466002)(69596002)(85806002)(44976005)(68736004)(86362001)(19580405001)(19580395003)(92566001)(86612001)(104016003)(31966008)(85852003)(55846006)(107046002)(230783001)(99396003)(4396001)(106116001)(106466001)(81156004)(77096002)(95666004)(50986999)(93886004)(46102003)(21056001)(80022003)(85306004)(54356999)(120916001)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR03MB282;; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en;
X-Microsoft-Antispam: UriScan:;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR03MB282;
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Exchange-Antispam-Report-Test: UriScan:;
X-Forefront-PRVS: 03706074BC
Received-SPF: Pass ( domain of designates as permitted sender); client-ip=;;
Authentication-Results: spf=pass (sender IP is;
Cc: Jim Schaad <>, "" <>, "" <>, 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: Mon, 20 Oct 2014 15:39:35 -0000

Hi Stephen,

Could you take a look at the text changes made and responses your DISCUSS positions in the next few days?  We’re down to a week left to submit new drafts and if we need to make further changes for you, it would be good to know what they are before that.

For your DISCUSS on JWK, this text was added in

   Some applications may include case-insensitive information in a case-
   sensitive value, such as including a DNS name as part of a "kid" (key
   ID) value.  In those cases, the application may need to define a
   convention for the canonical case to use for representing the case-
   insensitive portions, such as lowercasing them, if more than one
   party might need to produce the same value so that they can be
   compared.  (However if all other parties consume whatever value the
   producing party emitted verbatim without attempting to compare it to
   an independently produced value, then the case used by the producer
   will not matter.)

For your DISCUSS on JWA about the "oth" RSA private key parameters.  I'd responded to that on the list, but didn't delete it.

For your (3) on JWT, I did add this text in

   Of course, including
   only necessary privacy-sensitive information in a JWT is the most
   basic means of minimizing any potential privacy issues.

The proposed resolutions were applied in response to your COMMENT positions too.

                                                            -- Mike

-----Original Message-----
From: Stephen Farrell [] 
Sent: Tuesday, October 07, 2014 6:17 PM
To: Mike Jones; Barry Leiba
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)

On 08/10/14 01:47, Mike Jones wrote:
> 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?

I'm not clear what edits you are proposing but I do think that submitting an updated draft is fine and we can look at that and see how it maps to the various discuss/comment points more easily than fully process this many threads in parallel.

That said, I don't agree that the "rule" you state above is universal - messy as it may be, reality requires dealing with both case sensitive and case insensitive identifiers as well as i18n for string comparisons. In the case of key ids, I don't think there's a generic i18n issue, but there is a real issue that DNS names will be used as part of key ids. That real issue cannot be wished away via specification language no matter how smart or subtle so any updated text that does not have some level of messiness will unfortunately likely not be fit for purpose. (If however your edits are pretty much along the lines of the text previously discussed, then as I've said, I'll be fine to clear the discuss.)