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

[AJITOMI Daisuke <[e-mail]>]

> I understood that some people think that we can encode the map key for
'kty'
> as both 'kty' and also 1.

Perhaps my description has been misleading but, at least for me, it was
very clear that we could NOT encode the map key as 'kty' and also 1 because
the CDDL says that (as Jeremy mentioned).

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

Same as Jeremy, this is the point where I misunderstood. I think the
problem is that the CDDL says "int | tstr", but any description of tstr is
not included in RFC8152.

>  label = int / tstr

I did not mention this issue in this thread so far but it is also one of
the issues I wanted to address. As well as tstr values for kty, alg, crv,
and key_ops, I think there is no need to use the tstr label.

Regards,
Daisuke


2021年8月10日(火) 19:35 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]>
> 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.
>
>
>
> [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
>
>
>