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

"Jim Schaad" <ietf@augustcellars.com> Tue, 07 October 2014 02:21 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84D521A9108; Mon, 6 Oct 2014 19:21:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 mgoKxAzr3xT6; Mon, 6 Oct 2014 19:21:49 -0700 (PDT)
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 873EA1A9116; Mon, 6 Oct 2014 19:21:49 -0700 (PDT)
Received: from Philemon (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 78A5A38F07; Mon, 6 Oct 2014 19:21:45 -0700 (PDT)
From: "Jim Schaad" <ietf@augustcellars.com>
To: "'Mike Jones'" <Michael.Jones@microsoft.com>, "'Stephen Farrell'" <stephen.farrell@cs.tcd.ie>, "'Ted Lemon'" <Ted.Lemon@nominum.com>
References: <20141002111501.6046.52416.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439BAF0C1E@TK5EX14MBXC286.redmond.corp.microsoft.com> <00c601cfe1a4$15d32900$41797b00$@augustcellars.com> <7ABF79CB-61C8-490B-A727-465530222F0B@nominum.com> <00dd01cfe1aa$eba7db10$c2f79130$@augustcellars.com> <54330888.4090605@cs.tcd.ie> <00f101cfe1ad$6dc9fea0$495dfbe0$@augustcellars.com> <54330D56.507@cs.tcd.ie> <4E1F6AAD24975D4BA5B16804296739439BAF2783@TK5EX14MBXC286.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BAF2783@TK5EX14MBXC286.redmond.corp.microsoft.com>
Date: Mon, 6 Oct 2014 19:19:10 -0700
Message-ID: <011b01cfe1d5$17f6d610$47e48230$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFzXA7eJfgYcKZweMPGVE2DOPtSUQEciAY8Aez3c4ACI+OSpQFBX6zfAgXItlUB6UQ0RwFyOqdMAmi5Mrecaysp8A==
Content-Language: en-us
Archived-At: http://mailarchive.ietf.org/arch/msg/jose/4_4IrZxkC3OOePVswfUuOWCWLAA
Cc: jose-chairs@tools.ietf.org, draft-ietf-jose-json-web-key@tools.ietf.org, 'The IESG' <iesg@ietf.org>, jose@ietf.org
Subject: Re: [jose] Stephen Farrell's Discuss on draft-ietf-jose-json-web-key-33: (with DISCUSS and COMMENT)
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose/>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Oct 2014 02:21:51 -0000


> -----Original Message-----
> From: Mike Jones [mailto:Michael.Jones@microsoft.com]
> Sent: Monday, October 06, 2014 6:12 PM
> To: Stephen Farrell; Jim Schaad; 'Ted Lemon'
> Cc: jose-chairs@tools.ietf.org; 'The IESG'; jose@ietf.org; draft-ietf-jose-json-
> web-key@tools.ietf.org
> Subject: RE: [jose] Stephen Farrell's Discuss on draft-ietf-jose-json-web-key-
> 33: (with DISCUSS and COMMENT)
> 
> > >>>>> I worry that if we starting providing guidance to DNS names,
> > >>>>> then we need to worry about the I18N implications.  I don't
> > >>>>> remember if these are both case sensitive and easy to do the
> > >>>>> case conversion on.
> > >>>>
> > >>>> Isn't this a solved problem?   You convert to the unicode
> > >>>> presentation and then convert to the canonical case as defined in
> > >>>> the unicode standard.
> > >>> The
> > >>>> worst case scenario is that you encounter some script where this
> > >>>> rule
> > >>> doesn't
> > >>>> work, and that script is then in the position that all scripts
> > >>>> are in now.
> > >>>
> > >>> It may be it is, however this makes an assumption that clients are
> > >>> up on how to do this.  I.e. that JavaScript is going to do it
> > >>> right when I do a strlower function on a string.  I don't know
> > >>> that this is really the case. I would hope so but am unsure.
> > >>
> > >> So we're talking about key ids here. In most case where those would
> > >> use DNS names, the code that creates the key id would know what its
> > >> doing and dumber code would be presented with the key id and would
> > >> not have to do the tolower().
> > >>
> > >> So I would say its safe to add something like "When creating a key
> > >> id, if the code doing so is aware that it is dealing with a DNS
> > >> name, then that code should tolower() the DNS name before including
> > >> those bytes in the key id."
> > >
> > > Yes, but if that is the case, then why does it need to be
> > > lower-cased at all?  If I say my key id is "JimSchaad.foobar" and
> > > that is my DNS address why does it need to be lowercased? Jim
> >
> > Because there will be cases where two different implementations with
> > code try to create the same key id from its components and get it
> > wrong otherwise. Not all cases, but some.
> >
> > S.
> 
> All of this is making me think that saying anything specifically about the use of
> DNS names in Key IDs is opening up a can of worms - particularly I18N worms.
> ;-)
> 
> In my initial response, I'd proposed that we add more generic text like the
> following.  Would that work for you, Stephen?
> 
> "If case-insensitive values, such as DNS names, are included in "kid" values,
> then the application specifying their inclusion needs to define a canonical
> case-sensitive representation to use for the case-insensitive portions inside
> the "kid", such as lowercasing them."
> 
> 				-- Mike

In cases where applications assign semantics to the kid field, applications may need to define canonicalization routines for these values.  For example, if DNS names are to be used as a "kid" value, then it applications should probably specify that it be converted to lowercase before using it as a value.

I kind of like using the assumption that this is important only when applications assign semantics to the field.  Otherwise it is just going to be some random string.

Jim