> -----Original Message-----
> From: Stephen Farrell [mailto:[email protected]]
> Sent: Tuesday, October 07, 2014 3:18 AM
> To: Mike Jones; Jim Schaad; 'Ted Lemon'
> Cc: [email protected]; [email protected];
> 'The
> IESG'; [email protected]
> Subject: 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:[email protected]]
> >> Sent: Monday, October 06, 2014 7:19 PM
> >> To: Mike Jones; 'Stephen Farrell'; 'Ted Lemon'
> >> Cc: [email protected]; 'The IESG'; [email protected];
> >> draft-ietf-jose-json- [email protected]
> >> 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:[email protected]]
> >>> Sent: Monday, October 06, 2014 6:12 PM
> >>> To: Stephen Farrell; Jim Schaad; 'Ted Lemon'
> >>> Cc: [email protected]; 'The IESG'; [email protected];
> >>> draft-ietf-jose-json- [email protected]
> >>> 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.
Works for me.
> S.
-- Mike
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
