> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of Barry
> Leiba
> Sent: Tuesday, October 07, 2014 9:05 AM
> To: Mike Jones
> Cc: Stephen Farrell; Jim Schaad; Ted Lemon; [email protected]; draft-
> [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)
>
> > 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?
>
> Yes, that's fine, if that's adequate for the situation.
Yes, I believe that this is adequate to the situation, especially since the
party generating the key is also extremely likely to be the one generating the
Key ID value for the key, and publishing it when needed. Parties receiving the
key and the Key ID will use and compare these values literally - not interpret
them in any way.
> Remember that this all came
> from what's in the documents now, with statements such as this (from JWT,
> Sections 5.1 and 5.2):
>
> While media type names are not case-sensitive,
> it is RECOMMENDED that "JWT" always be spelled using uppercase
> characters for compatibility with legacy implementations. Use of
> this Header Parameter is OPTIONAL.
>
> That violates the "always case sensitive" rule, and requires that you deal
> with
> comparisons and/or normalization.
The real rule is "always case sensitive unless otherwise specified". I think
the right fix is to be clear on that point. Stephen and Barry, can I proceed
on that basis and have you review the proposed edits?
> If you just say that everything is case sensitive, or REQUIRE those strings
> to be
> case-normalized, that addresses the problem.
Per my comments above, no normalization should be necessary since the Key ID
values are extremely likely to be published by the party publishing the key and
used literally by parties using the key. Different parties would never be
generating Key ID values and seeing if they match.
I'll also note that MIME Media Type values are the only values that have
case-insensitive portions in any of the 5 specs and that per RFC 2045, MIME
Media Type values are restricted to a subset of ASCII Characters - so there's
nothing difficult about doing case-insensitive comparisons of them. None of
the Unicode weirdness can happen.
> Barry
-- Mike
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
