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

Hi folks,

> I prefer to see the option of `tstr` labels removed if possible.

I'm glad to see that there are several people who agree with me.

To remove the option of tstr labels from the spec, would a revised RFC be
needed? Or would an errata enough for that?
Anyway, I would like to hear from the key members in COSE whether this
change is acceptable or not.

If it is acceptable, I would like to support moving this effort forward.

Best regards,
Daisuke

2021年8月5日(木) 19:48 Jeremy O'Donoghue <jodonogh@qti.qualcomm.com>:

> Hi list,
>
>
>
> I agree with Laurence on this. I work on platform-related security
> standards at GlobalPlatform where we are using COSE quite extensively. A
> major use-case is highly constrained embedded targets where the benefits
> from eliminating string handling are considerable – many such platforms do
> not have a heap, and minimal code size is an important design goal.
>
>
>
> I prefer to see the option of `tstr` labels removed if possible. We do
> have a 64bit integer space for algorithms which should suffice. If this is
> not possible (e.g. for backward compatibility with proprietary
> implementations), at least a note to registrants that integer values are
> greatly preferred in some implementations for reasons of code size would be
> helpful. Implementations could then decide whether to not implement tstr
> support.
>
>
>
> Best regards
>
> Jeremy
>

2021年7月29日(木) 5:50 Laurence Lundblade <lgl@island-resort.com>:

> Yes, I much prefer int labels for a small C implementation. Adding support
> for tstr labels would noticeably increase code size. I hope no one
> registers a tstr label.  It seems unlikely because algorithms are
> relatively hard to invent and vet.
>
> LL
>
>
> On Jul 28, 2021, at 5:47 AM, Carsten Bormann <cabo@tzi.org> wrote:
>
> Hi Daisuke,
>
> On 2021-07-28, at 13:45, AJITOMI Daisuke <ajitomi@gmail.com> wrote:
>
> In my opinion, the tstr type for 'kty', 'alg', 'crv' or 'key_ops' is not
> necessary because I think the major advantage of COSE is its
> compactness,but I would like to know what you are assuming as the value of
> tstr.
>
>
> The registrant gets the choice between a text string and an integer.
>
> https://www.iana.org/assignments/cose/cose.xhtml lists the registration
> procedures for certain ranges, e.g.:
>
> https://www.iana.org/assignments/cose/cose.xhtml#algorithms
>
> Range <sort_none.gif> Registration Procedures <sort_up.gif>
> Strings of length 1 Standards Action With Expert Review
> Integer values between -256 and 255 Standards Action With Expert Review
> Strings of length 2 Specification Required
> Integer values from 256 to 65535 Specification Required
> Integer values from -65536 to -257 Specification Required
> Strings of length greater than 2 Expert Review
> Integer values greater than 65535 Expert Review
>
> So labels the representations of which would be 1+0 and 1+1 bytes long
> require standards action, 1+2, specification required, and 1+>2, expert
> review.
>
> It doesn’t look like anyone has felt a need to register a text string
> label for an algorithm ID yet; there are still quite a few 1+1 (and even a
> few 1+0!) values available for registration.
>
> I would expect that, until we run out of codepoints, the registration of
> text labels will remain an occurrence for special circumstances (which
> means we might not be prepared for text labels when we finally actually
> need them).
>
> Grüße, Carsten
>
> _______________________________________________
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose
>
>
>