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

[Mike Jones <[e-mail]>]

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