> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of Barry
> Leiba
> Sent: Tuesday, October 07, 2014 5:14 AM
> To: Stephen Farrell
> Cc: Mike Jones; Jim Schaad; Ted Lemon; [email protected]; draft-ietf-
> [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)
>
> I think I've kept the relevant bits here:
>
> >>>>> 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.
> >>>>
> >>>> 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."
> >>>
> >>> 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 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.
>
> On the desire not to open the I18N "can of worms": I'm sorry, folks, but just
> wanting not to open it doesn't make it stay closed. If you will ver have to
> compare strings, you *have* to deal with it. It doesn't matter whether you've
> assigned semantic significance to the field or not. If a kid value (for
> example)
> will ever have to be compared to another string (be it another kid value or
> any
> other string from any other source), and you do not want a straight
> byte-by-byte
> comparison -- say, you created a kid value and I created a kid value, and you
> need to see if they match -- then you need to address now to do the
> comparison... or how to create the strings so that the byte-by-byte comparison
> works.
>
> Even with Stephen's "SHOULD" there, I don't see how interop happens.
> If you lowercase your DNS names (or other case-insensitive values), using "the
> common approach", but I decide to be uncommon and uppercase them (perhaps
> I have a system that internally stores these things in upper case, so it's
> easier for
> me to leave them that way), then we don't interoperate.
>
> Why, then, is this not a "MUST"?
This brings me back around to wondering why just saying that Key ID values are
case sensitive strings is not enough, and leaving it up to applications how to
choose the contents of those case-sensitive strings? I really feel like
injecting domain names into the discussion, when I'm aware of no deployments
that use domain names in Key ID values, is a red herring.
It's also worth noting that, from a protocol perspective, the same party that
creates the Key ID value will almost certainly be publishing it to the
recipients, so there's no chance of mismatch. If I'm a signer, I'll both put
the "kid" value in a JWK Set to advertise my keys and put the same "kid" value
in a JWS in which the key is used. There's no chance for mismatch, since the
same party is publishing the same "kid" value in all the places it is used.
I think that by even talking about domain names in the context of Key IDs,
we're creating an issue where none actually exists. I'm hoping that simplicity
can prevail here...
> Barry
-- Mike
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
