> -----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. > Jim > _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
