Re: [COSE] tstr values for kty, alg, crv, etc.

[Laurence Lundblade <[e-mail]>]

> On Aug 9, 2021, at 12:43 PM, Michael Richardson <[e-mail]> wrote:
> 
> 
> Carsten Bormann <[e-mail]> wrote:
>> This discussion is all a bit short sighted to me. Sure, we can advise
>> against registering text labels now. But COSE has a long life with many
>> applications before it, some of which may be outside what you are
>> thinking about now. What’s the rush on disabling these?
> 
> I understood that some people think that we can encode the map key for 'kty'
> as both 'kty' and also 1.
> 
> (section 7 of RFC8152)
> [ditto alg and I think key_ops]
> 
> I'm not convinced the document says that.

Agreed.

The CDDL allows only 1, 2, 3,...for the params defined in COSE, but allows tstr for future params.


   label = int / tstr


   COSE_Key = {
       1 => tstr / int,          ; kty
       ? 2 => bstr,              ; kid
       ? 3 => tstr / int,        ; alg
       ? 4 => [+ (tstr / int) ], ; key_ops
       ? 5 => bstr,              ; Base IV
       * label => values
   }

Essentially, I think anyone trying to register tstr COSE identifier or label should be asked if they really want to do that, is it really necessary to use a tstr instead of an int:  Are you just doing it because you are used to JSON? You know that most implementations don’t support tstr, right?

Also, to be clear, you don't register both a tstr and an int for a particular item. There are two ways of doing this, but not for an individual item. Having tstr ‘foo’ and int 42 both referring to the same item would actually require two registrations and would be the worst thing to do.

LL