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

[Barry Leiba <[e-mail]>]

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"?

Barry