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

[Mike Jones <[e-mail]>]

> -----Original Message-----
> From: Jim Schaad [mailto:[e-mail]]
> Sent: Monday, October 06, 2014 7:19 PM
> To: Mike Jones; 'Stephen Farrell'; 'Ted Lemon'
> Cc: [e-mail]; 'The IESG'; [e-mail]; draft-ietf-jose-json-
> [e-mail]
> 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:[e-mail]]
> > Sent: Monday, October 06, 2014 6:12 PM
> > To: Stephen Farrell; Jim Schaad; 'Ted Lemon'
> > Cc: [e-mail]; 'The IESG'; [e-mail];
> > draft-ietf-jose-json- [e-mail]
> > 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.

> Jim
>