I don’t think tstr can be removed from the standard. That would break backwards compatibility. Maybe a strong recommendation could be added with the comment that many implementations don’t support tstr.
There is a revision of 8152 in process right now called 8152bis. That seems like the place to do it. LL > On Aug 5, 2021, at 8:29 PM, AJITOMI Daisuke <[email protected]> wrote: > > 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 <[email protected] > <mailto:[email protected]>>: > 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 <[email protected] > <mailto:[email protected]>>: > 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 <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi Daisuke, >> >>> On 2021-07-28, at 13:45, AJITOMI Daisuke <[email protected] >>> <mailto:[email protected]>> 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 >> <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 >> <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 >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/cose >> <https://www.ietf.org/mailman/listinfo/cose> >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
