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

[Jeremy O'Donoghue <[e-mail]>]

On 09/08/2021, 21:21, "Laurence Lundblade" <[e-mail]> wrote:
On Aug 9, 2021, at 12:43 PM, Michael Richardson <[e-mail]<mailto:[e-mail]>> wrote:


Carsten Bormann <[e-mail]<mailto:[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.

[JOD] The document does not say that, but it requires careful reading to realise that this is not so.

I can certainly say that *I* made an error in my effort to implement a COSE library, and I am reasonably experienced in reading and interpreting standards text, so I believe it is an error others might make. The error was not “encode the map key as “kty” and also 1. That is completely clear from the CDDL. It was that it was not apparent without careful reading that the “Name” column in (for example) COSE Algorithms is descriptive only and the “value” column is the one containing allowed normative values.

I am prepared to accept that a reasonable outcome here is that “people should read the standards more carefully”, or even that “Jeremy should read standards more carefully”. It does seem that we are too late in document publishing process to do anything about this.

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.

[JOD] Document doesn’t state that you do not register both a tstr and an int value. I do agree that you should not.

Perhaps a good way forward is Expert Review (whether with Standards Action or not) does not approve tstr values unless there is a very compelling reason why use of an integer is unreasonable or impossible. This, as I understand things, does not require any specification change, since it looks to be exactly within the scope of the existing Expert Review instructions.

Best regards
Jeremy