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]>: > 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]>: > 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]> wrote: > > Hi Daisuke, > > On 2021-07-28, at 13:45, AJITOMI Daisuke <[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 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 > [email protected] > https://www.ietf.org/mailman/listinfo/cose > > >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
