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

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 <ajitomi@gmail.com> 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 <jodonogh@qti.qualcomm.com <mailto: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 <mailto: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 <mailto:cabo@tzi.org>> wrote:
>> 
>> Hi Daisuke,
>> 
>>> On 2021-07-28, at 13:45, AJITOMI Daisuke <ajitomi@gmail.com <mailto: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 <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
>> COSE@ietf.org <mailto:COSE@ietf.org>
>> https://www.ietf.org/mailman/listinfo/cose <https://www.ietf.org/mailman/listinfo/cose>
> 