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

From: AJITOMI Daisuke <[email-masked]>
Date: Fri, 6 Aug 2021 12:29:22 +0900

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-masked]>:

> 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-masked]>:

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

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 5 Aug 2021 21:56:51 -0700

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-masked]> wrote:
> 
> Hi folks,
> 
> 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.
> 
> 2021年8月5日(木) 19:48 Jeremy O'Donoghue <[email-masked] <mailto:[email-masked]>>:
> 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-masked] <mailto:[email-masked]>>:
> 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-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Daisuke,
>> 
>>> On 2021-07-28, at 13:45, AJITOMI Daisuke <[email-masked] <mailto:[email-masked]>> 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.
>> 
>> 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>
>> 
>> 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
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/cose <https://www.ietf.org/mailman/listinfo/cose>
>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 6 Aug 2021 09:04:27 +0200

Sent from mobile, sorry for terse

> On 6. Aug 2021, at 06:57, Laurence Lundblade <[email-masked]> wrote:
> 

Well, rfc 9052/9053 are almost published. But I think we already diagnosed that it would be good to have a document helping with registration, and that could make the point.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 07 Aug 2021 19:22:18 -0400

Laurence Lundblade <[email-masked]> wrote:
    > 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.

Any system built upon COSE that does not support tstr as a key is already
broken if many implementations don't support it.

We can deprecate tstr as key.
We can say that no signer MUST NEVER emit this again.
We can say that a verifier MAY accept tstr as a key.

    > seems like the place to do it.

It is pretty late to do this.  8152bis is in AUTH48, we need the proxy-author
and WG chairs to agree to this immediately.

I agree that having two ways things is not a good thing.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: AJITOMI Daisuke <[email-masked]>
Date: Sun, 8 Aug 2021 17:13:10 +0900

> We can say that a verifier MAY accept tstr as a key.

This sounds reasonable to me.

Since any tstr labels are not registered in the IANA registry for now and
there are no implementations that support the tstr labels as far as I know,

I think there is room to make the tstr labels deprecated.

Thanks,
Daisuke

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 8 Aug 2021 13:48:34 +0200

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?

> On 8. Aug 2021, at 10:15, AJITOMI Daisuke <[email-masked]> wrote:
> 
> 
> Since any tstr labels are not registered in the IANA registry for now and there are no implementations that support the tstr labels as far as I know,
>

---

From: AJITOMI Daisuke <[email-masked]>
Date: Sun, 8 Aug 2021 22:49:32 +0900

> What’s the rush on disabling these?

You may indeed be right.
At least, I think there may be no need to rush to apply the change
to 8152bis (Maybe that's impossible in the first place though).

Maybe we should discuss this more. I would be happy if you would consider
this matter as the next step after 8152bis.

Regards,
Daisuke

2021年8月8日(日) 20:48 Carsten Bormann <[email-masked]>:

> 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?
>
>>     > There is a revision of 8152 in process right now called 8152bis.
>> That
>>     > seems like the place to do it.
>>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 09 Aug 2021 15:43:45 -0400

Carsten Bormann <[email-masked]> wrote:
    > 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.

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 9 Aug 2021 13:21:29 -0700

> On Aug 9, 2021, at 12:43 PM, Michael Richardson <[email-masked]> wrote:
> 
> 

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.

LL

---

From: Jeremy O'Donoghue <[email-masked]>
Date: Tue, 10 Aug 2021 10:35:26 +0000

On 09/08/2021, 21:21, "Laurence Lundblade" <[email-masked]> wrote:
On Aug 9, 2021, at 12:43 PM, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

Carsten Bormann <[email-masked]<mailto:[email-masked]>> wrote:

(section 7 of RFC8152)

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

   label = int / tstr

   COSE_Key = {

       1 => tstr / int,          ; kty

       ? 2 => bstr,              ; kid

       ? 3 => tstr / int,        ; alg

       ? 5 => bstr,              ; Base IV

       * label => values

   }

[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

---

From: AJITOMI Daisuke <[email-masked]>
Date: Tue, 10 Aug 2021 23:46:25 +0900

> 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 <[email-masked]>:

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