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: [e-mail] [mailto:[e-mail]] On Behalf Of Barry
> Leiba
> Sent: Tuesday, October 07, 2014 9:05 AM
> To: Mike Jones
> Cc: Stephen Farrell; Jim Schaad; Ted Lemon; [e-mail]; draft-
> [e-mail]; The IESG; [e-mail]
> 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