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

From: Mike Jones <[email-masked]>
Date: Mon, 6 Oct 2014 07:54:11 +0000

Thanks for your review, Stephen.  I'm adding the working group to the thread so they're aware of your comments.

> -----Original Message-----
> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Thursday, October 02, 2014 4:15 AM
> To: The IESG
> Cc: [email-masked]; [email-masked]
> Subject: Stephen Farrell's Discuss on draft-ietf-jose-json-web-key-33: (with
> DISCUSS and COMMENT)
> 
> Stephen Farrell has entered the following ballot position for
> draft-ietf-jose-json-web-key-33: Discuss
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-jose-json-web-key/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> 
> nearly a nit, but would impact code so a discuss to make sure we get it right...
> 
> 4.5: saying kid is case sensitive precludes use of DNS names there or introduces
> bugs if those are used.  Since DNS names are the primary way we distinguish
> things on the Internet, that seems odd. I don't think that you need to say case-
> insensitive here but that you might want to say that DNS names SHOULD be
> [lower|upper]cased before being used in kid parameters.

OK

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> 4.8: I'd prefer if sha-256 had been the default/shorter of these. But whatever.

The SHA-1 is the one that's actually in widely deployed crypto libraries, including Windows and OpenSSL, and has been in the spec pretty much the whole time.  Kathleen had us add the S256 version based on its usage in SSH during her AD review.

> 4.8/4.9: the disconnect with DANE and other specs that use
> HASH(SPKI) as a thumbprint is a pity (but can be fixed later). How'd that happen?

The current thumbprint calculation is the one used by OpenSSL and Windows, among others.

The first that this issue was raised was during Tero Kivinen's secdir review.  In that discussion, I pointed out that other specs are free to define header parameter(s) to represent the HASH(SPKI) thumbprint and register them.  (I even pointed him to draft-jones-jose-jwk-thumbprint-01 as an example of a spec making a similar registration that he could use as an example if he wanted to write it up.)  He thought that that definition would be useful to the IoT community, so I expect that someone will do that when the need arises.

> 8: "make sense" still isn't useful;-) I've noted that on the algs draft though so
> won't repeat more.

Noted

> C.9: Huh? Needs a ref to compact rep which isn't defined here.

Agreed - thanks

> As with other JOSE drafts, there was a substantial thread on the secdir review
> that I didn't have time to follow but I'm ok that Kathleen's been on top of that.

Yes, she has.

				Thanks again,
				-- Mike

---

From: Mike Jones <[email-masked]>
Date: Mon, 6 Oct 2014 07:54:11 +0000

[Adding the working group to this thread so they’re aware of the discussion between our Security Area Directors on this]

From: Kathleen Moriarty [mailto:[email-masked]]
Sent: Thursday, October 02, 2014 5:30 AM
To: Stephen Farrell
Cc: The IESG; [email-masked]; [email-masked]
Subject: Re: Stephen Farrell's Discuss on draft-ietf-jose-json-web-key-33: (with DISCUSS and COMMENT)

On Thu, Oct 2, 2014 at 8:20 AM, Stephen Farrell <[email-masked]<mailto:[email-masked]>> wrote:

sorry forgot about that...

On 02/10/14 13:04, Kathleen Moriarty wrote:
> Yes, I mentioned the duplicate member name discussion in a couple of
> the draft's ballot text.  There isn't really a great answer at this
> time unfortunately.  This particular item came up in my AD review as
> well as in a SecDir review.  It took some digging, but the problem is
> at least better understood now.  There may be a way to fix it with a
> draft that updates if I-JSON turns out to be a good way to handle
> this.  The problem is deployed code.  I flagged it in case anyone in
> the IESG had an opinion.  I'd love to see the right thing get done,
> but it may have to wait for a draft that updates these.  Opinions are
> welcome.

At a comment level, I'd say leave things as they are. Adding the
I-JSON requirement would be premature I think as its not clear if
libraries etc will or won't adopt that. If they don't then it'd
be a meaningless requirement. If however, I-JSON does take off then
JOSE code will be fine anyway without changing.

Thanks, Stephen.  I'm leaning the same way for now.  It looks like Pete hit this in a discuss, but just requesting a wording change as opposed the the more extensive changes discussed on list.  I'll follow up to his message.

S.

--

Best regards,
Kathleen

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 6 Oct 2014 13:28:26 -0700

> From: jose [mailto:[email-masked]] On Behalf Of Mike Jones
> Sent: Monday, October 06, 2014 12:54 AM
> To: Stephen Farrell; The IESG
> Cc: [email-masked];
[email-masked];
> [email-masked]
> Subject: Re: [jose] Stephen Farrell's Discuss on
draft-ietf-jose-json-web-key-33:
> (with DISCUSS and COMMENT)
> 
> Thanks for your review, Stephen.  I'm adding the working group to the
thread
> so they're aware of your comments.
> 
> > Cc: [email-masked];
> > [email-masked]
> > Subject: Stephen Farrell's Discuss on draft-ietf-jose-json-web-key-33:
> > (with DISCUSS and COMMENT)
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut
> > this introductory paragraph, however.)
> >
> >
> > Please refer to
> > http://www.ietf.org/iesg/statement/discuss-criteria.html
> > 4.5: saying kid is case sensitive precludes use of DNS names there or
> > introduces bugs if those are used.  Since DNS names are the primary
> > way we distinguish things on the Internet, that seems odd. I don't
> > think that you need to say case- insensitive here but that you might
> > want to say that DNS names SHOULD be [lower|upper]cased before being
> used in kid parameters.
> 
> OK

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.

> > HASH(SPKI) as a thumbprint is a pity (but can be fixed later). How'd
that
> happen?
> The first that this issue was raised was during Tero Kivinen's secdir
review.  In
> that discussion, I pointed out that other specs are free to define header
> parameter(s) to represent the HASH(SPKI) thumbprint and register them.  (I
> even pointed him to draft-jones-jose-jwk-thumbprint-01 as an example of a
> spec making a similar registration that he could use as an example if he
> wanted to write it up.)  He thought that that definition would be useful
to the
> IoT community, so I expect that someone will do that when the need arises.

I would also say that a hash of the full certificate is needed if you care
about the extensions in the certificate as well.  Many of the bare key cases
don't care about this they are just using a cert to carry the key.

> 				Thanks again,
> 				-- Mike
> 
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Ted Lemon <[email-masked]>
Date: Mon, 6 Oct 2014 16:34:06 -0400

> 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.

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 6 Oct 2014 14:17:21 -0700

> From: Ted Lemon [mailto:[email-masked]]
> Sent: Monday, October 06, 2014 1:34 PM
> To: Jim Schaad
> Cc: Mike Jones; Stephen Farrell; The IESG; [email-masked];
draft-
> [email-masked]; [email-masked]
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.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 06 Oct 2014 22:24:24 +0100

> 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."

S.

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 6 Oct 2014 14:35:19 -0700

> Sent: Monday, October 06, 2014 2:24 PM
> To: Jim Schaad; 'Ted Lemon'
> Cc: [email-masked]; 'Mike Jones'; 'The IESG'; [email-masked]; draft-
> [email-masked]
> Subject: Re: [jose] Stephen Farrell's Discuss on draft-ietf-jose-json-web-key-
> >>> 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.
> >>
> > 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.
> 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

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 06 Oct 2014 22:44:54 +0100

On 06/10/14 22:35, Jim Schaad wrote:
> 
> 
>> -----Original Message----- From: Stephen Farrell
>> [mailto:[email-masked]] Sent: Monday, October 06, 2014
>> 2:24 PM To: Jim Schaad; 'Ted Lemon' Cc: [email-masked];
>> 'Mike Jones'; 'The IESG'; [email-masked]; draft- 
>> [email-masked] Subject: Re: [jose] Stephen
>> Farrell's Discuss on draft-ietf-jose-json-web-key- 33: (with
>> DISCUSS and COMMENT)
>> 
>> 
>> 
>>>> -----Original Message----- From: Ted Lemon
>>>> [mailto:[email-masked]] Sent: Monday, October 06, 2014
>>>> 1:34 PM To: Jim Schaad Cc: Mike Jones; Stephen Farrell; The
>>>> IESG; [email-masked];
>>> draft-
>>>> [email-masked]; [email-masked] Subject:
>>>> Re: [jose] Stephen Farrell's Discuss on
>>>>> 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
>>> 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 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.

> 
>> 
>> S.
>> 
>> 
>>> 
>>> _______________________________________________ jose mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/jose
>>> 
>

---

From: Mike Jones <[email-masked]>
Date: Tue, 7 Oct 2014 01:12:18 +0000

> >>>>> 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
> >>>> presentation and then convert to the canonical case as defined in
> >>>> the unicode standard.
> >>> The
> >>> 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.
> >>
> >> 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."
> >
> 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

---

From: Ted Lemon <[email-masked]>
Date: Mon, 6 Oct 2014 22:09:07 -0400

> get it wrong otherwise. Not all cases, but some.

Right, but as currently written, this will happen in _all_ cases, not just in special cases.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 6 Oct 2014 22:09:54 -0400

> "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 th…

WFM.

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 6 Oct 2014 19:19:10 -0700

> From: Mike Jones [mailto:[email-masked]]
> Sent: Monday, October 06, 2014 6:12 PM
> To: Stephen Farrell; Jim Schaad; 'Ted Lemon'
> Cc: [email-masked]; 'The IESG'; [email-masked]; draft-ietf-jose-json-
> [email-masked]
> Subject: RE: [jose] Stephen Farrell's Discuss on draft-ietf-jose-json-web-key-
> > >>> up on how to do this.  I.e. that JavaScript is going to do it
> > > 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.

Jim

---

From: Mike Jones <[email-masked]>
Date: Tue, 7 Oct 2014 02:23:40 +0000

> From: Jim Schaad [mailto:[email-masked]]
> Sent: Monday, October 06, 2014 7:19 PM
> To: Mike Jones; 'Stephen Farrell'; 'Ted Lemon'
> Subject: RE: [jose] Stephen Farrell's Discuss on draft-ietf-jose-json-web-key-33:
> > Cc: [email-masked]; 'The IESG'; [email-masked];
> > draft-ietf-jose-json- [email-masked]
> > > >>> 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."
> > > >
> > 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.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 07 Oct 2014 11:17:39 +0100

>> assign semantics to the field.  Otherwise it is just going to be some random

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.

S.

---

From: Mike Jones <[email-masked]>
Date: Tue, 7 Oct 2014 11:36:28 +0000

> Sent: Tuesday, October 07, 2014 3:18 AM
> To: Mike Jones; Jim Schaad; 'Ted Lemon'
> Cc: [email-masked]; [email-masked]; 'The
> IESG'; [email-masked]
> Subject: Re: [jose] Stephen Farrell's Discuss on draft-ietf-jose-json-web-key-33:
> >>>> 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 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.
> 
> 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:
> 
> I'd prefer "SHOULD be lowercased" myself but can live with the above.

Works for me.

				-- Mike

---

From: Barry Leiba <[email-masked]>
Date: Tue, 7 Oct 2014 08:13:51 -0400

> I'd prefer "SHOULD be lowercased" myself but can live with the

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"?

Barry

---

From: Mike Jones <[email-masked]>
Date: Tue, 7 Oct 2014 12:29:46 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry
> Leiba
> Sent: Tuesday, October 07, 2014 5:14 AM
> To: Stephen Farrell
> Cc: Mike Jones; Jim Schaad; Ted Lemon; [email-masked]; draft-ietf-
> [email-masked]; The IESG; [email-masked]
> >>>> about the use of DNS names in Key IDs is opening up a can of worms
> >>>> - particularly
> >>> I18N worms.
> >>>> ;-)
> >>>>
> >>> then it applications should probably specify that it be converted to
> lowercase before using it as a value.
> >>>
> > 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.
> >
> 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.
> 
> 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.
> 

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...

				-- Mike

---

From: Ted Lemon <[email-masked]>
Date: Tue, 7 Oct 2014 10:34:36 -0400

> 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-sensi…

You could say "Key IDs are compared literally, not in a case-insensitive manner.   Therefore, case-sensitive strings or other strings requiring non-literal comparison algorithms MUST NOT be used as Key IDs."

---

From: Barry Leiba <[email-masked]>
Date: Tue, 7 Oct 2014 12:04:33 -0400

> 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.  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.

If you just say that everything is case sensitive, or REQUIRE those
strings to be case-normalized, that addresses the problem.

Barry

---

From: Mike Jones <[email-masked]>
Date: Wed, 8 Oct 2014 00:47:34 +0000

> Sent: Tuesday, October 07, 2014 9:05 AM
> To: Mike Jones
> Cc: Stephen Farrell; Jim Schaad; Ted Lemon; [email-masked]; draft-
> [email-masked]; The IESG; [email-masked]
> > 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):
> 
> 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.

				-- Mike

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 08 Oct 2014 02:17:14 +0100

On 08/10/14 01:47, Mike Jones wrote:
> 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?

I'm not clear what edits you are proposing but I do think that
submitting an updated draft is fine and we can look at that and
see how it maps to the various discuss/comment points more
easily than fully process this many threads in parallel.

That said, I don't agree that the "rule" you state above is
universal - messy as it may be, reality requires dealing with
both case sensitive and case insensitive identifiers as well
as i18n for string comparisons. In the case of key ids, I
don't think there's a generic i18n issue, but there is a real
issue that DNS names will be used as part of key ids. That
real issue cannot be wished away via specification language
no matter how smart or subtle so any updated text that does
not have some level of messiness will unfortunately likely
not be fit for purpose. (If however your edits are pretty
much along the lines of the text previously discussed, then
as I've said, I'll be fine to clear the discuss.)

S.

---

From: Mike Jones <[email-masked]>
Date: Mon, 20 Oct 2014 15:37:22 +0000

Hi Stephen,

Could you take a look at the text changes made and responses your DISCUSS positions in the next few days?  We’re down to a week left to submit new drafts and if we need to make further changes for you, it would be good to know what they are before that.

For your DISCUSS on JWK, this text was added in http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-35#section-5.3:

   Some applications may include case-insensitive information in a case-
   sensitive value, such as including a DNS name as part of a "kid" (key
   ID) value.  In those cases, the application may need to define a
   convention for the canonical case to use for representing the case-
   insensitive portions, such as lowercasing them, if more than one
   party might need to produce the same value so that they can be
   compared.  (However if all other parties consume whatever value the
   producing party emitted verbatim without attempting to compare it to
   an independently produced value, then the case used by the producer
   will not matter.)

For your DISCUSS on JWA about the "oth" RSA private key parameters.  I'd responded to that on the list, but didn't delete it.

For your (3) on JWT, I did add this text in http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-29#section-12:

   Of course, including
   only necessary privacy-sensitive information in a JWT is the most
   basic means of minimizing any potential privacy issues.

The proposed resolutions were applied in response to your COMMENT positions too.

                                                            Thanks,
                                                            -- Mike

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Tuesday, October 07, 2014 6:17 PM
To: Mike Jones; Barry Leiba
Cc: [email-masked]; Jim Schaad; Ted Lemon; [email-masked]; [email-masked]; The IESG
Subject: Re: [jose] Stephen Farrell's Discuss on draft-ietf-jose-json-web-key-33: (with DISCUSS and COMMENT)

> Barry, can I proceed on that basis and have you review the proposed 

I'm not clear what edits you are proposing but I do think that submitting an updated draft is fine and we can look at that and see how it maps to the various discuss/comment points more easily than fully process this many threads in parallel.

That said, I don't agree that the "rule" you state above is universal - messy as it may be, reality requires dealing with both case sensitive and case insensitive identifiers as well as i18n for string comparisons. In the case of key ids, I don't think there's a generic i18n issue, but there is a real issue that DNS names will be used as part of key ids. That real issue cannot be wished away via specification language no matter how smart or subtle so any updated text that does not have some level of messiness will unfortunately likely not be fit for purpose. (If however your edits are pretty much along the lines of the text previously discussed, then as I've said, I'll be fine to clear the discuss.)

S.