Subject: [COSE] Question on Key Identifiers

From: "Jim Schaad" <[email-masked]>
Date: Wed, 19 Aug 2015 12:37:30 -0700

I have switched Key Identifiers from being a string (a base64 string if it
was binary) to being a binary value in all cases.  As with JOSE the internal
structure of a KID is not defined or reliable.  Is there any reason to allow
for KID values to be a text string as well as a binary string?  The only
possible reason that I can think of is to allow for readable KID values if
one does a dump of a message.  I don't know that this is worth the
flexibility.

Is there anyone who wants to argue for allowing have text values for KIDs
that are not encoded as binary items?

Jim

---

From: Justin Richer <[email-masked]>
Date: Wed, 19 Aug 2015 16:25:36 -0400

(Speaking as an individual)

In my JOSE experience, the *only* KID values I have ever used in any 
deployments are simple strings. Usually with values like "rsa-1" and 
"2015-08-19" and the like. No binary encoded data, no thumbprints, no 
base64.

As such, I don't see the purpose of a binary value in the first place. 
What if I'm using a JWK encoded key but a COSE-encoded token? How am I 
supposed to map the KID here:

https://mitreid.org/jwk

to my COSE object if it's binary? If the answer is "just encode the JSON 
string as a binary", then I'm not sure what the binary actually buys us.

  -- Justin

On 8/19/2015 3:37 PM, Jim Schaad wrote:
> _______________________________________________
> COSE mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 19 Aug 2015 13:32:47 -0700

For JOSE that is exactly what I would expect the experience to be, if for no
other reason that that's what the examples were showing.  Going to a binary
value is a space consumption for JOSE because of the base64 encoding.

However, do you think that people might start using thumbprints with the new
document coming out of the JOSE working group?  These are really common
outside of the JOSE space for identifying keys because they have a greater
degree of uniqueness (even if one truncates them).

Jim

> -----Original Message-----
> From: Justin Richer [mailto:[email-masked]]
> Sent: Wednesday, August 19, 2015 1:26 PM
> To: Jim Schaad; [email-masked]
> Subject: Re: [COSE] Question on Key Identifiers
> 
"2015-08-
> 19" and the like. No binary encoded data, no thumbprints, no base64.
> 
string as
> a binary", then I'm not sure what the binary actually buys us.
> 
>   -- Justin
> 
> > I have switched Key Identifiers from being a string (a base64 string
> > if it was binary) to being a binary value in all cases.  As with JOSE
> > the internal structure of a KID is not defined or reliable.  Is there
> > any reason to allow for KID values to be a text string as well as a
> > binary string?  The only possible reason that I can think of is to
> > allow for readable KID values if one does a dump of a message.  I
> > don't know that this is worth the flexibility.
> >
> > Is there anyone who wants to argue for allowing have text values for
> > KIDs that are not encoded as binary items?
> >
> > Jim
> >
> >

---

From: Mike Jones <[email-masked]>
Date: Wed, 19 Aug 2015 20:35:36 +0000

I would use thumbprints as COSE key ID values, and so would favor binary key ID values.

-- Mike
________________________________
From: Jim Schaad<mailto:[email-masked]>
Sent: ‎8/‎19/‎2015 1:32 PM
To: 'Justin Richer'<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [COSE] Question on Key Identifiers

Jim

"2015-08-
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmitreid.org%2fjwk&data=01%7c01%7cMichael.Jones%40microsoft.com%7cf144e2aacf2c4da1914108d2a8d54d96%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3pUQcoqpFeFUf4zPkf6KRgZTS3HpAK9z57ZbkTa7Rxc%3d
>
string as
> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fcose&data=01%7c01%7cMichael.Jones%40microsoft.com%7cf144e2aacf2c4da1914108d2a8d54d96%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=jBQrziGATnv69UC1%2fRtwfCUMSblsc5R7S7V6oOoP2dI%3d

_______________________________________________
COSE mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fcose&data=01%7c01%7cMichael.Jones%40microsoft.com%7cf144e2aacf2c4da1914108d2a8d54d96%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=jBQrziGATnv69UC1%2fRtwfCUMSblsc5R7S7V6oOoP2dI%3d

---

From: Justin Richer <[email-masked]>
Date: Wed, 19 Aug 2015 17:14:16 -0400

(Again, as an individual).

I honestly don't see people going to thumbprints in the COSE space. Your 
argument of space efficiency assumes that I've got a big binary value 
that I want to store in the KID. If I have a keystore with a handful of 
keys, it's going to be much easier and more space efficient to tell my 
apps/devices/things-of-the-internet "use key '1'" instead of "use key 
with the hash 'abcd2341'", because the latter is something they're going 
to have to compute themselves and compare. It would seem to me that most 
of these devices are going to have a bucket of keys to test against that 
they'll be getting from context, either as pre-placed into the device at 
onboarding/configuration time, or fetched over the network using a 
mechanism like jwks_uri is used in JOSE-based protocols like OpenID 
Connect. This position is based (and biased) from my JOSE deployment 
experience, so take it with the appropriate salt.

In the end, I do think strings are a lot more flexible as an ID and I 
would personally anticipate them being more common. I don't anticipate 
moving any of my JOSE-related things to using thumbprints, so I wouldn't 
expect to see them enforced here in COSE.

  -- Justin

---

From: Mike Jones <[email-masked]>
Date: Wed, 19 Aug 2015 21:18:33 +0000

Even if I do use the string key ID "1", there's a natural mapping of that string, via UTF-8, to the binary key ID value [49].  In fact, we could recommend this mapping in the spec for key IDs that begin their life as strings.

				-- Mike

-----Original Message-----
From: COSE [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Wednesday, August 19, 2015 2:14 PM
To: Jim Schaad; [email-masked]
Subject: Re: [COSE] Question on Key Identifiers

I honestly don't see people going to thumbprints in the COSE space. Your argument of space efficiency assumes that I've got a big binary value that I want to store in the KID. If I have a keystore with a handful of keys, it's going to be much easier and more space efficient to tell my apps/devices/things-of-the-internet "use key '1'" instead of "use key with the hash 'abcd2341'", because the latter is something they're going to have to compute themselves and compare. It would seem to me that most of these devices are going to have a bucket of keys to test against that they'll be getting from context, either as pre-placed into the device at onboarding/configuration time, or fetched over the network using a mechanism like jwks_uri is used in JOSE-based protocols like OpenID Connect. This position is based (and biased) from my JOSE deployment experience, so take it with the appropriate salt.

In the end, I do think strings are a lot more flexible as an ID and I would personally anticipate them being more common. I don't anticipate moving any of my JOSE-related things to using thumbprints, so I wouldn't expect to see them enforced here in COSE.

  -- Justin

On 8/19/2015 4:32 PM, Jim Schaad wrote:
> For JOSE that is exactly what I would expect the experience to be, if 
> for no other reason that that's what the examples were showing.  Going 
> to a binary value is a space consumption for JOSE because of the base64 encoding.
>
> However, do you think that people might start using thumbprints with 
> the new document coming out of the JOSE working group?  These are 
> really common outside of the JOSE space for identifying keys because 
> they have a greater degree of uniqueness (even if one truncates them).
>
> Jim
>
>
>> What if I'm using a JWK encoded key but a COSE-encoded token? How am 
>> I supposed to map the KID here:
>>
>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmitr
>> eid.org%2fjwk&data=01%7c01%7cMichael.Jones%40microsoft.com%7ca599a69b
>> 5bfb4e9b9c6b08d2a8db2f2f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata
>> =3wdnV1iQbIVRRb6N7s99e1Eo2b1wV2Yjxxk0wAJoLh8%3d
>>
>>> if it was binary) to being a binary value in all cases.  As with 
>>> JOSE the internal structure of a KID is not defined or reliable.  Is 
>>> there any reason to allow for KID values to be a text string as well 
>>> as a binary string?  The only possible reason that I can think of is 
>>> to allow for readable KID values if one does a dump of a message.  I 
>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww
>>> .ietf.org%2fmailman%2flistinfo%2fcose&data=01%7c01%7cMichael.Jones%4
>>> 0microsoft.com%7ca599a69b5bfb4e9b9c6b08d2a8db2f2f%7c72f988bf86f141af
>>> 91ab2d7cd011db47%7c1&sdata=mlyeJeT5e1SmN3%2bfHZnuxL0vu1v8fNaOcUEfdBx
>>> GGxM%3d

_______________________________________________
COSE mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fcose&data=01%7c01%7cMichael.Jones%40microsoft.com%7ca599a69b5bfb4e9b9c6b08d2a8db2f2f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=mlyeJeT5e1SmN3%2bfHZnuxL0vu1v8fNaOcUEfdBxGGxM%3d

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 19 Aug 2015 14:41:24 -0700

> argument of space efficiency assumes that I've got a big binary value that
I want
> to store in the KID. If I have a keystore with a handful of keys, it's
going to be
> much easier and more space efficient to tell my
apps/devices/things-of-the-
> internet "use key '1'" instead of "use key with the hash 'abcd2341'",
because the
> latter is something they're going to have to compute themselves and
compare.

No, you are operating under a misconception of how things are going to work.

The thumbprint is computed once, by the person who generates the key and it
is placed in the key id field.  From that point on things are going to work
the same way as they would if you used the string "use key 1".  If you
needed to recomputed the thumbprint then it would be necessary to know the
format of the data to be encoded and the hash being used.  This is strictly
a function of the creator of the initial identifier.

jim

> It would seem to me that most of these devices are going to have a bucket
of
> keys to test against that they'll be getting from context, either as
pre-placed into
> the device at onboarding/configuration time, or fetched over the network
using
> a mechanism like jwks_uri is used in JOSE-based protocols like OpenID
Connect.
> This position is based (and biased) from my JOSE deployment experience, so
take
> it with the appropriate salt.
> 
would
> personally anticipate them being more common. I don't anticipate moving
any
> of my JOSE-related things to using thumbprints, so I wouldn't expect to
see them
> enforced here in COSE.

---

From: Derek Atkins <[email-masked]>
Date: Thu, 20 Aug 2015 22:10:32 -0400

Jim,

> degree of uniqueness (even if one truncates them).

In my implementation/use of COSE we plan to use a PGP Fingerprints as
KIDs.  We expect to use the binary form, not a printable string.

> Jim

-derek
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant