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

Barry Leiba <> Tue, 07 October 2014 12:13 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D94B01A1B9A; Tue, 7 Oct 2014 05:13:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id arwe_Xw77sC2; Tue, 7 Oct 2014 05:13:55 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 01AEB1A1B8E; Tue, 7 Oct 2014 05:13:53 -0700 (PDT)
Received: by with SMTP id mk6so6252415lab.15 for <multiple recipients>; Tue, 07 Oct 2014 05:13:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=2stVMNCVaPplEQVjwtHvw2VZTrsZHkJCSw74liHaB9U=; b=N6KTcC6CiIz7LvpfDB48escCet3OOMRZ6zzNfu/4HAtXL4nNdGI9lpv3uIlRQd4XYl JIjYAjOp2d9mUUoLbS9EXQ3Y6xp7hnxAxgodyURum+PpABemak0Lp74WrDnXed2rn3MS 9A8b2t97whgUJLWkgAnTtRdiHRyK40QxfXzXhiAsbQxQrb2T6G1dpmIT9MCuPsesnk6e pKm5Em/HHhf+8/BUSPgz+5CsUzAxxwD6AEcEjli57GQwWXluIg14N9jP7vlV3QrCSmjr c+YkMKXC2fHeEcox7reQdqhsBwui37i8f0zWUujyNuoiiPwefDuKEJWcfXE1+sM7ihH4 QLXg==
MIME-Version: 1.0
X-Received: by with SMTP id w5mr3732269laa.28.1412684032028; Tue, 07 Oct 2014 05:13:52 -0700 (PDT)
Received: by with HTTP; Tue, 7 Oct 2014 05:13:51 -0700 (PDT)
In-Reply-To: <>
References: <> <> <00c601cfe1a4$15d32900$41797b00$> <> <00dd01cfe1aa$eba7db10$c2f79130$> <> <00f101cfe1ad$6dc9fea0$495dfbe0$> <> <> <011b01cfe1d5$17f6d610$47e48230$> <> <>
Date: Tue, 07 Oct 2014 08:13:51 -0400
X-Google-Sender-Auth: Ze77jC8cVwxhOGHDJCPM7LolMRY
Message-ID: <>
From: Barry Leiba <>
To: Stephen Farrell <>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "" <>, Jim Schaad <>, Mike Jones <>, The IESG <>, "" <>, "" <>, Ted Lemon <>
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: Tue, 07 Oct 2014 12:13:58 -0000

I think I've kept the relevant bits here:

>>>>> 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.
>>>> 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."
>>> 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.
> I disagree. There is no assignment of semantics if two different
> implementations are written to read a DNS name from somewhere
> and then use that as part of a kid. The issue is nothing to do
> with semantics but all do to with whether those two chunks of
> code both do or do not include a tolower() call.
> The text suggested above is almost ok however, but I'd prefer it
> more like:
>    If case-insensitive values, such as DNS names, are included
>    in "kid" values, then the application including those needs
>    to ensure that a canonical case-sensitive representation is
>    used as otherwise different implementations will be highly
>    likely to suffer interoperability problems. In the case of
>    DNS names, the common approach taken is lowercasing."
> I'd prefer "SHOULD be lowercased" myself but can live with the
> above.

On the desire not to open the I18N "can of worms": I'm sorry, folks,
but just wanting not to open it doesn't make it stay closed.  If you
will ver have to compare strings, you *have* to deal with it.  It
doesn't matter whether you've assigned semantic significance to the
field or not.  If a kid value (for example) will ever have to be
compared to another string (be it another kid value or any other
string from any other source), and you do not want a straight
byte-by-byte comparison -- say, you created a kid value and I created
a kid value, and you need to see if they match -- then you need to
address now to do the comparison... or how to create the strings so
that the byte-by-byte comparison works.

Even with Stephen's "SHOULD" there, I don't see how interop happens.
If you lowercase your DNS names (or other case-insensitive values),
using "the common approach", but I decide to be uncommon and uppercase
them (perhaps I have a system that internally stores these things in
upper case, so it's easier for me to leave them that way), then we
don't interoperate.

Why, then, is this not a "MUST"?