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

On 07/10/14 03:23, Mike Jones wrote:
>> -----Original Message-----
>> From: Jim Schaad [mailto:ietf@augustcellars.com]
>> Sent: Monday, October 06, 2014 7:19 PM
>> To: Mike Jones; 'Stephen Farrell'; '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)
>>
>>
>>
>>> -----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.
> 
> I agree - thanks Jim.

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.

S.

> 
>> Jim
>>
> 
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
> 